Verwenden von Azure Firewall zum Schützen von AKS-Clustern (Azure Kubernetes Service)
In diesem Artikel erfahren Sie, wie Sie AKS-Cluster (Azure Kubernetes Service) schützen können, indem Sie Azure Firewall zum Schützen von ausgehendem und eingehendem Datenverkehr verwenden.
Hintergrund
Azure Kubernetes Service (AKS) bietet einen verwalteten Kubernetes-Cluster in Azure. Weitere Informationen finden Sie unter Azure Kubernetes Service.
AKS ist zwar eine vollständig verwaltete Lösung, bietet aber keine integrierte Lösung, um den ein- und ausgehenden Datenverkehr zwischen dem Cluster und externen Netzwerken zu schützen. Azure Firewall bietet dafür eine Lösung.
AKS-Cluster werden in einem virtuellen Netzwerk bereitgestellt. Dabei kann es sich um ein verwaltetes (von AKS erstelltes) Netzwerk oder um ein benutzerdefiniertes (durch den Benutzer vorkonfiguriertes) Netzwerk handeln. In beiden Fällen sind für den Cluster ausgehende Abhängigkeiten von Diensten außerhalb des virtuellen Netzwerks vorhanden. (Eingehende Abhängigkeiten sind für den Dienst nicht vorhanden.) Zu Verwaltungs- und Betriebszwecken müssen Knoten in einem AKS-Cluster auf bestimmte Ports und vollqualifizierte Domänennamen (FQDNs) zugreifen, die diese ausgehenden Abhängigkeiten beschreiben. Dies ist für verschiedene Funktionen erforderlich, einschließlich, aber nicht beschränkt auf die Knoten, die mit dem Kubernetes-API-Server kommunizieren. Sie laden Kernkomponenten des Kubernetes-Clusters und Sicherheitsupdates für Knoten herunter und installieren sie oder pullen Containerimages des Basissystems aus Microsoft Container Registry (MCR) usw. Diese Abhängigkeiten für ausgehenden Datenverkehr werden fast ausschließlich mit FQDNs definiert, hinter denen sich keine statischen Adressen befinden. Das Fehlen statischer Adressen bedeutet, dass keine Netzwerksicherheitsgruppen verwendet werden können, um den ausgehenden Datenverkehr eines AKS-Clusters zu sperren. Aus diesem Grund haben AKS-Cluster standardmäßig uneingeschränkten ausgehenden Internetzugriff. Diese Ebene des Netzwerkzugriffs ermöglicht, dass ausgeführte Knoten und Dienste nach Bedarf auf externe Ressourcen zugreifen können.
In einer Produktionsumgebung sollte die Kommunikation mit einem Kubernetes-Cluster jedoch geschützt werden, um Datenexfiltration sowie andere Sicherheitsrisiken zu verhindern. Der gesamte eingehende und ausgehende Netzwerkdatenverkehr muss auf Grundlage verschiedener Sicherheitsregeln überwacht und gesteuert werden. Dafür müssen Sie den ausgehenden Datenverkehr einschränken. Eine begrenzte Anzahl von Ports und Adressen muss jedoch zugänglich bleiben, um Wartungsaufgaben für einen fehlerfreien Clusterbetrieb ausführen zu können und diesen zuvor erwähnten Abhängigkeiten für ausgehenden Datenverkehr gerecht zu werden.
Die einfachste Lösung besteht in der Verwendung eines Firewallgeräts, das den ausgehenden Datenverkehr auf der Grundlage von Domänennamen kontrolliert. Eine Firewall errichtet normalerweise eine Barriere zwischen einem vertrauenswürdigen Netzwerk und einem nicht vertrauenswürdigen Netzwerk wie dem Internet. Von Azure Firewall kann beispielsweise ausgehender HTTP- und HTTPS-Datenverkehr auf der Grundlage des FQDN des Ziels eingeschränkt werden. Dadurch können Sie ausgehenden Datenverkehr präzise steuern, gleichzeitig aber den Zugriff auf die FQDNs ermöglichen, die die ausgehenden Abhängigkeiten eines AKS-Clusters umfassen. (Dies ist mit NSGs nicht möglich.) Ebenso können Sie eingehenden Datenverkehr steuern und die Sicherheit verbessern, indem Sie eine auf Threat Intelligence basierende Filterung in einer Azure Firewall-Instanz aktivieren, die in einem gemeinsam genutzten Umkreisnetzwerk bereitgestellt wird. Diese Filterung kann Warnungen ausgeben und den Datenverkehr zu und von bekannten schädlichen IP-Adressen und Domänen verweigern.
Im folgenden Video von Abhinav Sriram erhalten Sie einen kurzen Überblick darüber, wie dies in der Praxis in einer Beispielumgebung funktioniert:
Sie können eine ZIP-Datei aus dem Microsoft Download Center herunterladen, die eine Bash-Skriptdatei und eine YAML-Datei enthält, um die im Video verwendete Beispielumgebung automatisch zu konfigurieren. Azure Firewall wird so konfiguriert, dass sowohl der eingehende als auch der ausgehende Datenverkehr geschützt wird. In den folgenden Anleitungen werden die einzelnen Schritte des Skripts ausführlicher erläutert, damit Sie eine benutzerdefinierte Konfiguration einrichten können.
Das folgende Diagramm zeigt die Beispielumgebung aus dem Video, die vom Skript und von der Anleitung konfiguriert wird:
Es gibt einen Unterschied zwischen dem Skript und dem folgenden Leitfaden. Das Skript verwendet verwaltete Identitäten, der Leitfaden hingegen einen Dienstprinzipal. So lernen Sie zwei verschiedene Möglichkeiten zum Erstellen einer Identität zum Verwalten und Erstellen von Clusterressourcen kennen.
Einschränken von ausgehendem Datenverkehr mithilfe von Azure Firewall
Festlegen der Konfiguration mit Umgebungsvariablen
Definieren Sie eine Reihe von Umgebungsvariablen, die bei der Erstellung von Ressourcen verwendet werden können.
PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"
Erstellen eines virtuellen Netzwerks mit mehreren Subnetzen
Stellen Sie ein virtuelles Netzwerk mit zwei separaten Subnetzen bereit: eins für den Cluster und eins für die Firewall. Optional kann auch noch ein Subnetz für internen eingehenden Dienstdatenverkehr erstellt werden.
Erstellen Sie eine Ressourcengruppe für alle Ressourcen.
# Create Resource Group
az group create --name $RG --location $LOC
Erstellen Sie ein virtuelles Netzwerk mit zwei Subnetzen zum Hosten des AKS-Clusters und der Azure Firewall-Instanz. Jedes verfügt über ein eigenes Subnetz. Beginnen wir mit dem AKS-Netzwerk.
# Dedicated virtual network with AKS subnet
az network vnet create \
--resource-group $RG \
--name $VNET_NAME \
--location $LOC \
--address-prefixes 10.42.0.0/16 \
--subnet-name $AKSSUBNET_NAME \
--subnet-prefix 10.42.1.0/24
# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)
az network vnet subnet create \
--resource-group $RG \
--vnet-name $VNET_NAME \
--name $FWSUBNET_NAME \
--address-prefix 10.42.2.0/24
Erstellen und Einrichten einer Azure Firewall-Instanz mit einer benutzerdefinierten Route
Für Azure Firewall müssen Eingangs- und Ausgangsregeln konfiguriert werden. Die Firewall dient hauptsächlich dazu, Organisationen das Konfigurieren von differenzierten Regeln für ein- und ausgehenden Datenverkehr in den und aus dem AKS-Cluster zu ermöglichen.
Wichtig
Wenn durch Ihren Cluster oder Ihre Anwendung eine große Anzahl von ausgehenden Verbindungen erstellt wird, die jeweils das gleiche Ziel oder eine kleine Teilmenge von Zielen haben, sind unter Umständen mehr Front-End-IP-Adressen für die Firewall erforderlich, um eine Überschreitung der Portkapazität pro Front-End-IP-Adresse zu vermeiden. Weitere Informationen zum Erstellen einer Azure Firewall-Instanz mit mehreren IP-Adressen finden Sie hier.
Erstellen Sie eine öffentliche IP-Adressressource mit einer Standard-SKU, die als Front-End-Adresse für Azure Firewall verwendet wird.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Registrieren Sie die Azure CLI Preview-Erweiterung, um eine Azure Firewall-Instanz zu erstellen.
# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
Die erstellte IP-Adresse kann jetzt dem Firewall-Front-End zugewiesen werden.
Hinweis
Das Einrichten der öffentlichen IP-Adresse für die Azure Firewall-Instanz kann einige Minuten dauern. Um die FQDN-Nutzung in Netzwerkregeln zu ermöglichen, muss der DNS-Proxy aktiviert werden. Bei aktiviertem DNS-Proxy lauscht die Firewall am Port 53 und leitet DNS-Anforderungen an den zuvor angegebenen DNS-Server weiter. Dadurch kann der FQDN von der Firewall automatisch übersetzt werden.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME
Wenn der oben stehende Befehl erfolgreich ausgeführt wurde, speichern Sie die IP-Adresse des Firewall-Front-Ends zur späteren Konfiguration.
# Capture Firewall IP Address for Later Use
FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
Hinweis
Wenn Sie den sicheren Zugriff auf den AKS-API-Server mit autorisierten IP-Adressbereichen verwenden, müssen Sie die öffentliche IP-Adresse der Firewall zum autorisierten IP-Adressbereich hinzufügen.
Erstellen einer benutzerdefinierten Route mit einem Hop zu Azure Firewall
Azure führt für Datenverkehr automatisch das Routing zwischen Azure-Subnetzen, virtuellen Netzwerken und lokalen Netzwerken durch. Wenn Sie das Standardrouting von Azure ändern möchten, erstellen Sie eine Routingtabelle.
Erstellen Sie eine leere Routingtabelle, die einem bestimmten Subnetz zugeordnet werden kann. Die Routingtabelle definiert die zuvor erstellte Azure Firewall-Instanz als nächsten Hop. Jedem Subnetz können null oder mehr Routentabellen zugeordnet sein.
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
Informationen zum Außerkraftsetzen der Standardsystemrouten von Azure sowie zum Hinzufügen zusätzlicher Routen zur Routingtabelle eines Subnetzes finden Sie in der Dokumentation zu Routingtabellen für virtuelle Netzwerke.
Hinzufügen von Firewallregeln
Hinweis
Für Anwendungen außerhalb der Namespaces „kube-system“ oder „gatekeeper-system“, die mit dem API-Server kommunizieren müssen, muss nicht nur eine Anwendungsregel für das FQDN-Tag „AzureKubernetesService“, sondern auch eine zusätzliche Netzwerkregel hinzugefügt werden, um die TCP-Kommunikation mit Port 443 für die API-Server-IP zuzulassen.
Sie können die folgenden drei Netzwerkregeln verwenden, um Ihre Firewall zu konfigurieren. Möglicherweise müssen Sie diese Regeln basierend auf Ihrer Bereitstellung anpassen. Mit der ersten Regel wird der Zugriff auf den Port 9000 über TCP zugelassen. Mit der zweiten Regel wird der Zugriff auf Port 1194 und 123 über UDP zugelassen. Durch beide Regeln wird jeweils nur Datenverkehr zugelassen, der für das klassenlose domänenübergreifende Routing der verwendeten Azure-Region (in diesem Fall „USA, Osten“) bestimmt ist.
Zum Schluss fügen wir eine dritte Netzwerkregel hinzu, die Port 123 über UDP für den FQDN eines Internetzeitservers (Beispiel: ntp.ubuntu.com) öffnet. Das Hinzufügen eines FQDN als Netzwerkregel ist eines der besonderen Features von Azure Firewall, und Sie müssen es anpassen, wenn Sie eigene Optionen verwenden.
Nach dem Festlegen der Netzwerkregeln wird außerdem eine Anwendungsregel mit AzureKubernetesService hinzugefügt, um die benötigten FQDNs abzudecken, auf die über den TCP-Port 443 und den Port 80 zugegriffen werden kann. Darüber hinaus müssen Sie möglicherweise abhängig von Ihrer Bereitstellung zusätzliche Netzwerk- und Anwendungsregeln konfigurieren. Weitere Informationen finden Sie unter Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service-Cluster (AKS).
Hinzufügen von FW-Netzwerkregeln
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
Hinzufügen von FW-Anwendungsregeln
az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
Weitere Informationen zum Azure Firewall-Dienst finden Sie in der Azure Firewall-Dokumentation.
Zuordnen der Routingtabelle zu AKS
Um den Cluster der Firewall zuzuordnen, muss das dedizierte Subnetz für das Subnetz des Clusters auf die zuvor erstellte Routingtabelle verweisen. Zur Zuordnung geben Sie einen Befehl zum Aktualisieren der Routingtabelle des Clustersubnetzes an das virtuelle Netzwerk aus, in dem sich sowohl der Cluster als auch die Firewall befinden.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME
Bereitstellen von AKS mit dem ausgehenden Typ „UDR“ im vorhandenen Netzwerk
Jetzt kann ein AKS-Cluster im vorhandenen virtuellen Netzwerk bereitgestellt werden. Darüber hinaus wird der ausgehende Typ userDefinedRouting verwendet. Durch dieses Feature wird sichergestellt, dass ausgehender Datenverkehr die Firewall durchlaufen muss und keine anderen Ausgangspfade vorhanden sind. (Standardmäßig kann der ausgehende Typ „Lastenausgleich“ verwendet werden).
Das Zielsubnetz, in dem die Bereitstellung erfolgen soll, wird mit der Umgebungsvariable $SUBNETID definiert. In den vorherigen Schritten wurde die $SUBNETID-Variable nicht definiert. Zum Festlegen des Werts für die Subnetz-ID können Sie den folgenden Befehl verwenden:
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
Sie definieren den ausgehenden Typ für die Verwendung der benutzerdefinierten Route, die bereits im Subnetz vorhanden ist. Diese Konfiguration ermöglicht es AKS, die Einrichtung und die IP-Adressbereitstellung für den Lastenausgleich zu überspringen.
Wichtig
Weitere Informationen zum ausgehenden Typ „UDR“ sowie zu den damit verbundenen Einschränkungen finden Sie unter Einschränkungen.
Tipp
Der Clusterbereitstellung können weitere Features hinzugefügt werden – beispielsweise private Cluster oder das Ändern der Betriebssystem-SKU.
Das AKS-Feature für vom API-Server autorisierte IP-Adressbereiche kann hinzugefügt werden, um den Zugriff des API-Servers auf den öffentlichen Endpunkt der Firewall zu beschränken. Das Feature für autorisierte IP-Adressbereiche ist im Diagramm als optional gekennzeichnet. Wenn Sie das Feature für autorisierte IP-Adressbereiche verwenden, um den API-Serverzugriff einzuschränken, müssen Ihre Entwicklertools eine Jumpbox für das virtuelle Netzwerk der Firewall verwenden, oder Sie müssen alle Entwicklerendpunkte zum autorisierten IP-Adressbereich hinzufügen.
az aks create -g $RG -n $AKSNAME -l $LOC \
--node-count 3 \
--network-plugin azure \
--outbound-type userDefinedRouting \
--vnet-subnet-id $SUBNETID \
--api-server-authorized-ip-ranges $FWPUBLIC_IP
Hinweis
Um ein eigenes VNet und eine Routingtabelle mit kubenet-Netzwerk-Plug-In zu erstellen und zu verwenden, müssen Sie die benutzerseitig zugewiesene verwaltete Identität verwenden. Für die systemseitig zugewiesene verwaltete Identität kann die Identitäts-ID nicht vor dem Erstellen des Clusters abgerufen werden, wodurch die Rollenzuweisung verzögert wird.
Um ein eigenes VNet und eine Routingtabelle mit azure-Netzwerk-Plug-In zu erstellen und zu verwenden, werden sowohl systemseitig zugewiesene als auch benutzerseitig zugewiesene verwaltete Identitäten unterstützt.
Ermöglichen des Entwicklerzugriffs auf den API-Server
Falls Sie im vorherigen Schritt autorisierte IP-Adressbereiche für den Cluster verwendet haben, müssen Sie die IP-Adressen Ihrer Entwicklertools der AKS-Clusterliste mit den genehmigten IP-Adressbereichen hinzufügen, um von dort aus auf den API-Server zugreifen zu können. Eine andere Möglichkeit besteht darin, in einem separaten Subnetz innerhalb des virtuellen Netzwerks von Azure Firewall eine Jumpbox mit den erforderlichen Tools zu konfigurieren.
Mit dem folgenden Befehl fügen Sie dem Bereich der genehmigten IP-Adressen eine weitere Adresse hinzu.
# Retrieve your IP address
CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Mit dem Befehl az aks get-credentials können Sie kubectl für das Herstellen einer Verbindung mit Ihrem neu erstellten Kubernetes-Cluster konfigurieren.
az aks get-credentials -g $RG -n $AKSNAME
Einschränken von eingehendem Datenverkehr mithilfe von Azure Firewall
Nun können Sie damit beginnen, Dienste verfügbar zu machen und Anwendungen in diesem Cluster bereitzustellen. In diesem Beispiel machen wir einen öffentlichen Dienst verfügbar. Sie können aber auch einen internen Dienst über den internen Lastenausgleich verfügbar machen.
Stellen Sie die Azure-Abstimmungs-App bereit, indem Sie den folgenden YAML in eine Datei namens example.yaml kopieren.
# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-storage
spec:
replicas: 1
selector:
matchLabels:
app: voting-storage
template:
metadata:
labels:
app: voting-storage
spec:
containers:
- name: voting-storage
image: mcr.microsoft.com/azuredocs/voting/storage:2.0
args: ["--ignore-db-dir=lost+found"]
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: voting-storage-secret
type: Opaque
data:
MYSQL_USER: ZGJ1c2Vy
MYSQL_PASSWORD: UGFzc3dvcmQxMg==
MYSQL_DATABASE: YXp1cmV2b3Rl
MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-storage
labels:
app: voting-storage
spec:
ports:
- port: 3306
name: mysql
selector:
app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app
spec:
replicas: 1
selector:
matchLabels:
app: voting-app
template:
metadata:
labels:
app: voting-app
spec:
containers:
- name: voting-app
image: mcr.microsoft.com/azuredocs/voting/app:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
- name: ANALYTICS_HOST
value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-app
labels:
app: voting-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: voting-app
---
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-analytics
spec:
replicas: 1
selector:
matchLabels:
app: voting-analytics
version: "2.0"
template:
metadata:
labels:
app: voting-analytics
version: "2.0"
spec:
containers:
- name: voting-analytics
image: mcr.microsoft.com/azuredocs/voting/analytics:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-analytics
labels:
app: voting-analytics
spec:
ports:
- port: 8080
name: http
selector:
app: voting-analytics
Stellen Sie den Dienst bereit, indem Sie Folgendes ausführen:
kubectl apply -f example.yaml
Hinzufügen einer DNAT-Regel zu Azure Firewall
Wichtig
Wenn Sie Azure Firewall verwenden, um ausgehenden Datenverkehr einzuschränken, und eine benutzerdefinierte Route (UDR) erstellen, um den gesamten ausgehenden Datenverkehr zu erzwingen, stellen Sie sicher, dass Sie in der Firewall eine entsprechende DNAT-Regel erstellen, um ausgehenden Datenverkehr zuzulassen. Durch die Verwendung von Azure Firewall mit einer UDR wird das Setup für eingehenden Datenverkehr aufgrund von asymmetrischem Routing unterbrochen. (Das Problem tritt auf, wenn das AKS-Subnetz über eine Standardroute verfügt, die zur privaten IP-Adresse der Firewall wechselt, Sie aber einen öffentlichen Load Balancer verwenden – Eingangs- oder Kubernetes-Dienst vom Typ LoadBalancer). In diesem Fall wird der eingehende Load Balancer-Datenverkehr über die öffentliche IP-Adresse empfangen, während der Rückpfad über die private IP-Adresse der Firewall verläuft. Die Firewall löscht das zurückgegebene Paket, weil sie zustandsbehaftet ist und nichts über eine vorhandene Sitzung weiß. Informationen zur Integration von Azure Firewall in ihren Eingangs- oder Service Dienst-Load Balancer finden Sie unter Integrieren von Azure Firewall mit Azure Load Balancer Standard.
Um die eingehende Konnektivität zu konfigurieren, muss eine DNAT-Regel für die Azure Firewall-Instanz geschrieben werden. Zum Testen der Konnektivität mit dem Cluster wird eine Regel definiert, durch die die öffentliche IP-Adresse des Firewall-Front-Ends an die interne IP-Adresse weitergeleitet wird, die durch den internen Dienst verfügbar gemacht wird.
Die Zieladresse kann angepasst werden, da es sich um den Port in der Firewall handelt, auf den zugegriffen werden soll. Die übersetzte Adresse muss die IP-Adresse des internen Lastenausgleichs sein. Der übersetzte Port muss der verfügbar gemachte Port für Ihren Kubernetes-Dienst sein.
Sie müssen die interne IP-Adresse angeben, die der vom Kubernetes-Dienst erstellten Lastenausgleichsressource zugewiesen wurde. Rufen Sie die Adresse ab, indem Sie Folgendes ausführen:
kubectl get services
Die erforderliche IP-Adresse wird in der Spalte „EXTERNAL-IP“ aufgeführt, ähnlich wie im folgenden Beispiel.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m
voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m
voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m
Führen Sie den folgenden Befehl aus, um die IP-Adresse des Diensts abzurufen:
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Führen Sie den folgenden Befehl aus, um die NAT-Regel hinzuzufügen:
az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
Überprüfen der Konnektivität
Navigieren Sie in einem Browser zur IP-Adresse des Azure Firewall-Front-Ends, um die Konnektivität zu überprüfen.
Die AKS-Abstimmungs-App sollte angezeigt werden. In diesem Beispiel lautete die öffentliche IP-Adresse der Firewall 52.253.228.132.
Bereinigen von Ressourcen
Um die Azure-Ressourcen zu bereinigen, löschen Sie die AKS-Ressourcengruppe.
az group delete -g $RG
Nächste Schritte
- Weitere Informationen zu Azure Kubernetes Service finden Sie unter Grundlegende Kubernetes-Konzepte für Azure Kubernetes Service (AKS).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für