Bewährte Methoden für Netzwerkkonnektivität und Sicherheit in Azure Kubernetes Service (AKS)

Beim Erstellen und Verwalten von Clustern in Azure Kubernetes Service (AKS) stellen Sie netzwerkkonnektivität für Ihre Knoten und Anwendungen bereit. Die Netzwerkressourcen umfassen IP-Adressbereiche, Load-Balancer und Ingress-Controller.

In diesem Artikel zu bewährten Methoden liegt der Schwerpunkt auf der Netzwerkkonnektivität und der Sicherheit für Clusteroperatoren. In diesem Artikel werden folgende Vorgehensweisen behandelt:

Auswählen des geeigneten Netzwerkmodells

Best Practices-Leitfaden

Verwenden Sie Azure CNI-Überlagerung für die meisten Szenarien. Wenn Workloads direkten Pod-IP-Zugriff über verbundene Netzwerke erfordern, verwenden Sie ein flaches Netzwerk mit Azure CNI-Pod-Subnetz.

Virtuelle Netzwerke bieten die grundlegende Konnektivität für AKS-Knoten und Kunden für den Zugriff auf Ihre Anwendungen. Es gibt zwei verschiedene Möglichkeiten, AKS-Cluster in virtuellen Netzwerken bereitzustellen:

• Overlay-Netzwerk: Azure CNI Overlay weist Pod-IP-Adressen aus einem separaten Pod-CIDR zu. Datenverkehr, der den Cluster verlässt, wird in die IP-Adresse des Knotens übersetzt, und Pods sind nicht direkt über ihre privaten IP-Adressen aus verbundenen Netzwerken zugänglich.
• Flaches Netzwerk: Azure CNI Pod Subnet oder legacy Azure CNI Node Subnet weist Pod-IP-Adressen aus dem virtuellen Netzwerkraum zu. Pods können über ihre privaten IP-Adressen aus verbundenen Netzwerken erreicht werden.

Weitere Informationen zum Auswählen eines Netzwerkmodells finden Sie unter Plan pod networking for AKS.

Azure CNI-Netzwerkübersicht

Azure CNI bietet IP-Adressverwaltung (IPAM) und Konnektivität für Pods und Knoten. Die IPAM-Option ist von der Netzwerkdatenebene getrennt. Sie können z. B. Azure CNI unterstützt von Cilium mit Azure CNI Overlay oder einer Flat-Network-Option verwenden.

Das folgende Diagramm zeigt zwei AKS-Knoten, die jeweils über eine Netzwerkbrücke mit einem freigegebenen Azure virtuellen Netzwerk verbunden sind.

Azure CNI-Vernetzung ermöglicht die Trennung von Kontrolle und Verwaltung von Ressourcen. Aus Sicherheitssicht möchten Sie diese Ressourcen oft von verschiedenen Teams verwalten und absichern lassen. Die Konnektivitätsmerkmale hängen vom Netzwerkmodell ab. Overlay-Pods stellen über die IP-Adresse des Knotens Verbindungen zu dem virtuellen Netzwerk und lokalen Ressourcen her. Flat-Network-Pods können über ihre privaten IP-Adressen direkt mit verbundenen Ressourcen kommunizieren.

Wenn Sie Azure CNI-Netzwerk verwenden, befindet sich die virtuelle Netzwerkressource in einer separaten Ressourcengruppe zum AKS-Cluster. Delegieren Sie Berechtigungen für die AKS-Clusteridentität, um auf diese Ressourcen zugreifen und sie verwalten zu können. Die vom AKS-Cluster verwendete Clusteridentität muss mindestens Berechtigungen Netzwerkmitwirkender für das Subnetz in Ihrem virtuellen Netzwerk haben.

Wenn Sie eine benutzerdefinierte Rolle anstelle der integrierten Rolle des Netzwerkmitwirkenden definieren möchten, sind die folgenden Berechtigungen erforderlich:

Standardmäßig verwendet AKS eine verwaltete Identität als Clusteridentität. Sie können stattdessen jedoch auch einen Dienstprinzipal verwenden.

• Weitere Informationen zur AKS-Dienstprinzipaldelegierung finden Sie unter Zugriff auf andere Azure-Ressourcen delegieren.
• Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwenden verwalteter Identitäten.

Planen Sie Adressbereiche basierend auf dem Netzwerkmodell. Berücksichtigen Sie folgende Kriterien:

