Best Practices für GKE-Netzwerke

Auf dieser Seite werden die Best Practices für die Konfiguration von Netzwerkoptionen für Google Kubernetes Engine-Cluster (GKE) erläutert. Es ist ein Leitfaden für die Architekturplanung für Cloud-Architekten und Netzwerktechniker, der Empfehlungen für die Clusterkonfiguration enthält, die für die meisten GKE-Cluster anwendbar sind. Bevor Sie Ihre GKE-Cluster erstellen, empfehlen wir Ihnen, alle Abschnitte auf dieser Seite zu lesen, um die von GKE unterstützten Netzwerkoptionen und ihre Auswirkungen zu verstehen.

Die ausgewählten Netzwerkoptionen wirken sich auf die Architektur Ihrer GKE-Cluster aus. Einige dieser Optionen können nach der Konfiguration nicht mehr geändert werden, ohne den Cluster neu zu erstellen.

Machen Sie sich vor dem Lesen dieser Seite mit den Netzwerkkonzepten und der Netzwerkterminologie von Kubernetes, allgemeinen Netzwerkkonzepten und Kubernetes-Netzwerken vertraut. Weitere Informationen finden Sie in der GKE-Netzwerkübersicht.

Beachten Sie bei der Lektüre dieser Best Practices Folgendes:

• Wie Sie planen, Arbeitslasten intern auf Ihr VPC-Netzwerk (Virtual Private Cloud), andere Arbeitslasten im Cluster, andere GKE-Cluster oder extern auf das Internet zu übertragen.
• Wie Sie Ihre Arbeitslasten skalieren möchten.
• Welche Arten von Google-Diensten Sie in Anspruch nehmen möchten.

Eine zusammenfassende Checkliste mit den Best Practices finden Sie in der Zusammenfassung der Checkliste.

VPC-Design

Folgen Sie beim Entwerfen Ihrer VPC-Netzwerke den Best Practices für das VPC-Design.

Der folgende Abschnitt enthält einige GKE-spezifische Empfehlungen für das VPC-Netzwerkdesign.

VPC-native Cluster verwenden

Wir empfehlen die Verwendung VPC-nativer Cluster. VPC-native Cluster verwenden Alias-IP-Adressbereiche auf GKE-Knoten und sind für private GKE-Cluster und zum Erstellen von Clustern in freigegebenen VPCs erforderlich und haben viele andere Vorteile. Bei Clustern, die im Autopilot-Modus erstellt wurden, ist der VPC-native Modus immer aktiviert und kann nicht deaktiviert werden.

VPC-native Cluster lassen sich leichter skalieren als weitergeleitete, geclusterte Cluster ohne Nutzung von Google Cloud-Routen. Daher sind sie weniger anfällig für Routingbeschränkungen.

Die Vorteile von VPC-nativen Clustern bieten einen Alias-IP-Support. Beispielsweise können Netzwerk-Endpunktgruppen (NEGs) nur mit sekundären IP-Adressen verwendet werden. Daher werden sie nur in VPC-nativen Clustern unterstützt.

Freigegebene VPC-Netzwerke verwenden

GKE-Cluster erfordern eine sorgfältige IP-Adressplanung. Die meisten Organisationen haben normalerweise eine zentrale Verwaltungsstruktur mit einem Netzwerkadministratorenteam, das IP-Adressbereiche für Cluster und einen Plattformadministrator für den Betrieb der Cluster zuweisen kann. Diese Art von Organisationsstruktur funktioniert gut mit der freigegebenen VPC-Netzwerkarchitektur von Google Cloud. In der Architektur eines freigegebenen VPC-Netzwerks kann ein Netzwerkadministrator Subnetze erstellen und sie für VPCs freigeben. Sie können GKE-Cluster in einem Dienstprojekt erstellen und die von der freigegebenen VPC freigegebenen Subnetze im Hostprojekt verwenden. Die IP-Adresskomponente verbleibt im Hostprojekt und die anderen Clusterkomponenten befinden sich im Dienstprojekt.

Ein freigegebenes VPC-Netzwerk ist im Allgemeinen eine häufig verwendete Architektur, die für die meisten Organisationen mit einem zentralisierten Managementteam geeignet ist. Es wird empfohlen, freigegebene VPC-Netzwerke zu verwenden, um die Subnetze für Ihre GKE-Cluster zu erstellen und IP-Adressenkonflikte innerhalb Ihrer Organisation zu vermeiden. Sie können auch freigegebene VPCs für die Governance von operativen Funktionen verwenden. Sie können beispielsweise ein Netzwerkteam haben, das sich nur mit Netzwerkkomponenten und Zuverlässigkeit beschäftigt, und ein anderes Team, das sich mit GKE beschäftigt.

Strategien zur Verwaltung von IP-Adressen

Alle Kubernetes-Cluster, einschließlich GKE-Cluster, benötigen für jeden Pod eine eindeutige IP-Adresse.

In GKE können alle diese IP-Adressen im gesamten VPC-Netzwerk routbar sein. Daher ist die Planung der IP-Adresse erforderlich, da sich Adressen nicht mit dem internen IP-Adressbereich in lokalen oder anderen verbundenen Umgebungen überschneiden können. In den folgenden Abschnitten werden Strategien für das Verwalten von IP-Adressen mit GKE vorgeschlagen.

