Google Kubernetes Engine-Umgebung für die Produktion vorbereiten

Diese Lösung bietet eine Vorlage und Methode, mit der Sie Arbeitslasten sicherer, zuverlässiger und kostengünstiger auf der Google Kubernetes Engine einrichten können. Sie erhalten eine Anleitung zum Konfigurieren des Administrator- und Netzwerkzugriffs auf Cluster. In diesem Artikel wird vorausgesetzt, dass Sie mit den Kubernetes-Ressourcen und der Clusterverwaltung sowie mit den Google Cloud-Netzwerkfunktionen vertraut sind.

Projekte, VPC-Netzwerke (Virtual Private Cloud) und Cluster strukturieren

Das folgende Diagramm zeigt ein Beispiel für eine flexible und hochverfügbare Struktur für Projekte, VPC-Netzwerke, Regionen, Subnetze, Zonen und Cluster.

Projekt, Netzwerk und Cluster strukturieren.

Projekte

Google Cloud erstellt alle Ressourcen innerhalb einer Projektentität. Projekte sind die Abrechnungseinheit und ermöglichen es Administratoren, IAM-Rollen (Identity and Access Management) mit Nutzern zu verknüpfen. Wenn Rollen auf Projektebene angewendet werden, gelten sie für alle im Projekt eingeschlossenen Ressourcen.

Verwenden Sie Projekte, um Ihre verschiedenen Betriebsumgebungen einzuschließen, Beispiel: Sie haben die Projekte production und staging für operative Teams sowie ein Projekt test-dev für Entwickler. Sie können detailliertere und striktere Richtlinien auf Projekte anwenden, in denen sich Ihre geschäftskritischen und vertraulichen Daten und Arbeitslasten befinden, oder freiere und flexiblere Richtlinien für Experimente von Entwicklern in test-dev-Umgebungen einrichten.

Cluster

Ein Projekt kann mehrere Cluster enthalten. Wenn Sie mehrere Arbeitslasten bereitstellen müssen, können Sie entweder einen einzelnen, freigegebenen Cluster oder separate Cluster für diese Arbeitslasten verwenden. Berücksichtigen Sie bei der Auswahl der Größe und des Umfangs eines GKE-Clusters die Best Practices.

Netzwerke und Subnetze

In jedem Projekt können Sie ein oder mehrere VPC-Netzwerke haben, bei denen es sich um virtuelle Versionen physischer Netzwerke handelt. Jedes VPC-Netzwerk ist eine globale Ressource, die andere netzwerkbezogene Ressourcen enthält, z. B. Subnetze, externe IP-Adressen, Firewallregeln, Routen, Ihr VPN und Cloud Router. Innerhalb eines VPC-Netzwerks können Sie Subnetze verwenden, die regionale Ressourcen sind, um Traffic in oder aus jeder Region zwischen Ihren GKE-Clustern zu isolieren und zu steuern.

Jedem Projekt ist ein Standardnetzwerk zugeordnet. Sie können ein zusätzliches Netzwerk erstellen und konfigurieren, um es der IPAM-Konvention (IP-Adressenverwaltung) zuzuordnen. Anschließend können Sie Firewallregeln auf dieses Netzwerk anwenden, um den Traffic von und zu Ihren GKE-Knoten zu filtern. Standardmäßig wird jeglicher Internettraffic zu Ihren GKE-Knoten zurückgewiesen.

Zur Steuerung der Kommunikation zwischen Subnetzen müssen Sie Firewallregeln erstellen, die Traffic zwischen den Subnetzen zulassen. Verwenden Sie beim Erstellen des Clusters oder Knotenpools das Flag --tags, um die GKE-Knoten mit einem geeigneten Tag zu versehen, damit die Firewallregeln wirksam werden. Sie können auch Tags verwenden, um bei Bedarf Routen zwischen Ihren Subnetzen zu erstellen.

Mehrzonen- und regionale Cluster

Standardmäßig erstellt ein Cluster seinen Clustermaster und seine Knoten in einer einzigen Zone, die Sie beim Erstellen des Clusters angeben. Sie können jedoch die Verfügbarkeit und Ausfallsicherheit Ihrer Cluster verbessern, wenn Sie Mehrzonencluster oder regionale Cluster erstellen. Mehrzonencluster und regionale Cluster verteilen Kubernetes-Ressourcen auf mehrere Zonen innerhalb einer Region.

Mehrzonencluster:

  • erstellen einen einzigen Clustermaster in einer Zone
  • erstellen Knoten in mehreren Zonen

Regionale Cluster:

  • erstellen drei Clustermaster in drei Zonen
  • erstellen standardmäßig Knoten in drei Zonen, können aber auch Knoten in beliebig vielen Zonen erstellen

Der Hauptunterschied zwischen regionalen Clustern und Mehrzonenclustern besteht darin, dass regionale Cluster drei Master und Mehrzonencluster nur einen Master erstellen. In beiden Fällen fallen für den Traffic zwischen Knoten über Zonen hinweg Gebühren an.

Sie können bei der Clustererstellung festlegen, ob Mehrzonencluster oder regionale Cluster erstellt werden. Sie können einem vorhandenen Cluster neue Zonen hinzufügen, um ihn zu einem Mehrzonencluster zu machen. Sie können einen vorhandenen Cluster jedoch nicht als regional definieren. Sie können auch keinen regionalen Cluster als nicht-regional definieren.

Die Dienstverfügbarkeit von Knoten in Ihren von GKE verwalteten Clustern wird durch das Service Level Agreement (SLA) für Compute Engine abgedeckt. Darüber hinaus garantiert das SLA für GKE eine monatliche Verfügbarkeit von 99,5 % für Ihre Kubernetes-Clustermaster für zonale Cluster und 99,95 % für regionale Cluster.

Ab dem 6. Juni 2020 berechnet GKE eine Clusterverwaltungsgebühr von 0,10 $ per pro Cluster und Stunde. Weitere Informationen finden Sie auf der Seite Preisübersicht.

Weitere Informationen zu Mehrzonen- und regionalen Clustern finden Sie in der GKE-Dokumentation.

Autorisierte Masternetzwerke

Eine weitere Sicherheitsmaßnahme, die Sie in Ihrem Cluster erzwingen können, ist die Aktivierung von autorisierten Master-Netzwerken. Mit diesem Feature wird der Zugriff auf den API-Server aus den von Ihnen angegebenen CIDR-Bereichen gesperrt und dafür gesorgt, dass nur Teams innerhalb Ihres Netzwerks den Cluster verwalten können.

Beachten Sie Folgendes, wenn Sie dieses Feature aktivieren:

  • Es sind nur 50 CIDR-Bereiche zulässig.
  • Wenn Sie eine CI/CD-Pipeline verwenden, sollten Sie dafür sorgen, dass Ihre CI/CD-Tools Zugriff auf den API-Server des Clusters haben. Dazu setzen Sie deren IP-Adressen oder CIDR-Bereiche auf die weiße Liste.

Sie können dieses Feature auch in Verbindung mit Cloud Interconnect oder Cloud VPN verwenden, um den Zugriff auf den Master-Knoten nur innerhalb Ihres privaten Rechenzentrums zu ermöglichen.

Private Cluster

Standardmäßig haben alle Knoten in einem GKE-Cluster öffentliche IP-Adressen. Es empfiehlt sich, private Cluster zu erstellen, durch die alle Worker-Knoten nur private RFC 1918-IP-Adressen erhalten. Private Cluster erzwingen die Netzwerkisolation, wodurch die Angriffsfläche der Cluster reduziert wird. Bei Verwendung von privaten Clustern können standardmäßig nur Clients innerhalb Ihres Netzwerks auf Dienste im Cluster zugreifen. Damit externe Dienste auf Dienste in Ihrem Cluster zugreifen können, können Sie einen HTTP(S)-Load-Balancer oder einen Netzwerk-Load-Balancer verwenden.