• Mit Azure CNI Overlay dimensionieren Sie das Knotensubnetz für die Knoten und verwenden einen separaten privaten CIDR-Bereich für Pods. Jeder Knoten erhält einen /24-Adressraum aus dem Pod-CIDR.
• Bei einem flachen Netzwerk können Sie die Größe der virtuellen Netzwerksubnetze sowohl für Knoten als auch für Pods festlegen. Azure CNI Pod Subnet verwendet getrennte Knoten- und Pod-Subnetze, während das ältere Azure CNI Node Subnet ein Subnetz für beides verwendet.
• Vermeiden Sie die Verwendung von IP-Adressbereichen, die sich mit vorhandenen Netzwerkressourcen überschneiden.
  • Es ist erforderlich, die Konnektivität mit lokalen oder peerierten Netzwerken in Azure zuzulassen.
• Um Skalierungsereignisse oder Clusterupgrades zu behandeln, benötigen Sie zusätzliche IP-Adressen, die im zugewiesenen Subnetz verfügbar sind.
  • Dieser zusätzliche Adressraum ist besonders wichtig, wenn Sie Windows Server Container verwenden, da für diese Knotenpools ein Upgrade erforderlich ist, um die neuesten Sicherheitspatches anzuwenden. Weitere Informationen zu Windows Server Knoten finden Sie unter Upgrade eines Knotenpools in AKS.

Informationen zum Berechnen des erforderlichen IP-Adressraums finden Sie unter IP-Adressplanung für AKS-Cluster.

Beim Erstellen eines Clusters mit Azure CNI-Netzwerk geben Sie andere Adressbereiche für den Cluster an, z. B. den IP- und Dienstadressbereich des DNS-Diensts. Stellen Sie allgemein sicher, dass sich diese Adressbereiche weder gegenseitig noch mit den dem Cluster zugeordneten Netzwerken überschneiden, einschließlich aller virtuellen Netzwerke, Subnetze, lokalen Netzwerke und per Peering verbundenen Netzwerke.

Ausführliche Informationen zu Netzwerkmodellen, Grenzwerten und Adressanpassungen finden Sie unter Azure CNI-Netzwerkübersicht.

Verteilen des Eingangsdatenverkehrs

Best Practices-Leitfaden

Um HTTP- oder HTTPS-Datenverkehr an Ihre Anwendungen zu verteilen, verwenden Sie Eingangsressourcen und -controller. Im Vergleich zu einem Azure Lastenausgleich bieten Eingangscontroller zusätzliche Features und können als systemeigene Kubernetes-Ressourcen verwaltet werden.

Während ein Azure Load Balancer Kundendatenverkehr an Anwendungen in Ihrem AKS-Cluster verteilen kann, hat er beschränkte Fähigkeiten, diesen Datenverkehr zu verstehen. Eine Lastenausgleichsressource wird auf Ebene 4 ausgeführt und verteilt den Datenverkehr basierend auf dem Protokoll oder den Ports.

Die meisten Webanwendungen, die HTTP oder HTTPS verwenden, sollten Kubernetes-Eingangsressourcen und -controller verwenden, die auf Ebene 7 ausgeführt werden. Ingress kann den Datenverkehr basierend auf der URL der Anwendung verteilen und die TLS/SSL-Terminierung verwalten. Ingress reduziert auch die Anzahl der IP-Adressen, die Sie offenlegen und abbilden.

Bei einem Load Balancer benötigt jede Anwendung typischerweise eine öffentliche IP-Adresse, die dem Dienst im AKS-Cluster zugewiesen und zugeordnet wird. Bei Verwendung einer Eingangsressource kann eine einzige IP-Adresse den Datenverkehr auf mehrere Anwendungen verteilen.

Das Diagramm zeigt eine einzelne öffentliche IP-Adresse, die externen Datenverkehr empfängt, und einen Eingangscontroller, der diesen Datenverkehr an mehrere Dienste im AKS-Cluster verteilt.

Ingress weist zwei Komponenten auf: eine Eingangsressource und einen Eingangscontroller.

Eingangsressource

Die Eingangsressource ist ein YAML-Manifest von kind: Ingress. Sie definiert den Host, die Zertifikate und die Regeln zum Weiterleiten des Datenverkehrs an die Dienste, die in Ihrem AKS-Cluster ausgeführt werden.