Erforderliches IP-Adresskontingent planen

Private Cluster werden empfohlen und werden im Abschnitt Netzwerksicherheit ausführlicher erläutert. Im Rahmen privater Cluster werden nur VPC-native Cluster unterstützt. Dafür sind die folgenden IP-Adressbereiche erforderlich:

• IP-Adressbereich der Steuerungsebene: Verwenden Sie ein /28-Subnetz innerhalb der privaten IP-Adressbereiche, die in RFC 1918 enthalten sind. Sie müssen darauf achten, dass sich dieses Subnetz nicht mit einem anderen Classless Inter-Domain Routing (CIDR) im VPC-Netzwerk überschneidet.
• Knotensubnetz: Das Subnetz mit dem primären IP-Adressbereich, den Sie allen Knoten in Ihrem Cluster zuweisen möchten. Dienste mit dem Typ LoadBalancer, die die Annotation cloud.google.com/load-balancer-type: "Internal" verwenden, verwenden ebenfalls dieses Subnetz standardmäßig. Sie können auch ein dediziertes Subnetz für interne Load-Balancer verwenden.
• Pod-IP-Adressbereich: Der IP-Bereich, den Sie allen Pods in Ihrem Cluster zuweisen. GKE stellt diesen Bereich als Alias des Subnetzes bereit. Weitere Informationen finden Sie unter IP-Adressbereiche für VPC-native Cluster.
• Dienst-IP-Adressbereich: Der IP-Adressbereich, den Sie allen Diensten in Ihrem Cluster zuweisen. GKE stellt diesen Bereich als Alias des Subnetzes bereit.

Für private Cluster müssen Sie ein Knotensubnetz, einen Pod-IP-Adressbereich und einen Dienst-IP-Adressbereich definieren.

Der IP-Adressbereich der Steuerungsebene ist der von GKE verwalteten Steuerungsebene zugewiesen, die sich in einem von Google verwalteten Mandantenprojekt mit Peering-VPC befindet. Dieser IP-Adressbereich darf sich nicht mit IP-Adressen in Ihrer VPC-Peering-Gruppe überschneiden, da GKE diese Route in Ihr Projekt importiert. Dies bedeutet, dass bei Routing zu demselben CIDR in Ihrem Projekt Routingprobleme auftreten können.

Beim Erstellen eines Clusters hat das Subnetz einen primären Bereich für die Knoten des Clusters und muss vor der Clustererstellung vorhanden sein. Das Subnetz sollte die maximale Anzahl von Knoten, die Sie im Cluster erwarten, und die internen Load Balancer-IP-Adressen im gesamten Cluster, der das Subnetz verwendet, bereitstellen können.

Die IP-Adressbereiche für Pods und Dienste werden als separate sekundäre Bereiche Ihres Subnetzes dargestellt, die als Alias-IP-Adressen in VPC-nativen Clustern implementiert werden.

Wählen Sie möglichst viele IP-Adressbereiche aus, damit Sie alle Knoten, Pods und Dienste für den Cluster bereitstellen können.

Beachten Sie folgende Einschränkungen:

• Sie können primäre IP-Adressbereiche erweitern, aber nicht verkleinern. Diese IP-Adressbereiche müssen zusammenhängend sein.
• Sie können den Pod-Bereich erweitern, indem Sie zusätzliche Pod-Bereiche an den Cluster anhängen oder neue Knotenpools mit anderen sekundären Pod-Bereichen erstellen.
• Der sekundäre IP-Adressbereich für Dienste kann über die gesamte Lebensdauer des Clusters nicht erweitert oder geändert werden.
• Prüfen Sie die Einschränkungen für den sekundären IP-Adressbereich für Pods und Dienste.

Mehr als private RFC 1918-IP-Adressen verwenden

In einigen Umgebungen ist der RFC 1918-Bereich in großen zusammenhängenden CIDR-Blöcken möglicherweise bereits in einer Organisation zugeordnet. Sie können den Nicht-RFC 1918-Bereich für zusätzliche CIDRs für GKE-Cluster verwenden, sofern sie sich nicht mit öffentlichen IP-Adressen von Google überschneiden. Wir empfehlen die Verwendung des Teils 100.64.0.0/10 desRFC-Adressbereichs, da Klasse E Adressbereich Interoperabilitätsprobleme mit lokaler Hardware verursachen kann. Sie können privat wiederverwendete öffentliche IP-Adressen (PUPI) verwenden.

Bei der Verwendung privat wiederverwendeter öffentlicher IP-Adressen sollten Sie vorsichtig sein und Routen-Advertising in lokalen Netzwerken über das Internet steuern, wenn Sie diese Option auswählen.

Sie sollten in einem Cluster mit Pod-zu-Pod- und Pod-zu-Dienst-Traffic keine Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) verwenden. Dadurch wird das Kubernetes-Netzwerkmodell beeinträchtigt.