Wenn Sie den Zugriff auf den Master-Knoten außerhalb Ihres VPC-Netzwerks öffnen möchten, können Sie private Cluster mit autorisierten Master-Netzwerken verwenden. Wenn Sie autorisierte Master-Netzwerke aktivieren, erhält der Cluster-Master-Endpunkt zwei IP-Adressen, eine interne (private) und eine öffentliche. Die interne IP-Adresse kann von allen internen Nutzern Ihres Netzwerks innerhalb derselben Region verwendet werden. Die öffentliche IP-Adresse des Masters kann von jedem Nutzer oder Prozess verwendet werden, der sich außerhalb Ihres Netzwerks befindet und der aus einem zulässigen CIDR-Bereich oder einer zulässigen IP-Adresse stammt. Private Knoten haben keine externen IP-Adressen. Daher haben sie standardmäßig keinen ausgehenden Internetzugriff. Dies bedeutet auch, dass die Containerlaufzeit Ihres Clusters standardmäßig keine Container-Images aus einer externen Container-Registry abrufen kann, da dafür eine ausgehende Verbindung erforderlich ist. Sie können Ihre Container-Images in Container Registry hosten und mit dem privaten Google-Zugriff auf diese Images zugreifen. Alternativ können Sie Cloud NAT verwenden oder ein NAT-Gateway bereitstellen, um ausgehenden Zugriff für Ihre privaten Knoten bereitzustellen.

Darüber hinaus können Sie VPC Service Controls verwenden, um das Risiko der Daten-Exfiltration zu verringern. Mit VPC Service Controls können Sie verwaltete Google Cloud-Dienste in einem oder mehreren Projekten schützen, indem Sie einen Dienstperimeter für den Zugriff auf diese Dienste definieren. Sie können Anwendungen, die in Ihren GKE-Clustern ausgeführt werden, Zugriff auf diese verwalteten Dienste gewähren. Dazu legen Sie entsprechende Zugriffsebenen fest. Sie können die Steuerungsebene zum Erstellen von GKE-Clustern auch mithilfe von VPC Service Controls schützen.

Identität und Zugriff verwalten

Zugriff auf Projektebene

Im vorigen Abschnitt wurde bereits erwähnt, dass Sie IAM-Rollen an Nutzer auf Projektebene binden können. Neben dem Zuweisen von Rollen an einzelne Nutzer können Sie die Anwendung von Rollen auch mithilfe von Gruppen vereinfachen.

Die folgende Abbildung eines IAM-Richtlinienlayouts zeigt das Prinzip der geringsten Berechtigung für ein dev-Projekt, das für Entwickler zum Entwickeln und Testen ihrer neuen Funktionen und Fehlerkorrekturen eingerichtet ist, und ein prod-Projekt für den Produktionstraffic:

Identitäts- und Zugriffsverwaltung.

Wie die folgende Tabelle zeigt, gibt es innerhalb der Organisation vier Nutzergruppen mit unterschiedlichen Berechtigungsebenen, die über IAM-Rollen in den beiden Projekten zugewiesen werden:

Team IAM-Rolle Projekt Berechtigungen
Entwickler container.developer dev Darf Kubernetes-Ressourcen für die vorhandenen Cluster im Projekt erstellen, darf keine Cluster erstellen oder löschen.
Betrieb container.admin prod Vollständiger Administratorzugriff auf die Cluster und Kubernetes-Ressourcen, die im Projekt ausgeführt werden.
Security container.viewer
security.admin
prod Darf Firewallregeln und SSL-Zertifikate erstellen, ändern und löschen sowie Ressourcen anzeigen, die in jedem Cluster erstellt wurden, einschließlich der Logs der ausgeführten Pods.
Netz network.admin prod Darf Netzwerkressourcen mit Ausnahme von Firewallregeln und SSL-Zertifikaten erstellen, ändern und löschen.

Zusätzlich zu den drei Teams mit Zugriff auf das Projekt prod erhält ein weiteres Dienstkonto die Rolle container.developer für prod, um Ressourcen im Cluster erstellen, auflisten und löschen zu können. Mithilfe von Dienstkonten können Automatisierungsskripts oder Deployment-Frameworks autorisiert werden, in Ihrem Namen zu agieren. Bereitstellungen in Ihrem Produktionsprojekt und Ihren Clustern sollten über eine automatisierte Pipeline erfolgen.

Im Projekt dev arbeiten mehrere Entwickler innerhalb desselben Clusters an derselben Anwendung. Dies wird durch Namespaces vereinfacht, die der Clusternutzer erstellen kann. Alle Entwickler können Ressourcen in ihrem Namespace erstellen und damit Namenskonflikte vermeiden. Sie können auch dieselben YAML-Konfigurationsdateien für ihre Deployments wiederverwenden, sodass ihre Konfigurationen während der Entwicklungsiterationen möglichst ähnlich bleiben. Namespaces können auch zum Erstellen von Kontingenten zur Nutzung von CPU, Arbeitsspeicher und Speicher im Cluster genutzt werden. Dadurch wird gewährleistet, dass nicht zu viele Ressourcen im Cluster von nur einem Entwickler ausgelastet werden. Im nächsten Abschnitt wird die Einschränkung von Nutzern auf bestimmte Namespaces erläutert.

Rollenbasierte Zugriffssteuerung

Für GKE-Cluster mit Kubernetes 1.6 und höher können weitere Einschränkungen für die Autorisierung von Nutzern in den einzelnen Clustern gelten. IAM kann Nutzern Zugriff auf die vollständigen Cluster und die Ressourcen darin bieten. Sie können jedoch mithilfe der rollenbasierten Zugriffssteuerung (RBAC) von Kubernetes die Kubernetes API verwenden, um die Aktionen, die Nutzer in ihren Clustern ausführen können, weiter einzuschränken.

Mit RBAC wenden Clusteradministratoren detaillierte Richtlinien auf einzelne Namespaces in ihren Clustern oder auf den Cluster als Ganzes an. Das kubectl-Tool von Kubernetes verwendet die aktiven Anmeldedaten aus dem Tool gcloud. Dadurch können Clusteradministratoren Google Cloud-Identitäten (Nutzer, Dienstkonten und Google Groups) Rollen als Themen in RoleBindings zuweisen.

Mit Google Groups for GKE (Beta) können Sie Google Groups mit Kubernetes RBAC verwenden. Zur Verwendung dieses Features müssen Sie Google Arbeitsbereich-Google Groups konfigurieren, einen Cluster mit aktiviertem Feature erstellen und RoleBinding-Objekte verwenden, um Ihre Gruppen mit den Rollen zu verknüpfen, an die sie gebunden werden sollen. Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung.

In der folgenden Abbildung sehen Sie beispielsweise zwei Nutzer, user-a und user-b, denen im Namespace app-a die Rollen config-reader und pod-reader zugewiesen wurden.

RBAC-Autorisierung.

Ein weiteres Beispiel sind Google Cloud-IAM-Rollen auf Projektebene, die bestimmten Nutzern Zugriff auf alle Cluster in einem Projekt gewähren. Außerdem werden über RBAC einzelne Rollenbindungen auf Namespace- und Clusterebene hinzugefügt, um in bestimmten Clustern oder Namespaces detailgenauen Zugriff auf Ressourcen zu gewähren.

IAM-Rollenbindungen.

Kubernetes umfasst einige Standardrollen, aber als Clusteradministrator können Sie eigene Rollen erstellen, die den Anforderungen Ihres Unternehmens besser entsprechen. Mit der folgenden Beispielrolle können Nutzer nur ConfigMaps ansehen, bearbeiten und aktualisieren, aber nicht löschen, da das Verb delete nicht enthalten ist:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Nachdem Sie Rollen definiert haben, können Sie diese über Bindungen auf den Cluster oder den Namespace anwenden. Bindungen verknüpfen Rollen mit ihren Nutzern, Gruppen oder Dienstkonten. Das folgende Beispiel zeigt, wie Sie eine zuvor erstellte Rolle (config-editor) an den Nutzer bob@example.org und den Namespace development binden.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Weitere Informationen zu RBAC finden Sie in der GKE-Dokumentation.

Image-Zugriff und -Freigabe

Images in Container Registry oder Artifact Registry (Beta) werden in Cloud Storage gespeichert. Dieser Abschnitt behandelt zwei Möglichkeiten, wie Images freigegeben werden können. Images können veröffentlicht und projektübergreifend genutzt werden.