Im folgenden Beispiel-YAML-Manifest wird die verwaltete NGINX Ingress-Klasse des Anwendungsrouting-Add-Ons verwendet. Er verteilt Datenverkehr für myapp.com auf einen von zwei Diensten, Blogservice oder Storeservice und leitet den Kunden basierend auf der url, auf die er zugreift, an einen Dienst oder den anderen weiter.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Das ingressClassName Feld wählt die Eingangsklasse aus und muss mit einer Klasse übereinstimmen, die auf einem Eingangscontroller im Cluster konfiguriert ist. Der Wert webapprouting.kubernetes.azure.com wählt den verwalteten NGINX-Eingangscontroller aus, der vom Anwendungsrouting-Add-On bereitgestellt wird. Ersetzen Sie ihn durch den Klassennamen für den Eingangscontroller, wenn Sie eine andere Implementierung verwenden.

Eingangscontroller

Ein vom Cluster gehosteter Eingangscontroller wird als Workload auf einem AKS-Knoten ausgeführt und überwacht eingehende Anforderungen. Eingehender Datenverkehr wird dann basierend auf den Regeln verteilt, die in der dem Controller zugeordneten Eingangsressource definiert sind. Während der gängigste Eingangscontroller auf NGINX basiert, beschränkt AKS Sie nicht auf einen bestimmten Controller. Sie können Anwendungsgateway für Container, Contour, HAProxy, Traefik und andere verwenden.

Sie müssen clustergehostete Ingress-Controller auf einem Linux-Knoten platzieren. Geben Sie an, dass die Ressource auf einem Linux-basierten Knoten ausgeführt werden soll, indem Sie eine Knotenauswahl in Ihrem YAML-Manifest oder in der Helm-Diagrammbereitstellung verwenden. Weitere Informationen finden Sie unter Verwenden von Knotenselektoren, um zu steuern, wo Pods in AKS geplant werden.

Ingress mit dem Add-On für Anwendungsrouting

Das Anwendungsrouting-Add-On stellt verwaltete Eingangsimplementierungen für AKS bereit. Verwenden Sie für neue, langlebige Bereitstellungen die Gateway-API-Implementierung für Anwendungsrouting, wenn sie Ihre Anforderungen unterstützt. Die Gateway-API ist der langfristige Standard für Kubernetes-Ingress- und Layer 7-Datenverkehrsmanagement.

Die verwaltete NGINX-Implementierung bietet die folgenden Features:

• Einfache Konfiguration von verwalteten NGINX-Ingress-Controllern basierend auf dem Kubernetes NGINX Ingress-Controller.
• Integration mit Azure DNS für die Verwaltung öffentlicher und privater Zonen.
• SSL-Beendigung mit Zertifikaten, die in Azure Key Vault gespeichert sind.

Weitere Informationen finden Sie unter Ingress mit der Gateway-API für Anwendungsrouting konfigurieren und Verwalteter NGINX-Ingress mit dem Add-On für Anwendungsrouting.

Absichern des Datenverkehrs mit einer Web Application Firewall (WAF)

Best Practices-Leitfaden

Um eingehenden Datenverkehr auf potenzielle Angriffe zu überprüfen, verwenden Sie eine Webanwendungsfirewall (WAF), z. B. Barracuda WAF für Azure oder Azure Web Application Firewall auf Dem Anwendungsgateway für Container. Application Gateway für Container leitet HTTP-, HTTPS-, gRPC-, WebSocket- und KI-Inferenzdatenverkehr weiter und unterstützt TLS-Terminierung.

Ein vom Cluster gehosteter Eingangscontroller wird als Kubernetes-Workload in Ihrem AKS-Cluster ausgeführt und verteilt Datenverkehr an Dienste und Anwendungen. Es verbraucht einige der Ressourcen des Knotens, z. B. CPU, Arbeitsspeicher und Netzwerkbandbreite. In größeren Umgebungen sollten Sie folgendes berücksichtigen:

• Sie können einen Teil dieses Datenverkehrsroutings oder der TLS-Terminierung auf eine Netzwerkressource außerhalb des AKS-Clusters auslagern.
• Sie können eingehenden Datenverkehr auf potenzielle Angriffe überprüfen.

Das Diagramm veranschaulicht, wie externer Datenverkehr über Azure Application Gateway for Containers geleitet wird. Wenn WAF-Schutz konfiguriert ist, filtern WAF-Regeln Anfragen, bevor das Application Gateway for Containers den zulässigen Datenverkehr an Dienste im AKS-Cluster weiterleitet.

Für diese zusätzliche Sicherheitsebene filtert eine Webanwendungsfirewall (WAF) eingehenden Datenverkehr. Verwaltete und benutzerdefinierte Regeln schützen vor Angriffen wie websiteübergreifendes Skripting und SQL-Einfügung. Das Anwendungsgateway für Container ist ein Lastenausgleichs- und Datenverkehrsverwaltungsdienst der Ebene 7, der Azure WAF unterstützt.