Kubernetes geht davon aus, dass alle IP-Adressen außerhalb RFC 1918 privat wiederverwendete öffentliche IP-Adressen sind und verwendet SNAT für den gesamten Traffic, der von diesen Adressen stammt.

Wenn Sie eine IP-Adresse außerhalb des RFC 1918-Bereichs für Ihren GKE-Cluster verwenden, müssen Sie für Standardcluster entweder SNAT explizit deaktivieren oder den IP-Masquerade-Agent konfigurieren, um die Pod-IP-Adressen des Clusters und die sekundären IP-Adressbereiche für Services von SNAT auszuschließen. Für Autopilot-Cluster sind keine zusätzlichen Schritte erforderlich.

Benutzerdefinierten Subnetzmodus verwenden

Wenn Sie das Netzwerk einrichten, wählen Sie auch den Subnetzmodus aus: auto (Standard) oder custom (empfohlen). Der Modus auto behält die Subnetzzuordnung bei Google vor und ist eine gute Option für den Einstieg ohne IP-Adressplanung. Es wird jedoch empfohlen, den Modus custom auszuwählen, da Sie in diesem Modus IP-Adressbereiche auswählen können, die sich nicht mit anderen Bereichen in Ihrer Umgebung überschneiden. Wenn Sie eine freigegebene VPC verwenden, kann ein Organisations- oder Netzwerkadministrator diesen Modus auswählen.

Im folgenden Beispiel wird ein Netzwerk mit dem Namen my-net-1 im benutzerdefinierten Subnetzmodus erstellt:

gcloud compute networks create my-net-1 --subnet-mode custom

Pod-Dichte pro Knoten planen

Standardmäßig reservieren Standard-Cluster einen /24-Bereich für jeden Knoten außerhalb des Pod-Adressbereichs im Subnetz und bis zu 110 Pods pro Knoten. Sie können jedoch einen Standardcluster für die Unterstützung von bis zu 256 Pods pro Knoten konfigurieren, wobei für jeden Knoten ein /23-Bereich reserviert ist. Je nach Größe der Knoten und dem Anwendungsprofil der Pods können Sie auf jedem Knoten deutlich weniger Pods ausführen.

Wenn Sie davon ausgehen, dass mehr als 64 Pods pro Knoten ausgeführt werden, sollten Sie die maximale Anzahl von Pods pro Knoten anpassen, um den IP-Adressbereich in Ihrem Pod-Subnetz beizubehalten.

Wenn Sie voraussichtlich mehr als die standardmäßigen 110 Pods pro Knoten ausführen werden, können Sie die maximale Anzahl der Pods pro Knoten auf 256 erhöhen, wobei /23 für jeden Knoten reserviert ist. Bei dieser Art von Konfiguration mit hoher Pod-Dichte empfehlen wir die Verwendung von Instanzen mit 16 oder mehr CPU-Kernen, um die Skalierbarkeit und Leistung Ihres Clusters zu gewährleisten.

Für Autopilot-Cluster beträgt die maximale Anzahl von Pods pro Knoten auf 32. Dabei wird ein /26-Bereich für jeden Knoten reserviert. Diese Einstellung kann in Autopilot-Clustern nicht konfiguriert werden.

Überschneidungen bei IP-Adressen vermeiden, die in anderen Umgebungen verwendet werden

Sie können ein VPC-Netzwerk über Cloud VPN oder Cloud Interconnect mit einer lokalen Umgebung oder anderen Clouddienstanbietern verbinden. Diese Umgebungen können Routen freigeben und das lokale Schema zur IP-Adressverwaltung in der Planung der IP-Adresse für GKE sehr wichtig machen. Achten Sie darauf, dass sich die IP-Adressen nicht mit den IP-Adressen in anderen Umgebungen überschneiden.

Subnetz für Load-Balancer erstellen

Erstellen Sie ein separates Load-Balancer-Subnetz, um Dienste mit dem internen TCP/UDP-Load-Balancing bereitzustellen. Wenn kein separates Load-Balancer-Subnetz verwendet wird, werden diese Dienste über eine IP-Adresse aus dem Knotensubnetz freigegeben. Dies kann dazu führen, dass der gesamte zugewiesene Speicherplatz in diesem Subnetz früher als erwartet verwendet und Ihr GKE-Cluster nicht auf die erwartete Anzahl von Knoten skaliert wird.

Wenn Sie ein separates Load-Balancer-Subnetz verwenden, können Sie außerdem Traffic an und von den GKE-Knoten separat nach Diensten filtern, die über das interne TCP/UDP-Load-Balancing freigegeben werden. So können Sie strengere Sicherheitsgrenzen festlegen.

Genügend IP-Adressbereich für den Cluster Autoscaler reservieren