Images in Container Registry veröffentlichen

Sie können Images veröffentlichen, indem Sie die Objekte und Buckets veröffentlichen, in denen sie gesichert sind. Detaillierte Anleitungen hierzu finden Sie in der Dokumentation zur Zugriffssteuerung für Container Registry.

Auf Images projektübergreifend in Container Registry zugreifen

Sie können Container-Images projektübergreifend freigeben, indem Sie sicherstellen, dass die Kubernetes-Knoten ein Dienstkonto verwenden. Das mit dem Projekt verknüpfte Standarddienstkonto hat das folgende Format:

project-id-compute@developer.gserviceaccount.com

Wenn Sie diese ID haben, können Sie dem Konto Zugriff als storage.viewer auf die Projekte gewähren, in denen Sie Container Registry verwenden möchten. Verwenden Sie ein benutzerdefiniertes Dienstkonto mit eingeschränkten Berechtigungen, da das Standarddienstkonto Bearbeiterzugriff auf das gesamte Projekt hat.

Wenn Sie für Ihre Cluster ein anderes Dienstkonto verwenden möchten, geben Sie dieses Dienstkonto bei der Cluster- oder Knotenpoolerstellung mithilfe des Flags --service-account an. So verwenden Sie beispielsweise das Dienstkonto gke-sa im Projekt my-project:

gcloud container clusters create west --service-account \
    gke-sa@my-project.google.com.iam.gserviceaccount.com

Informationen zur Migration von Container Registry zu Artifact Registry für Ihre Container-Images finden Sie unter Von Container Registry wechseln.

Richtige Image-Pull-Richtlinie ermitteln

Das Attribut imagePullPolicy bestimmt, ob Kubelet ein Image beim Start eines Pods abruft. Sie müssen eine geeignete imagePullPolicy-Einstellung verwenden, um Ihre Container-Images anzugeben. Sie können beispielsweise die folgende Image-Pull-Richtlinie festlegen:

imagePullPolicy: IfNotPresent

In diesem Fall ruft Kubelet nur dann eine Kopie des Images ab, wenn das Image nicht im Cache des Knotens verfügbar ist.

Weitere Informationen zu den möglichen Image-Pull-Richtlinien, die Sie angeben können, finden Sie in der Kubernetes-Dokumentation unter Container-Images.

Richtlinien mithilfe dynamischer Zulassungs-Webhooks erzwingen

Webhooks für dynamische Zulassungs-Webhooks sind Teil der Kubernetes-Steuerungsebene. Sie können eingehende Anfragen an den API-Server abfangen. Zulassungs-Webhooks sind ein leistungsstarkes Tool, mit dem Sie unternehmensspezifische benutzerdefinierte Richtlinien in Ihren GKE-Clustern erzwingen können.

Kubernetes unterstützt zwei Arten von Zulassungs-Webhooks: mutierende Zulassungs-Webhooks und validierende Zulassungs-Webhooks.

Mutierende Zulassungs-Webhooks fangen Zulassungsanfragen ab und können die Anfrage mutieren (ändern). Die Anfrage wird dann an den API-Server übergeben.

Validierende Zulassungs-Webhooks prüfen eine Anfrage und bestimmen, ob sie gemäß den von Ihnen festgelegten Regeln gültig sind. Wenn im Cluster validierende Zulassungs-Webhooks konfiguriert sind, werden sie aufgerufen, nachdem die Anfrage vom API-Server validiert wurde. Validierende Zulassungs-Webhooks können Anfragen ablehnen, um für Übereinstimmung mit den Richtlinien im Webhook zu sorgen.

Mit einem mutierenden Zulassungs-Webhook können Sie beispielsweise eine Image-Pull-Richtlinie erzwingen, um dafür zu sorgen, dass die Richtlinie auf Always festgelegt ist. Dies geschieht unabhängig von der Einstellung imagePullPolicy, die von Entwicklern angegeben wurde, die Pod-Erstellungsanfragen gesendet haben.

Weitere Hinweise zur Bereitstellung von Images

Es empfiehlt sich, eine private Container Registry wie Container Registry zu verwenden, um die ausgewählten Images Ihrer Organisation zu speichern. Dadurch verringert sich das Risiko, dass Sicherheitslücken in die Bereitstellungspipeline und letztendlich in Anwendungsarbeitslasten eintreten. Wenn möglich, sollten Sie auch die Containeranalyse wie das Scannen auf Sicherheitslücken aktivieren, um die Sicherheitsrisiken weiter zu reduzieren.

Wenn Sie öffentliche Images verwenden müssen, sollten Sie die Menge der öffentlichen Images überprüfen, die in Ihren Clustern bereitgestellt werden können. Weitere Informationen finden Sie im Abschnitt Binärautorisierung. Sie können auch vorgefertigte Kubernetes-Anwendungen aus Google Cloud Marketplace bereitstellen. Die im Google Cloud Marketplace aufgeführten Kubernetes-Anwendungen werden von Google getestet und geprüft. Dazu gehören das Scannen auf Sicherheitslücken und Partnervereinbarungen zur Wartung und für Support.

Achten Sie außerdem auf gute Vorgehensweisen zur Image-Versionsverwaltung. Verwenden Sie daher gute Tag-Konventionen und ziehen Sie zur Verwendung Digests anstelle von Tags in Betracht.

Workload Identity für die Interaktion mit Google Cloud-Dienst-APIs verwenden

Häufig beinhalten Unternehmensarchitekturen Architekturkomponenten von Cloud-Diensten – von der Cloud verwaltete Dienste und gehostete Dienste. GKE-Anwendungen oder -Dienste müssen häufig mit von Google Cloud verwalteten Diensten wie Cloud Storage und BigQuery kommunizieren. Beispiel: Sie müssen Kundendatensätze speichern, nachdem sie von Batchjobs in GKE zur späteren Analyse in BigQuery verarbeitet wurden.

Workload Identity ist ein GKE-Feature, über das Ihre GKE-Dienste mit der gesamten Google Cloud-Umgebung interagieren können, ohne Dienstkonto-Anmeldedaten als Kubernetes-Secrets speichern zu müssen. Mit diesem Feature können Sie ein Kubernetes-Dienstkonto mithilfe einer IAM-Bindung einem Google Cloud-Dienstkonto zuordnen. Wenn Pods schließlich mit dem Kubernetes-Dienstkonto ausgeführt werden, können sie dann die für den Zugriff auf den Google Cloud-Dienst erforderliche Identität annehmen. Dabei wird davon ausgegangen, dass Sie dem Google Cloud-Dienstkonto die erforderliche Zugriffsebene für den Dienst gewährt haben.

Weitere Informationen zu Workload Identity finden Sie in der GKE-Dokumentation.

Clustersicherheit verwalten

Sicherheit ist eine vielschichtige Disziplin, die bei der Bereitstellung von GKE-Clustern in Unternehmen von größter Bedeutung ist. In diesem Abschnitt werden mehrere Faktoren erläutert, mit denen Sie die Sicherheit Ihres Clusters erhöhen können.

Scannen auf Sicherheitslücken für Images

Container Registry kann Images scannen, die per Push-Funktion übertragen wurden, und nach bekannten Sicherheitslücken von Images suchen, die auf Ubuntu, Alpine, Debian, CentOS und RedHat basieren. Wir empfehlen, dass Sie dieses Feature zum Scannen von Images verwenden, die Sie in Ihren Kubernetes-Clustern verwenden möchten.

Sie können Sicherheitslücken für ein Image in der Google Cloud Console oder durch Ausführen des folgenden gcloud-Befehls aufrufen:

gcloud beta container images describe \
    hostname/project-id/image-id:tag  \
    --show-package-vulnerability

Ersetzen Sie Folgendes:

  • hostname: Einer der folgenden Hostname-Standorte:
    • gcr.io, der derzeit die Images in den USA hostet.
    • us.gcr.io, der das Image in den USA in einem separaten Storage-Bucket von Images hostet, die von gcr.io gehostet werden.
    • eu.gcr.io, der die Images in der Europäischen Union hostet.
    • asia.gcr.io, der die Images in Asien hostet.
  • project-id: Die ID des Projekts, das die Images enthält.
  • image-id: Die ID des Images, für das Sie Sicherheitslücken sehen möchten.
  • tag: Das Image-Tag, über das Sie Informationen erhalten möchten.

