In diesen Anleitungen werden einige der Planungsüberlegungen vereinfacht, damit Sie sich auf die wichtigsten Funktionen und Dienste der Google Kubernetes Engine (GKE) konzentrieren können. Bevor Sie eine eigene Google Kubernetes Engine-Umgebung erstellen, die der in dieser Reihe von Anleitungen beschriebenen ähnelt, sollten Sie einige zusätzliche Planungsüberlegungen berücksichtigen. Dazu gehören die Clusterverwaltungsebene, das Netzwerk und die Verfügbarkeitstypen.
Netzwerk
GKE-Cluster erfordern eine sorgfältige IP-Adressplanung. 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.
In diesen Anleitungen verwenden Sie Cluster im Autopilot-Modus, die immer den VPC-nativen Modus für das Netzwerk verwenden. VPC-native Cluster verwenden Alias-IP-Adressbereiche auf GKE-Knoten und sind für das Erstellen von Clustern in freigegebenen VPCs erforderlich. 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.
Bevor Sie eine eigene GKE-Umgebung erstellen und Arbeitslasten bereitstellen, sollten Sie sich die folgenden Informationen zum Netzwerk ansehen:
Clustermodi
In diesen Anleitungen erstellen Sie einen regionalen GKE-Cluster, der den Autopilot-Modus verwendet. Autopilot-Cluster sind mit einer optimierten Cluster-Konfiguration vorkonfiguriert, die für Produktionsarbeitslasten bereit ist. Alternativ können Sie Cluster im Standardmodus verwenden, um die Konfigurationsflexibilität für die zugrunde liegende Infrastruktur zu erhöhen.
Eine umfassendere Übersicht finden Sie in den Planungsdokumenten, die mit den Cluster-Konfigurationsoptionen beginnen.
Namespaces
Mit Namespaces können Sie Ihre Anwendungen organisieren und Komponenten voneinander isolieren. Jeder Namespace hat eigene Ressourcen wie Pods, Dienste und Bereitstellungen. Sie können beispielsweise einen Namespace für alle Frontend-Dienste und einen Namespace für Ihre Back-End-Dienste erstellen. So können Sie Ihre Dienste leichter verwalten und den Zugriff darauf steuern.
In dieser Reihe von Anleitungen stellen Sie die Pods und Dienste für die Beispielanwendung „Cymbal Bank“ in einem einzigen Namespace bereit. Dieser Ansatz reduziert die Komplexität der Bereitstellung, Sie können jedoch keine Namespaces verwenden, um verschiedenen Teams und Nutzern Ressourcen zuzuweisen, wie Sie es in einer Produktionsumgebung tun würden. Ein sichereres und produktionsfertiges Beispiel für die Beispielanwendung „Cymbal Bank“, die mehrere Namespaces verwendet, finden Sie unter Anwendungsarchitektur der Cymbal Bank.
Budget für Pod-Störungen
Mit PDB-Richtlinien (Pod Disruption Budget) können Sie die Anwendungsleistung gewährleisten, indem Sie verhindern, dass Pods gleichzeitig ausfallen, wenn Sie Änderungen am System vornehmen. Außerdem wird die Anzahl der gleichzeitig nicht verfügbaren Pods in einer replizierten Anwendung begrenzt.
In diesen Anleitungen werden keine PDBs konfiguriert und verwendet. Wenn Sie die Anleitung zum Simulieren eines Fehlers abgeschlossen haben, sollten Ihre Dienste und Knoten wie erwartet reagieren. Wenn Sie Ihre eigenen Arbeitslasten bereitstellen, können PDBs auf Knoten das Draining von Knoten blockieren.
Wenn Sie PDBs verwenden, prüfen Sie Ihre Konfiguration, bevor Sie versuchen, Knoten abzuriegeln und zu leeren. Wenn die Knoten nicht geleert werden können, treten möglicherweise Probleme mit geplanten Wartungsereignissen auf.
Nächste Schritte
Arbeiten Sie zuerst die erste Anleitung zum Bereitstellen eines einzelnen GKE-Clusters durch, in dem eine auf Mikrodiensten basierende Anwendung ausgeführt wird.