Mit Cluster Autoscaler können Sie Knoten im Cluster dynamisch hinzufügen und entfernen, um die Kosten zu kontrollieren und die Nutzung zu verbessern. Wenn Sie das Cluster-Autoscaling verwenden, achten Sie jedoch darauf, dass Ihre IP-Adressplanung für die maximale Größe aller Knotenpools gilt. Jeder neue Knoten benötigt eine eigene Knoten-IP-Adresse sowie einen eigenen zuweisbaren Satz von Pod-IP-Adressen basierend auf den konfigurierten Pods pro Knoten. Die Anzahl der Pods pro Knoten kann anders konfiguriert werden, als auf der Clusterebene konfiguriert ist. Nach dem Erstellen des Clusters oder Knotenpools können Sie die Anzahl der Pods pro Knoten nicht mehr ändern. Sie sollten Ihre Arbeitslasttypen berücksichtigen und sie unterschiedlichen Knotenpools zuweisen, um eine optimale IP-Adresszuweisung zu ermöglichen.

Erwägen Sie die Verwendung der automatischen Knotenbereitstellung mit dem Cluster-Autoscaling, insbesondere wenn Sie VPC-native Cluster verwenden. Weitere Informationen finden Sie unter Knotenbegrenzungsbereiche.

IP-Adressen Clusterübergreifend freigeben

Möglicherweise müssen Sie IP-Adressen für mehrere Cluster freigeben, wenn Sie ein zentrales Team haben, das die Infrastruktur für Cluster verwaltet. Informationen zum Freigeben von IP-Adressen für GKE-Cluster finden Sie unter IP-Adressbereiche für GKE-Cluster freigeben. Sie können die IP-Ausschöpfung reduzieren, indem Sie drei Bereiche für Pods, Dienste und Knoten erstellen und diese wiederverwenden oder freigeben, insbesondere in einem freigegebenen VPC-Modell. Diese Konfiguration kann auch die Verwaltung von IP-Adressen für Netzwerkadministratoren vereinfachen, da sie nicht für jeden Cluster eigene Subnetze erstellen müssen.

Beachten Sie dabei Folgendes:

• Als Best Practice sollten Sie separate Subnetze und IP-Adressbereiche für alle Cluster verwenden.
• Sie können den sekundären IP-Adressbereich des Pods freigeben, aber dies wird nicht empfohlen, da ein Cluster alle IP-Adressen verwenden kann.
• Sie können sekundäre Dienst-IP-Adressbereiche freigeben, aber dieses Feature funktioniert nicht mit VPC-Bereich Cloud DNS für GKE.

Wenn Sie keine IP-Adressen mehr haben, können Sie mithilfe von nicht zusammenhängenden Multi-Pod-CIDRs zusätzliche Pod-IP-Adressbereiche erstellen.

IP-Adressen für interne LoadBalancer-Dienste freigeben

Sie können eine einzelne IP-Adresse für bis zu 50 Back-Ends über unterschiedliche Ports freigeben. Dadurch können Sie die Anzahl der IP-Adressen reduzieren, die Sie für interne LoadBalancer-Dienste benötigen.

Weitere Informationen finden Sie unter Freigegebene IP-Adresse.

Optionen für die Netzwerksicherheit

Hier finden Sie einige wichtige Empfehlungen für die Clusterisolation. Die Netzwerksicherheit für GKE-Cluster ist eine gemeinsame Verantwortung zwischen Google und den Clusteradministratoren.

GKE Dataplane V2 verwenden

GKE Dataplane V2 basiert auf eBPF und bietet integrierte Sicherheits- und Sichtbarkeitsfunktionen des Netzwerks. Wenn Sie einen Cluster mit GKE Dataplane V2 erstellen, müssen Sie Netzwerkrichtlinien nicht explizit aktivieren, da GKE Dataplane V2 das Dienstrouting, die Durchsetzung von Netzwerkrichtlinien und das Logging verwaltet. Aktivieren Sie die neue Datenebene mit der Google Cloud CLI-Option --enable-dataplane-v2, wenn Sie einen Cluster erstellen. Nach der Konfiguration der Netzwerkrichtlinien kann ein Standard-CRD-Objekt NetworkLogging konfiguriert werden, um zugelassene und abgelehnte Netzwerkverbindungen zu protokollieren. Wir empfehlen, Cluster mit GKE Dataplane V2 zu erstellen, um die integrierten Features wie Logging von Netzwerkrichtlinien vollständig zu nutzen.

Privaten Clustertyp auswählen

Öffentliche Cluster haben sowohl private als auch öffentliche IP-Adressen für Knoten und nur einen öffentlichen Endpunkt für Knoten der Steuerungsebene. Private Cluster bieten eine stärkere Isolierung, da sie nur über interne IP-Adressen auf Knoten verfügen und private oder öffentliche Endpunkte für die Knoten der Steuerungsebene haben (die weiter isoliert werden kann und im Abschnitt Freigabe der Cluster-Steuerungsebene minimieren behandelt wird). In privaten Clustern können Sie mit dem privaten Google-Zugriff weiterhin auf Google APIs zugreifen. Es wird empfohlen, private Cluster auszuwählen.

In einem privaten Cluster sind Pods von der eingehenden und ausgehenden Kommunikation (dem Clusterperimeter) isoliert. Sie können diese Richtungen steuern, indem Sie Dienste mithilfe von Load-Balancing und Cloud NAT bereitstellen. Dies wird in diesem Dokument im Abschnitt Clusterkonnektivität erläutert. Das folgende Diagramm veranschaulicht diese Art der Einrichtung:

Dieses Diagramm zeigt die Kommunikation eines privaten Clusters. Lokale Clients können über den kubectl-Client eine Verbindung zum Cluster herstellen. Der Zugriff auf Google-Dienste erfolgt über privaten Google-Zugriff. Die Kommunikation mit dem Internet ist nur über Cloud NAT möglich.

Weitere Informationen finden Sie unter Anforderungen, Beschränkungen und Einschränkungen für private Cluster.

Freigabe der Cluster-Steuerungsebene minimieren

In einem privaten Cluster kann der GKE API-Server als öffentlicher oder privater Endpunkt bereitgestellt werden. Sie können beim Erstellen des Clusters entscheiden, welchen Endpunkt verwendet werden soll. Sie können den Zugriff mithilfe von autorisierten Netzwerken steuern, wobei sowohl die öffentlichen als auch die privaten Endpunkte standardmäßig die gesamte Kommunikation zwischen dem Pod und den Knoten-IP-Adressen im Cluster ermöglichen. Zum Aktivieren eines privaten Endpunkts beim Erstellen eines Clusters verwenden Sie das Flag --enable-private-endpoint.

Zugriff auf die Steuerungsebene autorisieren

Mit autorisierten Netzwerken können Sie festlegen, welche IP-Adress-Subnetze auf die GKE-Steuerungsebenenknoten zugreifen können. Nachdem Sie diese Netzwerke aktiviert haben, können Sie den Zugriff auf bestimmte Quell-IP-Adressbereiche beschränken. Wenn der öffentliche Endpunkt deaktiviert ist, sollten diese Quell-IP-Adressbereiche privat sein. Wenn ein öffentlicher Endpunkt aktiviert ist, können Sie öffentliche oder interne IP-Adressbereiche zulassen. Konfigurieren Sie benutzerdefiniertes Route Advertisement, damit der private Endpunkt der Cluster-Steuerungsebene aus einer lokalen Umgebung erreichbar ist. Sie können den privaten GKE API-Endpunkt mit der Option --enable-master-global-access global zugänglich machen, wenn Sie einen Cluster erstellen.

Das folgende Diagramm zeigt eine typische Konnektivität der Steuerungsebene über autorisierte Netzwerke:

Das Diagramm zeigt vertrauenswürdigen Nutzern, die mit der GKE-Steuerungsebene kommunizieren können, da sie Teil von autorisierten Netzwerken sind, während der Zugriff von nicht vertrauenswürdigen Nutzern blockiert wird. Die Kommunikation mit dem GKE-Cluster erfolgt über den privaten Endpunkt der Steuerungsebene.

Verbindung der Steuerungsebene zulassen

Bestimmte System-Pods auf jedem Worker-Knoten müssen Dienste wie den Kubernetes API-Server (kube-apiserver), Google APIs oder den Metadatenserver erreichen. kube-apiserver muss auch mit einigen System-Pods kommunizieren, z. B. mit event-exporter. Diese Kommunikation ist standardmäßig zugelassen. Wenn Sie in den Projekten VPC-Firewallregeln bereitstellen (weitere Details im Abschnitt Clustertraffic einschränken), müssen Sie dafür sorgen, dass diese Pods auch weiterhin mit dem kube-apiserver und mit Google APIs kommunizieren können.

Proxys für den Zugriff auf die Steuerungsebene über Peering-Netzwerke bereitstellen

Der Zugriff auf die Steuerungsebene für private GKE-Cluster erfolgt über VPC-Netzwerk-Peering. Da das VPC-Netzwerk-Peering nicht transitiv ist, können Sie von einem anderen Peering-Netzwerk aus nicht auf die Steuerungsebene des Clusters zugreifen.

Wenn Sie bei Verwendung einer Hub-and-Spoke-Architektur direkten Zugriff von einem anderen Peering-Netzwerk oder lokal benötigen, stellen Sie Proxys für den Traffic der Steuerungsebene bereit.

Cluster-Traffic mithilfe von Netzwerkrichtlinien beschränken

Für Cluster-Arbeitslasten, die kombiniert werden können, sind mehrere Ebenen der Netzwerksicherheit möglich: VPC-Firewallregeln, hierarchische Firewallrichtlinien und Kubernetes-Netzwerkrichtlinien. VPC-Firewallregeln und hierarchische Firewallrichtlinien gelten auf der Ebene der virtuellen Maschine (VM), d. h. den Worker-Knoten, auf denen sich die Pods des GKE-Clusters befinden. Kubernetes-Netzwerkrichtlinien gelten auf Pod-Ebene, um Pod-zu-Pod-Trafficpfade zu erzwingen.

Wenn Sie VPC-Firewalls implementieren, kann die standardmäßige erforderliche Kommunikation der Steuerungsebene wie etwa die Kubelet-Kommunikation mit der Steuerungsebene beeinträchtigt werden. GKE erstellt standardmäßig erforderliche Firewallregeln, kann jedoch überschrieben werden. Bei einigen Bereitstellungen kann es sein, dass die Steuerungsebene den Cluster im Dienst erreichen muss. Mithilfe von VPC-Firewalls können Sie eine Ingress-Richtlinie konfigurieren, die den Dienst zugänglich macht.