DER WAF-Schutz ist nicht durch die Bereitstellung des Anwendungsgateways für Container allein aktiviert. Sie müssen eine WAF-Richtlinie erstellen und beide der folgenden Konfigurationen ausführen, bevor WAF Datenverkehr prüft:

• Erstellen Sie eine Azure SecurityPolicy untergeordnete Ressource, die auf die WAF-Richtlinie verweist.
• Wenden Sie eine benutzerdefinierte Kubernetes-Ressource WebApplicationFirewallPolicy an, die auf dieselbe WAF-Richtlinie verweist und auf die Ressource HTTPRoute oder Gateway abzielt, die geschützt werden soll.

Überprüfen Sie nach Abschluss beider Konfigurationen den benutzerdefinierten Ressourcenstatus und die WAF-Protokolle, bevor Sie sich auf die Richtlinie für den Schutz verlassen. Weitere Informationen finden Sie unter Azure Web Application Firewall für Anwendungsgateway für Container.

Da auch andere Lösungen von Drittanbietern diese Funktionen bieten, können Sie bestehende Investitionen in Ihr bevorzugtes Produkt oder vorhandenes Know-how weiterhin nutzen.

Load Balancer oder Eingangsressourcen werden in Ihrem AKS-Cluster weiterhin ausgeführt und optimieren die Verteilung des Datenverkehrs. Azure Application Gateway für Container kann zentral als Eingangscontroller mit einer Ressourcendefinition verwaltet werden. Erstellen Sie zunächst ein Anwendungsgateway für Container, und konfigurieren Sie dann den WAF-Schutz separat.

Steuern des Datenverkehrsflusses mit Netzwerkrichtlinien

Best Practices-Leitfaden

Verwenden Sie Netzwerkrichtlinien, um den Datenverkehr für Pods zuzulassen oder zu verweigern. Standardmäßig ist der gesamte Datenverkehr zwischen den Pods in einem Cluster zulässig. Aus Sicherheitsgründen sollten Sie Regeln definieren, um die Kommunikation zwischen den Pods einzuschränken.

Netzwerkrichtlinien sind ein in AKS verfügbares Kubernetes-Feature, mit dem Sie den Datenverkehrsfluss zwischen Pods steuern können. Sie erlauben oder verweigern den Datenverkehr an den Pod basierend auf Einstellungen wie zugewiesenen Bezeichnungen, Namespaces oder Datenverkehrsport. Netzwerkrichtlinien sind eine cloudnative Möglichkeit, den Datenverkehrsfluss für Pods zu steuern. Wenn Pods in einem AKS-Cluster dynamisch erstellt werden, können automatisch die erforderlichen Netzwerkrichtlinien angewendet werden.

Um Netzwerkrichtlinien in AKS zu verwenden, wählen Sie ein Netzwerkrichtlinienmodul aus, das Ihre Knotenbetriebssysteme und netzwerkdatenebene unterstützt. Sie können ein Richtlinienmodul während der Clustererstellung oder auf einem vorhandenen unterstützten Cluster aktivieren.

Verwenden Sie für Linux-Knotenpools Azure CNI mit Cilium-Unterstützung und die integrierte Durchsetzung von Cilium-Netzwerkrichtlinien. Cilium wird für Windows Knotenpools nicht unterstützt. Verwenden Sie Calico für Windows Workloads.

Sie erstellen eine Netzwerkrichtlinie mit einem YAML-Manifest als Kubernetes-Ressource. Richtlinien werden auf definierte Pods angewendet, wobei Eingangs- oder Ausgangsregeln den Datenverkehrsfluss definieren.

Im folgenden Beispiel wird eine Netzwerkrichtlinie auf Pods mit der zugewiesenen Bezeichnung app: backend angewendet. Die Ingressregel erlaubt nur Datenverkehr von Pods mit dem Label app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Um mit Richtlinien zu beginnen, lesen Sie Sicheren Datenverkehr zwischen Pods mithilfe von Netzwerkrichtlinien in Azure Kubernetes Service (AKS).

Optimieren der DNS-Auflösung mit LocalDNS

Best Practices-Leitfaden

Verwenden Sie LocalDNS, um die DNS-Leistung und -Zuverlässigkeit zu verbessern und die Last auf zentralisierten CoreDNS-Pods zu reduzieren. LocalDNS ist in AKS Automatic vorkonfiguriert. Aktivieren und konfigurieren Sie in AKS Standard LocalDNS pro Knotenpool.