Ihre Organisation kann vom automatischen Tracking und Erhalt von Benachrichtigungen profitieren, wenn Änderungen an Ihrem Container Registry-Repository vorgenommen werden. So können Sie beispielsweise benachrichtigt werden, wenn ein neues Image erstellt oder ein Image gelöscht wird. Sie können eine Pipeline erstellen, in der Anwendungs-Listener ein Pub/Sub-Thema abonniert haben, in dem Container Registry-Ereignisse veröffentlicht werden. Mit diesen Ereignissen können Sie dann Builds oder automatisierte Bereitstellungen auslösen. Weitere Informationen finden Sie in der Dokumentation zu Container Registry.

Binärautorisierung

Mit Kubernetes müssen Sie bestimmen, ob und wann ein Image für die Bereitstellung in Ihrem Cluster als gültig erachtet werden kann. Für diese Aufgabe können Sie die Binärautorisierung verwenden. Dies ist ein Konstrukt der Bereitstellungszeit, mit dem Sie einen Workflow definieren können, der die Signaturen (Attestierungen) erzwingt, die ein Image haben muss, um in Ihrem Cluster bereitgestellt werden zu können.

Der Workflow wird in Form von Richtlinien definiert. Wenn Sie Ihren Code verschieben und das Container-Image dann über eine CI/CD-Pipeline verschieben, zeichnet die Binärautorisierung für jede dieser Phasen die Attestierungen gemäß der Definition der Binärautorisierung auf. Diese Attestierungen validieren, ob ein Image die definierten Meilensteine erfolgreich bestanden hat.

Die Binärautorisierung ist in die GKE Deployment API integriert. Dadurch wird sichergestellt, dass die Bereitstellung eines Images dem Image unterliegt, das alle erforderlichen Attestierungen hat. Fehlgeschlagene Bereitstellungsversuche werden automatisch geloggt und Clusteradministratoren können sie ansehen und prüfen.

Eine Anleitung zum Implementieren der Binärautorisierung für GKE mit Cloud Build finden Sie unter Binärautorisierung mit Cloud Build und GKE implementieren.

Sicherer Zugriff mit gVisor in der GKE Sandbox

Ein Container bietet eine Sicherheitsebene und eine Kernel-Isolation, kann jedoch anfällig für Sicherheitslücken sein, die Angreifern Zugriff auf das Betriebssystem des Hosts gewähren. Ein robusterer Ansatz für die Sicherheitsisolation zwischen einem Container und seinem Host-Betriebssystem besteht darin, eine weitere Trennschicht zu erstellen. Ein möglicher Ansatz ist die Verwendung von GKE Sandbox.

GKE Sandbox verwendet gVisor, eine Open-Source-Containerlaufzeit, die von Google veröffentlicht wurde. Intern erstellt gVisor einen virtuellen Kernel für die Interaktion mit Containern, der die Reichweite eines Containers zum Host-Kernel abstrahiert. Außerdem erzwingt er die Kontrolle über die Datei- und Netzwerkvorgänge, die der Container ausführen kann.

Da in GKE Sandbox eine zusätzliche Isolationsebene erstellt wird, können zusätzliche Speicher- und CPU-Overhead anfallen: Bevor Sie GKE Sandbox verwenden, sollten Sie sich überlegen, welche Arbeitslasten dieses Sicherheitsniveau benötigen. Dienste, die auf externen Images basieren, sind in der Regel gute Kandidaten.

Der folgende gcloud-Befehl zeigt, wie ein Knotenpool mit aktiviertem GKE Sandbox erstellt wird:

gcloud container node-pools create node-pool-name \
    --cluster=cluster \
    --image-type=cos_containerd \
    --sandbox type=gvisor \
    --enable-autoupgrade

Ersetzen Sie Folgendes:

  • node-pool-name: Der Name des zu erstellenden Moduspools.
  • cluster: Der Cluster, dem der Knotenpool hinzugefügt werden soll.

Wenn Sie angeben möchten, welche Anwendungs-Pods mit GKE Sandbox ausgeführt werden, fügen Sie gVisor in die Pod-Spezifikation ein, wie im folgenden Beispiel gezeigt:

apiVersion: v1
kind: Pod
metadata:
  name: sample-saas-app
  labels:
    app: saas-v1
spec:
  runtimeClassName: gvisor
  containers:
    - name: sample-node-app-v1
      image: [image]

Weitere Informationen zu GKE Sandbox finden Sie im Google Cloud-Blog unter GKE Sandbox: Schutz auf Ihre Pods anwenden. Weitere Informationen darüber, ob Ihre Anwendung für GKE Sandbox geeignet ist, finden Sie in der GKE-Dokumentation.

Audit-Logging

Das Kubernetes-Audit-Logging zeichnet alle API-Anfragen auf, die an den Kubernetes API-Server gesendet werden. Dieses Logging hilft Ihnen, Anomalien und ungewöhnliche Muster in der Zugriffs- und Konfigurationseinrichtung zu erkennen. Achten Sie beispielsweise auf Folgendes:

  • Bereitstellung löschen.
  • Anhängen an oder mit exec auf einen Container zugreifen, der privilegierten Zugriff hat.
  • ClusterRole-Objekte ändern oder Rollenbindungen für die Clusterrollen erstellen.
  • Dienstkonten im Namespace kube-system erstellen.

GKE integriert das Audit-Logging von Kubernetes in Cloud Logging. Sie können auf diese Logs genauso wie auf Logs für Ressourcen zugreifen, die in Ihrem Cloudprojekt ausgeführt werden. An den Kubernetes API-Server gesendete API-Anfragen können geloggt werden. Sie können damit API-Aktivitätsmuster überprüfen.

Jede Anfrage (jedes Ereignis), die vom Kubernetes API-Server erfasst wird, wird mit einer oder mehreren von Ihnen definierten Richtlinien verarbeitet. Dies können entweder Kubernetes-Audit-Richtlinien sein, die bestimmen, welche Ereignisse protokolliert werden, oder es können Audit-Richtlinien von Google Kubernetes Engine sein, die bestimmen, ob die Ereignisse im Administratoraktivitätslog oder im Daten-Log geloggt werden. Administratoraktivitätslogs sind standardmäßig aktiviert. Sie können das Datenzugriffs-Logging auch aktivieren, wenn Sie Details dazu loggen möchten, welche Metadaten und Daten in den Clustern gelesen oder geschrieben wurden. Beachten Sie, dass bei Aktivierung des Loggings für den Datenzugriff zusätzliche Gebühren anfallen können. Weitere Informationen finden Sie in der Dokumentation zur Preisgestaltung.

PodSecurityPolicies

Ein üblicher Angriffsvektor ist die Bereitstellung von Pods mit eskalierten Berechtigungen, um Zugriff auf einen Kubernetes-Cluster zu erhalten. PodSecurityPolicies definieren eine Reihe von Regeln in der Pod-Spezifikation. Diese definieren, welche Aktionen ein Pod ausführen kann. Sie implementieren eine PodSecurityPolicy in Kubernetes als Zugangssteuerungsressource. Sie können damit den Zugriff auf Namespaces und die Verwendung von Volume-Typen und zugrunde liegende Betriebssystemfunktionen einschränken.

Verwenden Sie den folgenden Befehl, um einen GKE-Cluster mit aktivierter PodSecurityPolicy zu erstellen: Ersetzen Sie cluster-name durch den Namen des Clusters, dem Sie eine PodSecurityPolicy hinzufügen.

gcloud beta container clusters create cluster-name \
    --enable-pod-security-policy

Das folgende Beispiel zeigt eine PodSecurityPollicy, die die Möglichkeit begrenzt, privilegierte Pods zu erstellen.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-pod-security-policy
spec:
  privileged: false
  hostPID: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

Überlegungen zur Containersicherheit