GKE-Netzwerkrichtlinien werden über die Kubernetes Network Policy API konfiguriert, um die Podkommunikation eines Clusters zu erzwingen. Sie können Netzwerkrichtlinien beim Erstellen eines Clusters mit der gcloud container clusters create-Option --enable-network-policy aktivieren. Wenn Sie den Traffic mithilfe von Netzwerkrichtlinien beschränken möchten, können Sie die Bereitstellungsanleitung für Anthos zur Beschränkung von Traffic lesen.

Google Cloud Armor-Sicherheitsrichtlinien für Ingress aktivieren

Mit den Google Cloud Armor-Sicherheitsrichtlinien können Sie Anwendungen, die externe Application Load Balancer verwenden, vor DDoS-Angriffen und anderen webbasierten Angriffen schützen, indem Sie diese Art von Traffic am Netzwerkrand blockieren. Aktivieren Sie in GKE die Google Cloud Armor-Sicherheitsrichtlinien für Anwendungen mithilfe von Ingress für externe Application Load Balancer und durch Hinzufügen einer Sicherheitsrichtlinie zur BackendConfig, die mit dem Ingress-Objekt verknüpft ist.

Identity-Aware Proxy zur Authentifizierung für Anwendungen mit IAM-Nutzern verwenden

Wenn Sie Dienste nur für Nutzer innerhalb der Organisation zugänglich machen möchten, ohne das Unternehmensnetzwerk verwenden zu müssen, können Sie mit Identity-Aware Proxy eine Authentifizierungsebene für diese Anwendungen. Zur Aktivierung von Identity-Aware Proxy für GKE folgen Sie den Konfigurationsschritten, um Identity-Aware Proxy als Teil der BackendConfig für Ihren Dienst-Ingress hinzuzufügen. Identity-Aware Proxy kann mit Google Cloud Armor kombiniert werden.

Sicherheitsrichtlinien für Unternehmen durch Optimieren von Organisationsrichtlinien einschränken

Mithilfe von Einschränkungen für Organisationsrichtlinien können Sie Richtlinien festlegen, um Ihren Sicherheitsstatus weiter zu verbessern. Sie können beispielsweise Einschränkungen verwenden, um die Erstellung von Load-Balancern auf bestimmte Typen zu beschränken, z. B. nur auf interne Load-Balancer.

Clusterverbindung skalieren

In diesem Abschnitt werden Skalieroptionen für die DNS- und ausgehende Konnektivität Ihrer Cluster zum Internet und zu Google-Diensten beschrieben.

Cloud DNS für GKE verwenden

Sie können Cloud DNS für GKE verwenden, um eine Pod- und Dienst-DNS-Auflösung mit verwaltetem DNS ohne Cluster-gehosteten DNS-Anbieter bereitzustellen. Cloud DNS reduziert den Aufwand für die Verwaltung eines im Cluster gehosteten DNS-Servers und erfordert keine Skalierung, Überwachung oder Verwaltung von DNS-Instanzen, da es sich dabei um einen gehosteten Google-Dienst handelt.

NodeLocal DNSCache aktivieren

GKE verwendet kube-dns, um den lokalen DNS-Dienst des Clusters als Standard-Cluster-Add-on bereitzustellen. kube-dns wird im Cluster als Funktion der Gesamtzahl von Kernen und Knoten im Cluster repliziert.

Sie können die DNS-Leistung mit NodeLocal DNSCache verbessern. NodeLocal DNSCache ist ein Add-on, das als DaemonSet bereitgestellt wird und keine Pod-Konfigurationsänderungen erfordert. DNS-Lookups zum lokalen Pod-Dienst erstellen keine offenen Verbindungen, die auf dem Knoten erfasst werden müssen. Externe Hostnamen-Lookups werden an Cloud DNS weitergeleitet, während alle anderen DNS-Abfragen an kube-dns gehen.

Aktivieren Sie NodeLocal DNSCache für konsistente DNS-Abfragesuchzeiten und eine verbesserte Clusterskalierung. Für Autopilot-Cluster ist NodeLocal DNSCache standardmäßig aktiviert und kann nicht überschrieben werden.

Mit der folgenden Google Cloud CLI-Option wird NodeLocal DNSCache beim Erstellen eines Clusters aktiviert: --addons NodeLocalDNS.

Wenn Sie den Namen steuern, den Anwendungen auflösen möchten, gibt es Möglichkeiten, die DNS-Skalierung zu verbessern. Verwenden Sie beispielsweise einen FQDN (Hostnamen mit einem Punkt beenden) oder deaktivieren Sie die Erweiterung des Suchpfads über die Manifestoption Pod.dnsConfig.

Cloud NAT für den Internetzugriff von privaten Clustern verwenden

Standardmäßig haben private Cluster keinen Internetzugriff. Damit Pods das Internet erreichen können, aktivieren Sie Cloud NAT für jede Region. Aktivieren Sie mindestens Cloud NAT für die primären und sekundären Bereiche im GKE-Subnetz. Achten Sie darauf, ausreichend IP-Adressen für Cloud NAT und Ports pro VM zuzuweisen.

