In dieser Anleitung wird beschrieben, wie Sie die knoteninterne Sichtbarkeit in einem GKE-Cluster (Google Kubernetes Engine) einrichten.
Die knoteninterne Sichtbarkeit konfiguriert das Netzwerk auf jedem Knoten im Cluster, sodass der von einem Pod an einen anderen Pod gesendete Traffic vom VPC-Netzwerk (Virtual Private Cloud) des Clusters verarbeitet wird, auch wenn sich die Pods auf demselben Knoten befinden.
Knoteninterne Sichtbarkeit ist in Standardclustern standardmäßig deaktiviert und in Autopilot-Clustern standardmäßig aktiviert.
Architektur
Knoteninterne Sichtbarkeit sorgt dafür, dass zwischen Pods gesendete Pakete immer vom VPC-Netzwerk verarbeitet werden. Dadurch wird gesorgt, dass Firewallregeln, Routen, Flusslogs und Paketspiegelungskonfigurationen auf die Pakete angewendet werden.
Wenn ein Pod ein Paket an einen anderen Pod auf demselben Knoten sendet, verlässt das Paket den Knoten und wird vom Google Cloud-Netzwerk verarbeitet. Das Paket wird anschließend sofort zum selben Knoten zurückgesendet und zum Ziel-Pod weitergeleitet.
Mit der knoteninternen Sichtbarkeit wird das DaemonSet netd
bereitgestellt.
Vorteile
Die knoteninterne Sichtbarkeit bietet folgende Möglichkeiten:
- Flusslogs für den gesamten Traffic zwischen den Pods ansehen, einschließlich des Traffics zwischen Pods auf demselben Knoten,
- Firewall-Regeln erstellen, die für den gesamten Traffic zwischen Pods gelten, einschließlich des Traffics zwischen Pods auf demselben Knoten.
- Paketspiegelung verwenden, um Traffic zu klonen, einschließlich Traffic zwischen Pods auf demselben Knoten, und diesen zur Untersuchung weiterleiten.
Anforderungen und Einschränkungen
Für die knoteninterne Sichtbarkeit gelten die folgenden Anforderungen und Einschränkungen:
- Ihr Cluster muss die GKE-Version 1.15 oder höher haben.
- Die knoteninterne Sichtbarkeit wird von Windows Server-Knotenpools nicht unterstützt.
- Wenn Sie die Sichtbarkeit innerhalb des Knotens aktivieren und den
ip-masq-agent
verwenden, der mit dem ParameternonMasqueradeCIDRs
konfiguriert ist, müssen Sie den Pod-CIDR-Bereich innonMasqueradeCIDRs
einschließen, um Probleme mit der Konnektivität innerhalb des Knotens zu vermeiden.
Firewallregeln
Wenn Sie die knoteninterne Sichtbarkeit aktivieren, verarbeitet das VPC-Netzwerk alle zwischen Pods gesendeten Pakete, einschließlich Pakete, die zwischen Pods auf demselben Knoten gesendet werden. Daher gelten VPC-Firewallregeln und hierarchische Firewallrichtlinien konsistent für die Pod-zu-Pod-Kommunikation, unabhängig vom Standort des Pods.
Wenn Sie benutzerdefinierte Firewallregeln für die Kommunikation innerhalb des Clusters konfigurieren, müssen Sie das Netzwerk Ihres Clusters sorgfältig bewerten, um die Gruppe der Regeln für ausgehenden Traffic und eingehenden Traffic zu bestimmen. Sie können Konnektivitätstests verwenden, um sicherzustellen, dass legitimer Traffic nicht blockiert wird. Beispielsweise ist die Pod-zu-Pod-Kommunikation erforderlich, damit die Netzwerkrichtlinie angewendet werden kann.
Hinweis
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components update
ab.
Knoteninterne Sichtbarkeit für einen neuen Cluster aktivieren
Mit der gcloud CLI oder mit der Google Cloud Console können Sie einen Cluster mit aktivierter knoteninterner Sichtbarkeit erstellen.
gcloud
Um einen Cluster mit einem einzelnen Knoten zu erstellen, für den die knoteninterne Sichtbarkeit aktiviert ist, verwenden Sie das Flag --enable-intra-node-visibility
:
gcloud container clusters create CLUSTER_NAME \
--region=COMPUTE_REGION \
--enable-intra-node-visibility
Dabei gilt:
CLUSTER_NAME
: Der Name des neuen Clusters.COMPUTE_REGION
. die Compute-Region für den Cluster.
Console
Um einen Cluster mit einem einzelnen Knoten zu erstellen, für den die knoteninterne Sichtbarkeit aktiviert ist, führen Sie die folgenden Schritte aus:
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_boxErstellen.
Geben Sie den Namen für den Cluster ein.
Klicken Sie im Dialogfeld Cluster konfigurieren neben GKE Standard auf Konfigurieren.
Konfigurieren Sie den Cluster nach Bedarf.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Klicken Sie auf das Kästchen Knoteninterne Sichtbarkeit aktivieren.
Klicken Sie auf Erstellen.
Knoteninterne Sichtbarkeit für einen vorhandenen Cluster aktivieren
Sie können die knoteninterne Sichtbarkeit für einen vorhandenen Cluster mit der gcloud CLI oder mit der Google Cloud Console aktivieren.
Wenn Sie die knoteninterne Sichtbarkeit für einen vorhandenen Cluster aktivieren, werden von GKE Komponenten sowohl auf der Steuerungsebene als auch auf den Worker-Knoten neu gestartet.
gcloud
Mit dem Flag --enable-intra-node-visibility
können Sie die knoteninterne Sichtbarkeit für einen vorhandenen Cluster aktivieren:
gcloud container clusters update CLUSTER_NAME \
--enable-intra-node-visibility
Ersetzen Sie dabei CLUSTER_NAME
durch den Namen Ihres Clusters.
Console
Um die knoteninterne Sichtbarkeit für einen vorhandenen Cluster zu aktivieren, führen Sie die folgenden Schritte aus:
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Netzwerk auf edit Knoteninterne Sichtbarkeit bearbeiten.
Klicken Sie auf das Kästchen Knoteninterne Sichtbarkeit aktivieren.
Klicken Sie auf Änderungen speichern.
Knoteninterne Sichtbarkeit deaktivieren
Sie können die knoteninterne Sichtbarkeit für einen Cluster mit der gcloud CLI oder mit der Google Cloud Console deaktivieren.
Wenn Sie die knoteninterne Sichtbarkeit für einen vorhandenen Cluster deaktivieren, werden von GKE Komponenten sowohl auf der Steuerungsebene als auch auf den Worker-Knoten neu gestartet.
gcloud
Mit dem Flag --no-enable-intra-node-visibility
deaktivieren Sie die knoteninterne Sichtbarkeit:
gcloud container clusters update CLUSTER_NAME \
--no-enable-intra-node-visibility
Ersetzen Sie dabei CLUSTER_NAME
durch den Namen Ihres Clusters.
Console
Um die knoteninterne Sichtbarkeit zu deaktivieren, führen Sie folgende Schritte aus:
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf:
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Netzwerk auf edit Knoteninterne Sichtbarkeit bearbeiten.
Entfernen Sie das Häkchen aus dem Kästchen Knoteninterne Sichtbarkeit aktivieren.
Klicken Sie auf Änderungen speichern.
Übung: Knoteninterne Sichtbarkeit prüfen
In dieser Übung werden die erforderlichen Schritte erläutert, um die knoteninterne Sichtbarkeit zu aktivieren und zu prüfen, ob sie für Ihren Cluster funktioniert.
Führen Sie in dieser Übung die folgenden Schritte aus:
- Aktivieren Sie Flusslogs für das Standardsubnetz in der Region
us-central1
. - Erstellen Sie einen Cluster mit einem einzelnen Knoten, für den die knoteninterne Sichtbarkeit in der Zone
us-central1-a
aktiviert ist. - Sie erstellen in dem Cluster zwei Pods.
- Senden Sie eine HTTP-Anfrage von einem Pod zu einem anderen.
- Sie sehen sich den Flusslogeintrag für die zwischen den Pods gesendete Anfrage an.
Flusslogs aktivieren
Aktivieren Sie Flusslogs für das Standardsubnetz:
gcloud compute networks subnets update default \ --region=us-central1 \ --enable-flow-logs
Prüfen Sie, ob für das Standardsubnetz Flusslogs aktiviert sind:
gcloud compute networks subnets describe default \ --region=us-central1
Die Ausgabe wie im folgenden Beispiel zeigt, dass Flusslogs aktiviert sind:
... enableFlowLogs: true ...
Cluster erstellen
Erstellen Sie einen Cluster mit einem einzelnen Knoten, für den die knoteninterne Sichtbarkeit aktiviert ist:
gcloud container clusters create flow-log-test \ --zone=us-central1-a \ --num-nodes=1 \ --enable-intra-node-visibility
Rufen Sie die Anmeldedaten für Ihren Cluster ab.
gcloud container clusters get-credentials flow-log-test \ --zone=us-central1-a
Zwei Pods erstellen
Erstellen Sie einen Pod.
Speichern Sie folgendes Manifest in einer Datei mit dem Namen
pod-1.yaml
:apiVersion: v1 kind: Pod metadata: name: pod-1 spec: containers: - name: container-1 image: google/cloud-sdk:slim command: - sh - -c - while true; do sleep 30; done
Wenden Sie das Manifest auf Ihren Cluster an:
kubectl apply -f pod-1.yaml
Erstellen Sie einen zweiten Pod.
Speichern Sie folgendes Manifest in einer Datei mit dem Namen
pod-2.yaml
:apiVersion: v1 kind: Pod metadata: name: pod-2 spec: containers: - name: container-2 image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
Wenden Sie das Manifest auf Ihren Cluster an:
kubectl apply -f pod-2.yaml
Sehen Sie sich die Pods an:
kubectl get pod pod-1 pod-2 --output wide
Die Ausgabe enthält dann die IP-Adressen der Pods wie im folgenden Beispiel:
NAME READY STATUS RESTARTS AGE IP ... pod-1 1/1 Running 0 1d 10.52.0.13 ... pod-2 1/1 Running 0 1d 10.52.0.14 ...
Notieren Sie sich die IP-Adressen
pod-1
undpod-2
.
Anfrage senden
Rufen Sie eine Shell für den Container in
pod-1
ab:kubectl exec -it pod-1 -- sh
Senden Sie in der Shell eine Anfrage an
pod-2
:curl -s POD_2_IP_ADDRESS:8080
Ersetzen Sie dabei
POD_2_IP_ADDRESS
durch die IP-Adressepod-2
.Die Ausgabe zeigt die Antwort des Containers, der auf
pod-2
ausgeführt wird.Hello, world! Version: 2.0.0 Hostname: pod-2
Geben Sie "exit" ein, um die Shell zu verlassen und zur Hauptbefehlszeilenumgebung zurückzukehren.
Flusslogeinträge aufrufen
Um einen Flusslogeintrag aufzurufen, verwenden Sie folgenden Befehl:
gcloud logging read \
'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'
Dabei gilt:
PROJECT_ID
: Ihre Projekt-ID.POD_1_IP_ADDRESS
: ist die IP-Adresse vonpod-1
.POD_2_IP_ADDRESS
: ist die IP-Adresse vonpod-2
.
Die Ausgabe zeigt einen Flusslogeintrag für eine Anfrage von pod-1
an pod-2
. In diesem Beispiel hat pod-1
die IP-Adresse 10.56.0.13
und pod-2
die IP-Adresse 10.56.0.14
.
...
jsonPayload:
bytes_sent: '0'
connection:
dest_ip: 10.56.0.14
dest_port: 8080
protocol: 6
src_ip: 10.56.0.13
src_port: 35414
...
Bereinigen
Um unerwünschte Kosten für Ihr Konto zu vermeiden, entfernen Sie die von Ihnen erstellten Ressourcen und führen dazu folgende Schritte aus:
Löschen Sie den Cluster:
gcloud container clusters delete -q flow-log-test
Deaktivieren Sie Flusslogs für das Standardsubnetz:
gcloud compute networks subnets update default --no-enable-flow-logs
Nächste Schritte
- Kommunikation zwischen den Pods und Services des Clusters durch Erstellen einer Clusternetzwerkrichtlinie steuern
- Informationen zu den Vorteilen von VPC-nativen Clustern