LocalDNS stellt einen DNS-Proxy als systemd Dienst auf jedem Knoten bereit, um DNS-Abfragen lokal zu verarbeiten. Standardmäßig senden Pods alle DNS-Abfragen an zentralisierte CoreDNS-Pods. In großem Maßstab kann die Zentralisierung dieser Abfragen zu einem Engpass führen, während die lokale Auflösung Netzwerksprünge und die Latenz reduziert.

LocalDNS eliminiert auch conntrack Tabelleneinträge für den DNS-Verkehr und verhindert so die Erschöpfung der conntrack Tabelle und Racebedingungen, die zu Verbindungsabbrüchen führen können. Verbindungen vom lokalen Cache zu CoreDNS werden auf TCP aktualisiert, wodurch die Verbindungsrebalancing und eine schnellere Bereinigung von Nachverfolgungseinträgen ermöglicht werden.

Für Workloads, die eine hohe DNS-Verfügbarkeit erfordern, unterstützt LocalDNS die Bereitstellung veralteter zwischengespeicherter Antworten für eine konfigurierbare Dauer, wenn upstream DNS nicht verfügbar ist. Diese Best-Effort-Funktion kann dazu beitragen, die Pod-Konnektivität und Dienstzuverlässigkeit während vorübergehender DNS-Ausfälle aufrechtzuerhalten, garantiert jedoch nicht, dass ein veralteter Eintrag verfügbar ist.

Bei AKS Standard werden beim Aktivieren von LocalDNS für einen vorhandenen Knotenpool dessen Knoten neu aufgesetzt. Planen Sie den Rollout, um diese Unterbrechung zu berücksichtigen.

Weitere Informationen zur LocalDNS-Architektur und -Funktionen finden Sie unter DNS-Auflösung in AKS. Konfigurationsanweisungen finden Sie unter Configure LocalDNS.

Sichere Verbindung mit Knoten herstellen

Best Practices-Leitfaden

Machen Sie für Ihre AKS-Knoten keine Remotekonnektivität verfügbar. Für routinemäßige Problembehandlung bei Linux-Knoten verwenden Sie die Kubernetes-API.For routine Linux node troubleshooting, use kubectl debug through the Kubernetes API. Wenn Sie SSH-Zugriff benötigen, stellen Sie eine Verbindung über private Netzwerke oder Azure Bastion her.

Sie können die meisten Vorgänge in AKS ausführen, indem Sie Azure Verwaltungstools oder den Kubernetes-API-Server verwenden. AKS-Knoten sind nur in einem privaten Netzwerk verfügbar und sind nicht mit dem öffentlichen Internet verbunden. Verwenden Sie kubectl debug für Linux-Knoten, um einen privilegierten Debugcontainer über die Kubernetes-API zu starten. Bei diesem Ansatz ist keine direkte SSH-Verbindung mit dem Knoten erforderlich.

Wenn kubernetes-API-Zugriff nicht geeignet ist oder SIE SSH benötigen, verwenden Sie die private IP-Adresse des Knotens aus einem verbundenen Netzwerk. Azure Bastion können private Verbindungen bereitstellen, ohne eine öffentliche IP-Adresse auf dem Knoten verfügbar zu machen. Verwenden Sie für Windows Knoten einen Hostprozesscontainer oder stellen Sie eine Verbindung über einen Linux-Proxyknoten her. Azure Bastion ist eine Alternative, wenn der Proxyknoten nicht verfügbar ist. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit AKS-Clusterknoten zur Wartung oder Problembehandlung.

Das Diagramm veranschaulicht ein virtuelles Verwaltungsnetzwerk, das einen Bastionhost enthält, der Verbindungen über eine sichere Peerverbindung zum virtuellen AKS-Clusternetzwerk weiterleitet.

Wenn Sie einen Bastion-Host oder eine Jumpbox verwenden, platzieren Sie diese in einem separaten, sicher per Peering verbundenen virtuellen Verwaltungsnetzwerk. Sichern Sie das Verwaltungsnetzwerk mithilfe von Azure ExpressRoute oder einem VPN-Gateway, um eine Verbindung mit einem lokalen Netzwerk herzustellen und den Zugriff mit Netzwerksicherheitsgruppen zu steuern.

Nächste Schritte

Dieser Artikel konzentriert sich auf Netzwerkkonnektivität und Sicherheit. Weitere Informationen zu Den Netzwerkgrundlagen in Kubernetes finden Sie unter Network-Konzepte für Anwendungen in Azure Kubernetes Service (AKS)