Beachten Sie bei der Verwendung von Cloud NAT für private Cluster die folgenden Best Practices für die Cloud NAT-Gateway-Konfiguration:

• Wenn Sie das Cloud NAT-Gateway erstellen, aktivieren Sie es nur für die von Ihren Clustern verwendeten Subnetzbereiche. Durch das Zählen aller Knoten in allen Clustern können Sie ermitteln, wie viele NAT-Nutzer-VMs Sie im Projekt haben.

• Verwenden Sie die dynamische Portzuweisung, um je nach Nutzung der VM eine unterschiedliche Anzahl von Ports pro VM zuzuweisen. Beginnen Sie mit einer Mindestanzahl an Ports von 64 und einer maximalen Anzahl von 2.048.

• Wenn Sie viele gleichzeitige Verbindungen zum selben Ziel-3-Tupel verwalten müssen, senken Sie die TCP-TIME_WAIT-Zeitüberschreitung vom Standardwert 120s auf 5s. Weitere Informationen finden Sie unter Unterschiedliche Zeitlimits für NAT angeben.

• Aktivieren Sie das Cloud NAT-Fehler-Logging, um die zugehörigen Protokolle zu prüfen.

• Prüfen Sie nach der Konfiguration des Gateways die Cloud NAT-Gateway-Protokolle. Wenn Sie Probleme mit dem Zuordnungsstatus verringern möchten, müssen Sie möglicherweise die maximale Anzahl von Ports pro VM erhöhen.

Vermeiden Sie das doppelte SNAT für den Traffic von Pods (SNAT zuerst im GKE-Knoten und dann noch einmal mit Cloud NAT). Sofern die Pod-IP-Adressen für lokale Netzwerke sichtbar sein dürfen, die über Cloud VPN oder Cloud Interconnect verbunden sind, disable-default-snat und übertragen Sie das SNAT-Tracking auf Cloud NAT., um Skalierbarkeit zu ermöglichen. Diese Lösung funktioniert für alle primären und sekundären Subnetz-IP-Bereiche. Mit Netzwerkrichtlinien können Sie externen Traffic nach dem Aktivieren von Cloud NAT einschränken. Cloud NAT ist für den Zugriff auf Google-Dienste nicht erforderlich.

Privaten Google-Zugriff für den Zugriff auf Google-Dienste verwenden

In privaten Clustern haben Pods keine öffentlichen IP-Adressen, um mit öffentlichen Diensten, einschließlich Google APIs und Diensten, Kontakt aufzunehmen. Mit dem privaten Google-Zugriff können private Google Cloud-Ressourcen Google-Dienste erreichen.

Der private Google-Zugriff ist in privaten Clustern standardmäßig aktiviert, mit Ausnahme von freigegebenen VPC-Clustern.

Anwendungen bereitstellen

Achten Sie darauf, den richtigen Typ und die Optionen für den Load-Balancer zu verwenden, wenn Sie Anwendungen erstellen, die entweder extern oder intern für Ihre Organisation erreichbar sind. Dieser Abschnitt enthält einige Empfehlungen zum Freigeben und Skalieren von Anwendungen mit Cloud Load Balancing.

Containernatives Load-Balancing verwenden

Verwenden Sie das containernative Load-Balancing , wenn Sie Dienste mithilfe von HTTP(S) extern verfügbar machen. Containernatives Load-Balancing ermöglicht weniger Netzwerk-Hops, niedrigere Latenz und präzisere Traffic-Verteilung. Außerdem wird die Sichtbarkeit während der Umlaufzeit erhöht und Sie können Load-Balancing-Features wie Google Cloud Armor nutzen.

Die richtige GKE-Ressource für die Freigabe der Anwendung auswählen

Je nach Umfang Ihrer Clients (intern, extern oder sogar cluster-internal), die Region Ihrer Anwendung und die verwendeten Protokolle, gibt es verschiedene GKE-Ressourcen, die Sie zur Bereitstellung Ihrer Anwendung auswählen können. In der Übersicht über das Dienstnetzwerk werden diese Optionen erläutert und Sie können mithilfe der Load-Balancing-Optionen von Google Cloud die beste Ressource für die einzelnen Teile Ihrer Anwendung auswählen.

Systemdiagnosen auf Basis von BackendConfig erstellen

Wenn Sie Dienste über ein Ingress-Objekt bereitstellen, verwenden Sie eine Systemdiagnosekonfiguration in einer BackendConfig-CRD, um die Systemdiagnosefunktion des Application Load Balancers zu nutzen. Sie können die Systemdiagnose an den entsprechenden Endpunkt weiterleiten und eigene Schwellenwerte festlegen. Ohne BackendConfig-CRD werden Systemdiagnosen aus Readiness-Prüfungsparametern abgeleitet oder Standardparameter verwendet.

Lokale Traffic-Richtlinie zur Beibehaltung der ursprünglichen IP-Adresse verwenden