Der grundlegende Baustein für Kubernetes-Dienste ist der Container. Dadurch wird die Containersicherheit bei der Planung der Clustersicherheit und -richtlinien ein wichtiger Faktor. Beachten Sie Folgendes:

  • Die Images, aus denen Sie Ihre Container erstellen.
  • Die Berechtigungen, die Sie Containern zuweisen.
  • Interaktion von Containern mit dem Hostbetriebssystem und anderen Diensten.
  • Informationen dazu, wie Container auf vertrauliche Informationen zugreifen und diese loggen.
  • Wie Sie den Lebenszyklus der Container in Ihren Clustern verwalten.

Weitere Informationen und Best Practices finden Sie in der Dokumentation zum Erstellen und Betreiben von Containern.

Netzwerke konfigurieren

Kubernetes bietet eine Dienstabstraktion, die Load-Balancing und Diensterkennung für Pod-Gruppen innerhalb eines Clusters sowie für Legacy-Systeme außerhalb des Clusters umfasst. In den folgenden Abschnitten werden Best Practices für die Kommunikation zwischen Kubernetes-Pods und anderen Systemen einschließlich anderer Kubernetes-Cluster beschrieben.

VPC-native Cluster im Vergleich zu routenbasierten Clustern

Je nachdem, wie GKE-Cluster Traffic von einem Pod an einen anderen weiterleiten, können die Cluster in zwei Typen unterteilt werden. Der erste ist ein Cluster, der Alias-IP-Bereiche für das Routing von Traffic verwendet. Dies wird als VPC-nativer Cluster bezeichnet. Der zweite Cluster verwendet Google Cloud-Routen und wird als routenbasierter Cluster bezeichnet.

VPC-native Cluster verwenden Alias-IP-Bereiche für Pod-Netzwerke. Das bedeutet, dass die Steuerungsebene automatisch die Routingkonfiguration für Pods verwaltet, anstatt statische Routen für jeden Knoten im GKE-Cluster zu konfigurieren und zu verwalten. Mit Alias-IP-Bereichen können Sie mehrere interne IP-Adressen konfigurieren, die in einer VM gehostete Container oder Anwendungen darstellen, ohne eine separate Netzwerkschnittstelle definieren zu müssen. Google Cloud installiert automatisch für das Subnetz der primären Netzwerkschnittstelle VPC-Netzwerkrouten für primäre und Alias-IP-Bereiche. Dies vereinfacht die Weiterleitung von Pod-zu-Pod-Traffic erheblich.

Darüber hinaus unterliegen VPC-native Cluster nicht den Routenkontingenten. Die Nutzung von Alias-IP-Bereichen in der Clusterstruktur bietet direkten Zugriff auf Google-Dienste wie Cloud Storage und BigQuery. Dieser Zugriff wäre andernfalls nur mit einem NAT-Gateway möglich.

Üblicherweise stellen Unternehmen ihre GKE-Cluster sicher mit ihrem lokalen System aus Anwendungen und Diensten bereit. Alias-IP-Bereiche ermöglichen dies, da die Alias-IP-Adressen über Cloud VPN oder Cloud Interconnect gefunden werden können. So erhalten Sie eine sichere Verbindung zwischen Ihrer lokalen und der Google Cloud-Infrastruktur.

Sie müssen entscheiden, welcher Clustertyp am besten für Ihre Netzwerktopologie geeignet ist. Wichtige Faktoren sind die Verfügbarkeit von IP-Adressen in Ihrem Netzwerk, Clustererweiterungspläne (Knoten) in Ihrem Unternehmen und Verbindungen zu anderen Anwendungen im System. VPC-native Cluster verwenden in der Regel mehr IP-Adressen im Netzwerk. Daher sollten Sie dies berücksichtigen. Beachten Sie, dass Sie einen VPC-nativen Cluster nach der Erstellung und einem routenbasierten Cluster nicht zu einem VPC-nativen Cluster migrieren können. Daher ist es wichtig, die Auswirkungen Ihrer Wahl vor der Implementierung zu verstehen.

Innerhalb desselben Clusters kommunizieren

Diensterkennung

Kubernetes ermöglicht es Ihnen, Dienste zu definieren, die anhand einer Reihe von Labels Pods gruppieren, die in dem Cluster ausgeführt werden. Eine solche Gruppe von Pods kann innerhalb des Clusters mithilfe von DNS erkannt werden. Weitere Informationen zur Diensterkennung in Kubernetes finden Sie in der Dokumentation Anwendungen mit Diensten verbinden.

DNS

In jedem GKE-Cluster wird ein im Cluster lokal angesiedelter DNS-Server kube-dns bereitgestellt, der die Zuordnung von Dienstnamen zu fehlerfreien Pod-IPs übernimmt. Standardmäßig gibt der Kubernetes DNS-Server die Cluster-IP-Adresse des Dienstes zurück. Diese IP-Adresse ist während der gesamten Lebensdauer des Dienstes statisch. Wenn Traffic an diese IP-Adresse gesendet wird, laden die IP-Tabellen auf dem Knoten Load-Balancing-Pakete auf Pods, die bereit sind und den Auswahlkriterien des Dienstes entsprechen. Diese IP-Tabellen werden von dem auf jedem Knoten ausgeführten Dienst kube-proxy automatisch programmiert.

Wenn Sie Diensterkennung und Systemüberwachung wünschen, der DNS-Dienst Ihnen jedoch die IP-Adressen von Pods statt einer virtuellen IP-Adresse zurückgeben soll, können Sie den Dienst mit dem Feld "ClusterIP" auf "Keine" bereitstellen. Der Dienst wird dadurch monitorlos. In diesem Fall gibt der DNS-Server eine Liste von A-Einträgen zurück. Diese ordnen den DNS-Namen Ihres Dienstes den A-Einträgen der einsatzbereiten Pods zu, die den vom Dienst definierten Label-Auswahlkriterien entsprechen. Die Datensätze in der Antwort rotieren, damit für ein einfacheres Load-Balancing auf die verschiedenen Pods gesorgt ist. Einige clientseitige DNS-Resolver speichern möglicherweise DNS-Antworten im Cache und machen die A-Datensatzrotation damit unwirksam. Die Vorteile der Verwendung der ClusterIP sind in der Kubernetes-Dokumentation aufgeführt.

Ein typischer Anwendungsfall für monitorlose Dienste sind StatefulSets. StatefulSets eignen sich ideal zum Ausführen von zustandsorientierten Anwendungen, für die ein stabiler Speicher und ein stabiles Netzwerk zwischen den Replikaten erforderlich ist. Diese Art der Bereitstellung stellt Pods zur Verfügung, die eine stabile Netzwerkidentität haben. Dies bedeutet, ihre Hostnamen können im Cluster aufgelöst werden. Obwohl sich die IP-Adresse des Pods ändern kann, bleibt der DNS-Eintrag des Hostnamens aktuell und auflösbar.

Paketfluss: ClusterIP

Im folgenden Diagramm sehen Sie die DNS-Antwort und den Paketfluss eines Kubernetes-Standarddienstes. Während Pod-IP-Adressen von außerhalb des Clusters routbar sind, ist der Zugriff auf die Cluster-IP-Adresse eines Dienstes nur innerhalb des Clusters möglich. Diese virtuellen IP-Adressen werden durch Ausführung einer Zielnetzwerkadressübersetzung (Destination Network Address Translation, DNAT) in jedem Kubernetes-Knoten implementiert. Der auf jedem Knoten ausgeführte Dienst kube-proxy hält die Weiterleitungsregeln auf allen Knoten aktuell, die die Cluster-IP-Adresse den IP-Adressen fehlerfreier Pods im gesamten Cluster zuordnen. Wenn ein Pod des Dienstes auf dem lokalen Knoten ausgeführt wird, wird dieser Pod verwendet, andernfalls wird ein zufällig ausgewählter Pod im Cluster verwendet.

ClusterIP-Dienst.

Weitere Informationen zur Implementierung von ClusterIP finden Sie in der Kubernetes-Dokumentation. Details zu GKE-Netzwerken finden Sie im "Next 2017 Talk" auf YouTube:

Monitorlose Dienste

Im Folgenden finden Sie ein Beispiel für die DNS-Antwort und das Traffic-Muster für einen monitorlosen Dienst. Pod-IP-Adressen sind über standardmäßige Routingtabellen für Google Cloud-Subnetze routbar. Ihre Anwendung greift direkt auf sie zu.

