Knoteninterne Sichtbarkeit einrichten

Autopilot Standard

---

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 Parameter nonMasqueradeCIDRs konfiguriert ist, müssen Sie den Pod-CIDR-Bereich in nonMasqueradeCIDRs 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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

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:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf Erstellen.

3. Geben Sie den Namen für den Cluster ein.

4. Klicken Sie im Dialogfeld Cluster konfigurieren neben GKE Standard auf Konfigurieren.

5. Konfigurieren Sie den Cluster nach Bedarf.

6. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

7. Klicken Sie auf das Kästchen Knoteninterne Sichtbarkeit aktivieren.

8. 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:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Netzwerk auf Knoteninterne Sichtbarkeit bearbeiten.

4. Klicken Sie auf das Kästchen Knoteninterne Sichtbarkeit aktivieren.

5. Klicken Sie auf Änderungen speichern.

Warnung: Wenn Sie die knoteninterne Sichtbarkeit aktivieren, berücksichtigt GKE beim Neuerstellen von Knoten die konfigurierten Wartungsfenster. Dies bedeutet, dass die knoteninterne Sichtbarkeit erst nach dem nächsten Wartungsfenster im Cluster verfügbar ist. Wenn Sie nicht warten möchten, können Sie den Knotenpool auch manuell aktualisieren. Dazu geben Sie für das Flag --cluster-version die GKE-Version an, die bereits auf der Steuerungsebene ausgeführt wird. Wenn Sie diese Problemumgehung verwenden, müssen Sie die gcloud CLI verwenden. Weitere Informationen finden Sie unter Hinweise für Wartungsfenster.

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:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf:

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Netzwerk auf Knoteninterne Sichtbarkeit bearbeiten.

4. Entfernen Sie das Häkchen aus dem Kästchen Knoteninterne Sichtbarkeit aktivieren.

5. Klicken Sie auf Änderungen speichern.

Warnung: Wenn Sie die knoteninterne Sichtbarkeit deaktivieren, berücksichtigt GKE beim Neuerstellen von Knoten die konfigurierten Wartungsfenster. Dies bedeutet, dass die knoteninterne Sichtbarkeit erst nach dem nächsten Wartungsfenster deaktiviert wird. Wenn Sie nicht warten möchten, können Sie den Knotenpool auch manuell aktualisieren. Dazu geben Sie für das Flag --cluster-version die GKE-Version an, die bereits auf der Steuerungsebene ausgeführt wird. Wenn Sie diese Problemumgehung verwenden, müssen Sie die gcloud CLI verwenden. Weitere Informationen finden Sie unter Hinweise für Wartungsfenster.

Ü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:

1. Aktivieren Sie Flusslogs für das Standardsubnetz in der Region us-central1.
2. Erstellen Sie einen Cluster mit einem einzelnen Knoten, für den die knoteninterne Sichtbarkeit in der Zone us-central1-a aktiviert ist.
3. Sie erstellen in dem Cluster zwei Pods.
4. Senden Sie eine HTTP-Anfrage von einem Pod zu einem anderen.
5. Sie sehen sich den Flusslogeintrag für die zwischen den Pods gesendete Anfrage an.

Flusslogs aktivieren

1. Aktivieren Sie Flusslogs für das Standardsubnetz:

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. 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

1. 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
   

2. Rufen Sie die Anmeldedaten für Ihren Cluster ab.

   gcloud container clusters get-credentials flow-log-test \
       --zone=us-central1-a
   

Zwei Pods erstellen

1. 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: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f pod-1.yaml
   

3. 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
   

4. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f pod-2.yaml
   

5. 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 und pod-2.

Anfrage senden

1. Rufen Sie eine Shell für den Container in pod-1 ab:

   kubectl exec -it pod-1 -- sh
   

2. Senden Sie in der Shell eine Anfrage an pod-2:

   wget -qO- POD_2_IP_ADDRESS:8080
   

   Ersetzen Sie dabei POD_2_IP_ADDRESS durch die IP-Adresse pod-2.

   Die Ausgabe zeigt die Antwort des Containers, der auf pod-2 ausgeführt wird.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. 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 von pod-1.
• POD_2_IP_ADDRESS: ist die IP-Adresse von pod-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:

1. Löschen Sie den Cluster:

   gcloud container clusters delete -q flow-log-test
   

2. 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