Wenn Sie einen internen Passthrough-Network Load Balancer mit GKE verwenden, setzen Sie die Option externalTrafficPolicy auf Local, um die Quell-IP-Adresse der Anfrage beizubehalten. Verwenden Sie diese Option, wenn Ihre Anwendung die ursprüngliche Quell-IP-Adresse benötigt. Die Option externalTrafficPolicy local kann jedoch zu einer geringeren Lastverteilung führen. Verwenden Sie diese Funktion deshalb nur bei Bedarf. Bei HTTP(S)-Diensten können Sie Ingress-Controller verwenden und die ursprüngliche IP-Adresse abrufen. Lesen Sie dazu den X-Forwarded-For-Header in der HTTP-Anfrage.

Private Service Connect verwenden

Sie können Private Service Connect verwenden, um interne Passthrough-Network Load Balancer-Dienste für andere VPC-Netzwerke freizugeben. Dies ist nützlich für Services, die auf GKE-Clustern gehostet werden, aber für Kunden zugänglich sind, die in verschiedenen Projekten und VPCs ausgeführt werden.

Sie können Private Service Connect verwenden, um die Nutzung von IP-Adressen zu reduzieren. Dazu stellen Sie eine Verbindung zwischen VPCs mit sich überschneidenden IP-Adressen bereit.

Betrieb und Verwaltung

Die folgenden Abschnitte enthalten Best Practices für den Betrieb von Vorgängen, mit denen Sie für Ihre Arbeitslasten detaillierte Autorisierungsoptionen gewährleisten können. Um das Erstellen von manuellen Firewallregeln zu vermeiden, befolgen Sie die Best Practices für den Betrieb dieses Abschnitts. Er enthält auch Empfehlungen zum Verteilen Ihrer Arbeitslasten und zum Monitoring und Logging in GKE.

IAM für GKE-Berechtigungen verwenden, um Richtlinien in freigegebenen VPC-Netzwerken zu steuern

Bei Verwendung von freigegebenen VPC-Netzwerken werden Firewallregeln für Load-Balancer automatisch im Hostprojekt erstellt.

Damit Sie keine Firewallregeln manuell erstellen müssen, weisen Sie dem GKE-Dienstkonto im Hostprojekt mit dem Namen service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com eine benutzerdefinierte Rolle mit den geringsten Berechtigungen zu.

Ersetzen Sie HOST_PROJECT_NUMBER durch die Projektnummer des Hostprojekts für die freigegebene VPC.

Die von Ihnen erstellte benutzerdefinierte Rolle sollte die folgenden Berechtigungen haben:

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

Außerdem haben Firewallregeln, die von GKE erstellt wurden, immer die Standardpriorität 1.000. Sie können also bestimmten Traffic unterbinden, indem Sie Firewallregeln mit einer höheren Priorität erstellen.

Wenn Sie die Erstellung bestimmter Load-Balancer-Typen einschränken möchten, verwenden Sie Organisationsrichtlinien, um die Erstellung von Load-Balancern einzuschränken.

Regionale Cluster verwenden und Arbeitslasten für hohe Verfügbarkeit verteilen

Regionale Cluster können die Verfügbarkeit von Anwendungen in einem Cluster erhöhen, da die Steuerungsebene des Clusters und die Knoten auf mehrere Zonen verteilt sind.

Verwenden Sie außerdem die Pod-Anti-Affinität, um sicherzustellen, dass Pods eines bestimmten Dienstes in mehreren Zonen geplant werden.

Weitere Informationen zum Konfigurieren dieser Einstellungen für Hochverfügbarkeit und Kostenoptimierung finden Sie unter Best Practices für hochverfügbare GKE-Cluster.

Cloud Logging und Cloud Monitoring verwenden und Logging von Netzwerkrichtlinien aktivieren

Obwohl jede Organisation unterschiedliche Anforderungen für die Sichtbarkeit und Prüfung hat, empfehlen wir die Aktivierung von Netzwerkrichtlinien-Logging. Dieses Feature ist nur in GKE Dataplane V2 verfügbar. Das Logging von Netzwerkrichtlinien bietet Einblick in die Durchsetzung von Richtlinien und Pod-Traffic-Muster. Beachten Sie, dass Kosten für das Logging von Netzwerkrichtlinien anfallen.

Für GKE-Cluster mit Version 1.14 oder höher sind Logging und Monitoring standardmäßig aktiviert. Monitoring bietet ein Dashboard für Ihre GKE-Cluster. Außerdem werden GKE-Annotationen für VPC-Flusslogs aktiviert. Standardmäßig erfasst Logging Logs für alle im Cluster bereitgestellten Arbeitslasten, aber es gibt auch eine Option nur für Systemlogs. Sie können Benachrichtigungen im GKE-Dashboard beobachten und festlegen. Bei Clustern, die im Autopilot-Modus erstellt wurden, sind Monitoring und Logging automatisch aktiviert und können nicht konfiguriert werden.

Beachten Sie, dass für Google Cloud Observability Kosten anfallen.

Zusammenfassung der Checkliste

Nächste Schritte

• Insights: Best Practices für GKE

• Best Practices für die Mehrmandantenfähigkeit in Unternehmen

• GKE-Anwendungen über Ingress und Dienste freigeben

• Best Practices und Referenzarchitekturen für das VPC-Design