Beispiel-DNS-Antwort und Traffic-Muster für monitorlosen Dienst.

Netzwerkrichtlinien

Sie können mit der GKE-Netzwerkrichtlinien erzwingen die Kommunikation zwischen den Pods und Diensten eines Clusters steuern. Zum Festlegen einer Netzwerkrichtlinie in GKE können Sie mit der Kubernetes Network Policy API Firewallregeln auf Pod-Ebene erstellen. Diese Firewallregeln bestimmen, welche Pods und Dienste in einem Cluster aufeinander zugreifen können.

Netzwerkrichtlinien sind eine Art von Verteidigungsintention, die die Sicherheit der in Ihrem Cluster ausgeführten Arbeitslasten verbessert. Beispielsweise lässt sich mit einer Netzwerkrichtlinie verhindern, dass ein manipulierter Front-End-Dienst in einer Anwendung direkt mit einem mehrere Ebenen tieferen Abrechnungs- oder Buchhaltungsdienst kommuniziert.

Netzwerkrichtlinien können auch zum Isolieren von Arbeitslasten verwendet werden, die zu verschiedenen Mandanten gehören. Sie können beispielsweise eine sichere Mehrmandantenfähigkeit bereitstellen, indem Sie ein Mandanten-pro-Namespace-Modell festlegen. In diesem Modell können Regeln von Netzwerkrichtlinien dafür sorgen, dass Pods und Dienste in einem bestimmten Namespace nicht auf andere Pods oder Dienste in einem anderen Namespace zugreifen können.

Weitere Informationen zu Netzwerkrichtlinien finden Sie in der GKE-Dokumentation.

Verbindung zu einem GKE-Cluster in Google Cloud herstellen

Wenn Sie eine Verbindung zu Ihren Diensten von außerhalb des Clusters, aber innerhalb des privaten IP-Adressbereichs des Google Cloud-Netzwerks herstellen möchten, verwenden Sie das interne Load-Balancing. Wenn Sie einen Dienst mit type: Load Balancer und einer cloud.google.com/load-balancer-type: Internal-Annotation in Kubernetes erstellen, wird in Ihrem Google-Projekt ein interner Netzwerk-Load-Balancer erstellt und für die Verteilung von TCP- und UDP-Traffic zwischen Pods konfiguriert.

Verbindung von innerhalb eines Clusters zu externen Diensten herstellen

In vielen Fällen ist es notwendig, eine Verbindung Ihrer Anwendungen, die innerhalb von Kubernetes ausgeführt werden, zu einem Dienst, einer Datenbank oder einer Anwendung herzustellen, die sich außerhalb des Clusters befindet. Ihnen stehen dafür die folgenden drei Optionen zur Verfügung.

Stub-Domains

In Kubernetes 1.6 und höher können Sie den clusterinternen DNS-Dienst (kube-dns) zur Weiterleitung von DNS-Anfragen einer bestimmten Domain an einen externen DNS-Server konfigurieren. Dies ist nützlich, wenn Sie autoritative DNS-Server haben, die für eine Domain angefragt werden sollen, die Ihre Kubernetes-Pods nutzen müssen.

Externe Namensdienste

Externe Namensdienste ermöglichen Ihnen die Zuordnung eines DNS-Datensatzes zu einem Dienstnamen im Cluster. In diesem Fall gibt die DNS-Suche nach dem Dienst im Cluster einen CNAME-Datensatz Ihrer Wahl zurück. Verwenden Sie diese Methode, wenn Sie nur einige Datensätze haben, die Sie vorhandenen DNS-Diensten zuordnen möchten.

Dienste ohne Auswahlkriterien

Sie können Dienste ohne ein Auswahlkriterium erstellen und dann manuell Endpunkte hinzufügen, um die Diensterkennung mit den richtigen Werten auszufüllen. Dadurch können Sie denselben Diensterkennungsmechanismus für Dienste im Cluster verwenden und gleichzeitig sicherstellen, dass auch Systeme ohne Diensterkennung über DNS erreichbar sind. Dieser Ansatz weist zwar die größte Flexibilität auf, erfordert aber langfristig ein hohes Maß an Konfiguration und Wartung.

Weitere Informationen zu DNS finden Sie auf der Dokumentationsseite DNS-Pods und -Dienste in Kubernetes.

Dienste in Kubernetes für den Empfang von Internet-Traffic konfigurieren

Kubernetes-Dienste können mit NodePort, ClusterIP und LoadBalancer bereitgestellt werden.

Wenn Sie jedoch viele nach außen gerichtete Dienste haben, können Sie Ingress-Ressourcen von Kubernetes verwenden. Ingress bietet einen Einstiegspunkt für Ihren Cluster und ermöglicht Ihnen die Definition von Routingregeln, die eingehende Anfragen an einen oder mehrere Back-End-Dienste in Ihrem Cluster weiterleiten. In GKE implementiert der GKE-Ingress-Controller eine Ingress-Ressource als Google Cloud HTTP(S)-Load-Balancer und konfiguriert sie gemäß den Informationen in der Ingress-Ressource und den zugehörigen Diensten.

Eine Kubernetes Ingress-Ressource kann nur verwendet werden, wenn Ihre Anwendungen Traffic über HTTP(S) bereitstellen. Wenn Ihre Back-End-Dienste TCP- oder UDP-Protokolle verwenden, müssen Sie stattdessen einen Netzwerk-Load-Balancer verwenden. Dies kann beispielsweise erforderlich sein, wenn Sie Ihre Datenbank als Dienst bereitstellen müssen.

Back-End-Konfiguration

Eine BackendConfig ist eine benutzerdefinierte Ressourcendefinition, die eine zusätzliche präskriptive Konfiguration bereitstellen kann, die vom Kubernetes Ingress-Controller verwendet wird. Wenn Sie ein Ingress-Objekt in Ihrem GKE-Cluster bereitstellen, konfiguriert der Kubernetes-Ingress-Controller einen HTTP(S)-Load-Balancer, der eingehende Anfragen wie im Ingress-Manifest an die Back-End-Dienste weiterleitet.

Sie können die Konfiguration des Load-Balancers mit Spezifikationen wie den folgenden ergänzen:

  • Caching mit Cloud CDN aktivieren
  • Hinzufügen von IP-Adressen oder CIDR-Genehmigungslisten (weiße Listen) mit Google Cloud Armor.
  • Zugriff auf Anwendungsebene mit dem Identity-Aware Proxy (IAP) steuern
  • Zeitlimits für Dienste und Verbindungs-Draining für Dienste konfigurieren, die dem Ingress-Objekt in einem Cluster unterliegen.

Weitere Informationen zum Konfigurieren der benutzerdefinierten BackendConfig-Ressource in GKE finden Sie in der GKE-Dokumentation.

Service Mesh verwenden

Ein Service Mesh bietet eine einheitliche Möglichkeit zum Verbinden, Sichern und Verwalten von Mikrodiensten, die in Ihren Kubernetes-Clustern ausgeführt werden. Beispielsweise kann das Istio-Service Mesh, das Sie als GKE-Add-on hinzufügen können, die Authentifizierung und Kommunikation zwischen Diensten verwalten, Zugriffsrichtlinien erzwingen und umfangreiche Telemetriedatenpunkte erfassen, mit denen Sie Ihre GKE-Cluster prüfen und verwalten können.

Das Service Mesh bietet die folgenden wichtigen Features:

  • Trafficverwaltung. Mit dem Service Mesh können Sie detaillierte Regeln definieren, die festlegen, wie Traffic weitergeleitet und auf verschiedene Versionen desselben Dienstes aufgeteilt werden soll. Dies vereinfacht die Einführung von Canary- und Blau/Grün-Bereitstellungen.

  • Integrierte Beobachtbarkeit: Das Mesh-Netzwerk erfasst einheitlich Messwerte zum Netzwertraffic (Ebene 4 und Ebene 7), ohne dass Sie Code für die Instrumentierung Ihrer Dienste schreiben müssen.

  • Sicherheit. Das Mesh-Netzwerk ermöglicht gegenseitige TLS (mTLS) zwischen Diensten. Es bietet nicht nur sichere Kanäle für die Datenübertragung, sondern hilft Ihnen auch bei der Verwaltung der Authentifizierung und Autorisierung von Diensten innerhalb des Mesh-Netzwerks.

Zusammenfassung: Mit Service Meshes wie Istio können Sie Aufgaben auf Systemebene an die Mesh-Infrastruktur delegieren. Dadurch werden die allgemeine Flexibilität, Robustheit und die Zusammenführung von Diensten verbessert, die in Ihren Kubernetes-Clustern ausgeführt werden.

Weitere Informationen finden Sie unter Istio in Google Kubernetes Engine.

Firewalls

GKE-Knoten werden als Instanzen in Compute Engine bereitgestellt. Daher richten sie sich nach demselben zustandsorientierten Firewallmechanismus wie andere Instanzen. Diese Firewallregeln werden im Netzwerk durch Verwendung von Tags auf Instanzen angewendet. Jeder Knotenpool erhält einen eigenen Satz von Tags, die Sie in Regeln verwenden können. Standardmäßig erhält jede Instanz eines Knotenpools ein Tag, das einen bestimmten Kubernetes Engine-Cluster identifiziert, zu dem dieser Knotenpool gehört. Dieses Tag wird in Firewallregeln verwendet, die Kubernetes Engine automatisch für Sie erstellt. Sie können beim Erstellen des Clusters oder des Knotenpools eigene benutzerdefinierte Tags hinzufügen. Verwenden Sie dazu im gcloud command-line tool-Tool das Flag --tags.

Verwenden Sie beispielsweise die folgenden Befehle, um einem internen Load-Balancer Zugriff auf Port 8080 auf allen Knoten zu gewähren:

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

Das folgende Beispiel zeigt, wie ein Cluster mit einem Tag versehen wird, damit der Internet-Traffic über Port 30000 auf Knoten zugreifen kann. Der andere Cluster wird mit einem Tag versehen, damit Traffic aus dem VPN an Port 40000 zugelassen wird. Dies ist nützlich, wenn ein Dienst über einen NodePort verfügbar gemacht wird, auf den nur über Netzwerke mit entsprechender Berechtigung zugegriffen werden soll. Ein Beispiel wäre der Zugriff eines VPNs auf ein Unternehmensrechenzentrum oder von einem anderen Cluster im Projekt.

Zwei Cluster mit unterschiedlichen Tags versehen.

Verbindung zu einem lokalen Rechenzentrum herstellen

Es gibt verschiedene Cloud Interconnect-Optionen für das Herstellen einer Verbindung zu lokalen Rechenzentren. Diese Optionen schließen sich gegenseitig nicht aus. Sie können sie je nach Arbeitslast und Anforderungen beliebig kombinieren:

  1. Das Internet für Arbeitslasten, die nicht datenintensiv oder latenzempfindlich sind. Google verfügt über mehr als 100 Points of Presence (PoPs), die mit Dienstanbietern weltweit verbunden sind.
  2. Direct Peering für Arbeitslasten, die eine dedizierte Bandbreite erfordern, latenzempfindlich sind und Zugriff auf alle Google-Dienste, einschließlich aller Google Cloud-Produkte, benötigen. Direct Peering ist eine Layer-3-Verbindung, die durch Austausch von BGP-Routen erfolgt und daher eine registrierte ASN erfordert.
  3. Carrier Peering entspricht Direct Peering, erfolgt aber über einen Dienstanbieter. Dies ist eine gute Option, wenn Sie keine registrierte ASN haben oder wenn Sie bereits geschäftliche Beziehungen mit einem bevorzugten Dienstanbieter unterhalten.
  4. Cloud VPN wird über Layer 3 Interconnect und Internetoptionen (1, 2 und 3) konfiguriert, wenn eine IPsec-Verschlüsselung erforderlich ist oder wenn Sie Ihr privates Netzwerk zu einem privaten Compute Engine-Netzwerk ausbauen möchten.

Cluster-Bedienbarkeit verwalten

In diesem Abschnitt werden die wichtigsten Faktoren beschrieben, die bei der Verwaltung und Ausführung Ihrer GKE-Cluster zu berücksichtigen sind.

Ressourcenkontingente

Kubernetes-Ressourcenkontingente sind Einschränkungen, die den aggregierten zulässigen Ressourcenverbrauch für jeden Namespace in einem Cluster begrenzen. Wenn Sie Cluster mit Kubernetes-Namespaces haben, die Geschäftsfunktionen oder Entwicklungsphasen isolieren, können Sie mithilfe von Kontingenten ein breites Spektrum an Ressourcen wie CPU-Auslastung, Arbeitsspeicher oder die Anzahl der Pods und Dienste begrenzen, die innerhalb eines Namespace erstellt werden können. Um die Stabilität der Steuerungsebene Ihrer GKE-Cluster zu gewährleisten, wendet Kubernetes automatisch nicht überschreibbare Ressourcenkontingente auf jeden Namespace in GKE-Clustern mit maximal fünf Knoten an.

Ressourcenlimits

Sie können das Kubernetes-Objekt LimitRange verwenden, um detaillierte Einschränkungen für die minimalen und maximalen Ressourcengrenzen zu erzwingen, mit denen Container und Pods erstellt werden können. Das folgende Beispiel zeigt die Verwendung von LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Budgets für Pod-Unterbrechungen

Budgets für Pod-Unterbrechungen (Pod Disruption Budgets, PDBs) tragen zum Schutz vor dem freiwilligen oder versehentlichen Löschen von Pods oder Bereitstellungen in Ihrem Team bei. PDBs können nicht versehentliche Unterbrechungen verhindern, die durch einen Ausfall oder einen Neustart eines Knotens verursacht werden können. In der Regel erstellt ein Operator eine PDB für eine Anwendung, in der die Mindestanzahl an Replikaten der Pods definiert wird, die für die Anwendung ausgeführt werden sollen.

In einem Unternehmen, in dem Entwickler an mehreren Anwendungen arbeiten, treten Fehler auf und ein Entwickler oder Administrator kann versehentlich ein Skript ausführen, das Pods oder Bereitstellungen löscht, d. h., die Kubernetes-Ressourcen werden gelöscht. Durch die Definition einer PDB sorgen Sie jedoch dafür, dass Sie immer einen minimalen Satz von Ressourcen für Ihre Kubernetes-Anwendungen verwalten müssen.

PDBs, die Sie für Ihre GKE-Cluster konfigurieren, werden während GKE-Upgrades berücksichtigt. Dies bedeutet, dass Sie die Verfügbarkeit Ihrer Anwendungen während eines Upgrades steuern können. Das folgende Beispiel zeigt, wie Sie ein PDB konfigurieren.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Kubernetes-Upgrades verwalten

Sie sollten Ihre Kubernetes-Cluster in GKE auf die neueste Version von Kubernetes aktualisieren, die Ihren Anforderungen entspricht. Dadurch können Sie neue Funktionen nutzen, die eingeführt werden, und dafür sorgen, dass das zugrunde liegende Betriebssystem Ihrer Clusterknoten gepatcht und aktuell ist.

Wenn ein Upgrade erforderlich ist, können Sie die folgenden Typen berücksichtigen:

  • Upgrades der Haupt- und Nebenversionen von Kubernetes Ihres GKE-Clusters für die Master- und Worker-Knoten.
  • Betriebssystem-Patches und -Upgrades der virtuellen Maschinen (Knoten), aus denen sich Ihr Cluster zusammensetzt.

Kubernetes-Version aktualisieren

Sie haben zwei Möglichkeiten, Ihre GKE-Master-Knoten zu aktualisieren. Die erste Option besteht darin, dass Google Cloud Ihren GKE-Clustermaster automatisch aktualisiert. Die zweite ist das Starten eines manuellen Upgrades, wenn eine neuere Version verfügbar ist.

In der Konsole werden für Ihre GKE-Cluster Benachrichtigungen angezeigt, wenn Upgrades verfügbar sind. Wir empfehlen, das Versionsupgrade auszulösen, nachdem Sie den Releaseinhalt überprüft haben und Sie Ihre Anwendungen in einem Sandbox-Cluster getestet haben, der mit der gewünschten Upgrade-Version ausgeführt wird.

Wenn für den Master-Knoten eines zonalen Clusters ein Upgrade durchgeführt wird, ist die Steuerungsebene nicht verfügbar. Dies bedeutet, dass Sie nicht mit dem API-Server interagieren können, um Ressourcen in Ihrem Cluster hinzuzufügen oder zu entfernen. Wenn Sie die Ausfallzeit beim Upgrade eines Master-Knotens in Ihrem zonalen Cluster nicht berücksichtigen können, können Sie den Master-Knoten hochverfügbar machen, indem Sie regionale GKE-Cluster bereitstellen. Mit diesem Ansatz können Sie mehrere Master-Knoten haben, die über Zonen verteilt sind. Wird ein Master-Knoten aktualisiert, werden alle Anfragen der Steuerungsebene an den API-Server zum anderen Master-Knoten bzw. zu den anderen Knoten weitergeleitet.

Wie bei Master-Knoten haben Sie zwei Möglichkeiten, Ihre GKE-Worker-Knoten auf dieselbe Version wie der Master-Knoten des Clusters zu aktualisieren:

  • GKE kann die Upgrades der Worker-Knoten für Sie verwalten. Dazu aktivieren Sie das automatische Knotenupgrade für die Knotenpools in Ihrem GKE-Cluster.
  • Sie können Ihre GKE-Worker-Knoten manuell aktualisieren. Wenn ein Upgrade verfügbar ist, zeigt die GKE-Konsole eine Benachrichtigung an. Wenn Sie diese Benachrichtigung sehen, können Sie das Upgrade auf Ihre GKE-Worker-Knoten anwenden.

In beiden Fällen wendet GKE bei der Anwendung eines Upgrades ein Rolling Update auf die Worker-Knoten an. Es wird systematisch jeweils ein Knoten entleert, heruntergefahren und aktualisiert, wenn ein neuer Ersatzknoten verfügbar ist, um auf eingehende Anfragen zu reagieren.

Automatische Knotenreparatur

Die automatische Reparatur für GKE-Knoten verwaltet die Systemdiagnosen Ihrer GKE-Knoten. Wenn einer der Knoten als fehlerhaft erkannt wird, initiiert GKE die Knotenreparatur.

Bei der verwalteten Knotenreparatur wird der Knoten entleert und neu erstellt. Wenn mehrere Knoten in Ihrem GKE-Cluster gleichzeitig repariert werden müssen, bestimmt Google Cloud intern, wie viele Knoten parallel repariert werden können.

Wenn Sie Cluster in der Google Cloud Console erstellen, ist das automatische Reparaturfeature automatisch aktiviert. Für die GKE-Cluster, die Sie mit dem gcloud command-line tool-Tool erstellen, können Sie die automatische Reparatur explizit aktivieren, indem Sie das Flag --enable-autorepair in den Befehl zur Clustererstellung aufnehmen.

Wenn Ihr GKE-Cluster über mehrere Knotenpools verfügt, können Sie mit der automatischen Reparatur genau steuern, für welche Knotenpools die automatische Knotenreparatur aktiviert werden soll.

Autoscaling von GKE-Clustern

Unternehmen haben oft eine unterschiedliche eingehende Auslastung der Anwendungen, die in ihren Kubernetes-Clustern ausgeführt werden. Sie können Ihre GKE-Cluster so einstellen, dass sie auf diese geschäftlichen Änderungen automatisch reagieren und anhand von Messwerten eine vertikale oder horizontale Skalierung vornehmen.

Autoscaling umfasst mehrere Dimensionen, wie in den folgenden Abschnitten beschrieben.

Cluster Autoscaler

Der Cluster Autoscaler von GKE fügt Ihrem Cluster je nach Bedarf der Arbeitslasten automatisch Knoten hinzu oder entfernt diese. Der Cluster Autoscaler ist für einzelne Knotenpools aktiviert. Für jeden Knotenpool prüft GKE, ob Pods vorhanden sind, die aufgrund fehlender Kapazitäten geplant werden sollen. Wenn dies der Fall ist, fügt der Cluster Autoscaler diesem Knotenpool Knoten hinzu.

Die Skalierung wird durch verschiedene Faktoren beeinflusst. Wenn ein Knoten von den darauf ausgeführten Pods weniger als 50 % genutzt wird und die ausgeführten Pods auf anderen Knoten ausgeführt werden können, die über Kapazitäten verfügen, wird der nicht ausgelastete Knoten per Drain beendet.

Sie können die Grenzen für einen Knotenpool festlegen, indem Sie die minimalen und maximalen Knoten angeben, auf die der Cluster Autoscaler skalieren kann.

Horizontales Pod-Autoscaling (HPA).

Mit Kubernetes können Sie ein horizontales Pod-Autoscaling (HPA) erstellen, um festzulegen, wie Ihre Kubernetes-Bereitstellungen oder -ReplicaSets skaliert werden sollen und auf welchen Messwerten die Skalierungsentscheidung basieren soll. Standardmäßig bestimmt der HPA-Controller die Autoscaling-Entscheidungen zur CPU-Auslastung. Der HPA-Controller kann jedoch berechnen, wie Pods basierend auf benutzerdefinierten Messwerten, z. B. der Anzahl der HTTP-Anfragen, skaliert werden sollen. Damit ein HPA auf benutzerdefinierte Messwerte reagiert, ist normalerweise zusätzliche Monitoring-Instrumentierung erforderlich.

Weitere Informationen finden Sie in der Dokumentation zu Kubernetes und GKE.

Vertikales Pod-Autoscaling (VPA)

Mit dem Feature Vertikales Pod-Autoscaling (VPA) in GKE-Clustern können Sie die Aufgabe festlegen, optimale CPU- und Speicheranforderungen für Container anzugeben. Bei Bedarf optimiert VPA die Ressourcenzuweisungen, die an Container in Ihrem Cluster vorgenommen wurden. Mit VPA können Sie die Ressourcennutzung für Cluster optimieren, indem Sie auf Containerebene die Knoten einzeln optimieren. Außerdem sparen Sie Zeit, die Sie in die Verwaltung Ihrer Ressourcen investieren müssten.

VPA arbeitet zusammen mit der automatischen Knotenbereitstellung, die im nächsten Abschnitt beschrieben wird.

Aufgrund von Kubernetes-Einschränkungen können die Ressourcenanfragen für einen Pod nur geändert werden, wenn ein Pod neu gestartet wird. Daher entfernt der VPA den Pod, um Änderungen vorzunehmen. Weitere Informationen finden Sie in der Dokumentation zu GKE und Kubernetes.

Automatische Bereitstellung von Knoten

Mit der automatischen Knotenbereitstellung kann Cluster Autoscaler von GKE automatisch zusätzliche Knotenpools bereitstellen, wenn der Autoscaler feststellt, dass diese erforderlich sind. Cluster Autoscaler kann auch automatisch bereitgestellte Knotenpools löschen, wenn sich in diesen Knotenpools keine Knoten befinden.

Entscheidungen bezüglich der automatischen Knotenbereitstellung werden vom GKE Cluster Autoscaler anhand einer Reihe von Faktoren getroffen. Dazu gehören die von Pods angefragten Ressourcen, von Ihnen angegebene Pod-Affinitäten sowie Knotenmarkierungen und -toleranzen, die in Ihrem GKE-Cluster definiert sind.

Die automatische Knotenbereitstellung ist nützlich, wenn Sie in Ihren GKE-Clustern viele Arbeitslasten ausführen. Wenn Ihr GKE-Cluster beispielsweise eine GPU-abhängige Arbeitslast hat, können Sie sie in einem dedizierten Knotenpool ausführen, der mit GPU-fähigen Knoten bereitgestellt wird. Sie können die Skalierungsgrenzen des Knotenpools definieren, indem Sie eine minimale und maximale Knotenpoolgröße angeben.

Weitere Informationen zur automatischen Knotenbereitstellung und deren Aktivierung finden Sie unter Automatische Knotenbereitstellung verwenden.

Weitere Informationen