IP-Masquerade-Agent in Standardclustern konfigurieren


Auf dieser Seite wird erläutert, wie Sie Cluster konfigurieren, die im GKE-Standardmodus (Google Kubernetes Engine) für die IP-Maskierung mit ip-masq-agent erstellt wurden. Weitere Informationen zur IP-Maskierung im Autopilot-Modus von GKE finden Sie unter NAT-Richtlinie für ausgehenden Traffic zur Konfiguration einer IP-Maskierung in Autopilot-Clustern verwenden.

Vorbereitung

Führen Sie die folgenden Schritte durch, 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.

ip-masq-agent-Status prüfen

In diesem Abschnitt wird Folgendes erläutert:

  • Ermitteln Sie, ob Ihr Cluster ein ip-masq-agent-DaemonSet hat.
  • Prüfen Sie die Ressource ConfigMap ip-masq-agent.

ip-masq-agent-DaemonSet prüfen

Um zu prüfen, ob Ihr Cluster das DaemonSet ip-masq-agent ausführt, verwenden Sie die Google Cloud CLI oder die Google Cloud Console.

gcloud

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

    gcloud container clusters get-credentials CLUSTER_NAME
    

    Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

  2. Suchen Sie im Namespace kube-system nach dem ip-masq-agent:

    kubectl get daemonsets/ip-masq-agent -n kube-system
    

    Wenn das ip-masq-agent-DaemonSet vorhanden ist, sieht die Ausgabe etwa so aus:

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    ip-masq-agent   3         3         3       3            3           <none>          13d
    

    Wenn das ip-masq-agent-DaemonSet nicht vorhanden ist, sieht die Ausgabe etwa so aus:

    Error from server (NotFound): daemonsets.apps "ip-masq-agent" not found
    

Console

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

    Zu Arbeitslasten

  2. Führen Sie für Filter folgende Schritte aus:

    1. Klicken Sie auf , um den Filter Is Ist ein Systemobjekt: Falsch zu löschen.
    2. Filtern Sie die folgenden Attribute:
      • Name: ip-masq-agent.
      • Cluster: Der Name Ihres Clusters.

    Wenn das ip-masq-agent-DaemonSet vorhanden ist, können Sie den DaemonSet-Eintrag in der Tabelle sehen. Wenn das ip-masq-agent-DaemonSet nicht vorhanden ist, werden keine Zeilen angezeigt.

Informationen zum Erstellen der ip-masq-agent-ConfigMap und zum Bereitstellen des ip-masq-agent-DaemonSets finden Sie unter ip-masq-agent konfigurieren und bereitstellen.

ip-masq-agent-ConfigMap prüfen

Um zu prüfen, ob Ihr Cluster die ConfigMap ip-masq-agent ausführt, verwenden Sie die Google Cloud CLI oder die Google Cloud Console.

gcloud

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

    gcloud container clusters get-credentials CLUSTER_NAME
    

    Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

  2. Beschreiben Sie die ip-masq-agent-ConfigMap im Namespace kube-system:

    kubectl describe configmaps/ip-masq-agent -n kube-system
    

    Wenn die ip-masq-agent-ConfigMap vorhanden ist, sieht die Ausgabe in etwa so aus:

    Name:         ip-masq-agent
    Namespace:    kube-system
    Labels:       <none>
    Annotations:  <none>
    
    Data
    ====
    config:
    ----
    nonMasqueradeCIDRs:
      - 198.15.5.92/24
      - 10.0.0.0/8
    masqLinkLocal: false
    resyncInterval: 60s
    
    BinaryData
    ====
    
    Events:  <none>
    

    Wenn die ip-masq-agent-ConfigMap nicht vorhanden ist, sieht die Ausgabe etwa so aus:

    Error from server (NotFound): configmaps "ip-masq-agent" not found
    

Console

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

    Zu „Konfiguration“

  2. Führen Sie für Filter folgende Schritte aus:

    1. Klicken Sie auf , um den Filter Is Ist ein Systemobjekt: Falsch zu löschen.
    2. Filtern Sie die folgenden Attribute:
      • Name: ip-masq-agent.
      • Cluster: Der Name Ihres Clusters.

    Wenn die ip-masq-agent-ConfigMap vorhanden ist, können Sie den ConfigMap-Eintrag in der Tabelle sehen. Wenn die ip-masq-agent-ConfigMap nicht vorhanden ist, werden keine Zeilen angezeigt.

Wenn der Cluster bereits die ip-masq-agent-ConfigMap hat, können Sie sie konfigurieren und bereitstellen.

ip-masq-agent konfigurieren und bereitstellen

In diesem Abschnitt erfahren Sie, wie Sie die ip-masq-agent-ConfigMap erstellen oder bearbeiten und wie Sie das ip-masq-agent-DaemonSet bereitstellen oder löschen. Um zu ermitteln, welche Aufgaben Sie ausführen müssen, müssen Sie zuerst ermitteln, ob Ihr Cluster bereits die ip-masq-agent-ConfigMap und das ip-masq-agent-DaemonSet hat.

ip-masq-agent-ConfigMap erstellen

In den folgenden Schritten wird gezeigt, wie die ip-masq-agent-ConfigMap erstellt wird. Wenn Ihr Cluster bereits die ip-masq-agent-ConfigMap hat, bearbeiten Sie stattdessen eine vorhandene ip-masq-agent-ConfigMap.

  1. Erstellen Sie eine Konfigurationsdatei mithilfe der folgenden Vorlage und speichern Sie sie lokal. Sie können für die lokale Kopie dieser Konfigurationsdatei einen beliebigen Namen verwenden.

    nonMasqueradeCIDRs:
      - CIDR_1
      - CIDR_2
    masqLinkLocal: false
    resyncInterval: SYNC_INTERVALUNIT_OF_TIME
    

    Dabei gilt:

    • CIDR_1 und CIDR_2: die IP-Adressbereiche im CIDR-Format. Wenn Pakete an diese Ziele gesendet werden, maskiert Ihr Cluster keine IP-Adressquellen und behält Quell-Pod-IP-Adressen bei. Wenn Sie mehr als zwei CIDRs benötigen, fügen Sie der Liste nonMasqueradeCIDRs weitere Einträge im selben Format hinzu. Das Attribut nonMasqueradeCIDRs sollte mindestens die Knoten- und Pod-IP-Adressbereiche Ihres Clusters enthalten.

    • SYNC_INTERVAL: die Zeitdauer, nach der jeder ip-masq-agent-Pod den Inhalt der ip-masq-agent-ConfigMap prüft und Änderungen in die lokale /etc/config/ip-masq-agent-Datei schreibt. Die Standardeinstellung ist 60.

    • UNIT_OF_TIME: die Zeiteinheit für das resyncInterval. Gültige Werte sind s (für Sekunden) und ms (für Millisekunden). Die Standardeinstellung ist s.

    Setzen Sie masqLinkLocal auf „false“ (Standardeinstellung), es sei denn, Sie müssen die Maskierung für Pakete aktivieren, die an Link-Local-IPv4-Adressen gesendet werden. Weitere Informationen finden Sie unter Maskierung auf Link-Local-Ziele.

  2. Erstellen Sie die ConfigMap-Ressource:

    kubectl create configmap ip-masq-agent \
       --namespace=kube-system \
       --from-file=config=LOCAL_CONFIG_FILE_PATH
    

    Ersetzen Sie LOCAL_CONFIG_FILE_PATH durch den Pfad zu der Konfigurationsdatei, die Sie im vorherigen Schritt erstellt haben.

  3. Beschreiben Sie die ip-masq-agent-ConfigMap im Namespace kube-system:

    kubectl describe configmaps/ip-masq-agent -n kube-system
    

    Die entsprechende Ausgabe sieht etwa so aus:

    Name:         ip-masq-agent
    Namespace:    kube-system
    Labels:       <none>
    Annotations:  <none>
    
    Data
    ====
    config:
    ----
    nonMasqueradeCIDRs:
      - 198.15.5.92/24
      - 10.0.0.0/8
    masqLinkLocal: false
    resyncInterval: 60s
    
    BinaryData
    ====
    Events:  <none>
    
    

    Diese Ausgabe enthält den Parameter config mit Ihren Konfigurationsänderungen. Sie können jetzt das ip-masq-agent-DeamonSet bereitstellen.

Vorhandene ip-masq-agent-ConfigMap bearbeiten

So ändern Sie den Inhalt einer vorhandenen ip-masq-agent-ConfigMap:

  1. Öffnen Sie die ConfigMap in einem Texteditor:

    kubectl edit configmap ip-masq-agent --namespace=kube-system
    
  2. Bearbeiten Sie den Inhalt der ConfigMap-Datei:

    apiVersion: v1
    data:
      config: |
        nonMasqueradeCIDRs:
          - CIDR_1
          - CIDR_2
        masqLinkLocal: false
        resyncInterval: SYNC_INTERVALUNIT_OF_TIME
    kind: ConfigMap
    metadata:
      name: ip-masq-agent
      namespace: kube-system
    

    Dabei gilt:

    • CIDR_1 und CIDR_2: die IP-Adressbereiche im CIDR-Format. Wenn Pakete an diese Ziele gesendet werden, maskiert Ihr Cluster keine IP-Adressquellen und behält Quell-Pod-IP-Adressen bei. Wenn Sie mehr als zwei CIDRs benötigen, fügen Sie der Liste nonMasqueradeCIDRs weitere Einträge im selben Format hinzu. Das Attribut nonMasqueradeCIDRs sollte mindestens die Knoten- und Pod-IP-Adressbereiche Ihres Clusters enthalten.

    • SYNC_INTERVAL: die Zeitdauer, nach der jeder ip-masq-agent-Pod den Inhalt der ip-masq-agent-ConfigMap prüft und Änderungen in die lokale /etc/config/ip-masq-agent-Datei schreibt. Die Standardeinstellung ist 60.

    • UNIT_OF_TIME: die Zeiteinheit für das resyncInterval. Gültige Werte sind s (für Sekunden) und ms (für Millisekunden). Die Standardeinstellung ist s.

    Setzen Sie masqLinkLocal auf „false“ (Standardeinstellung), es sei denn, Sie müssen die Maskierung für Pakete aktivieren, die an Link-Local-IPv4-Adressen gesendet werden. Weitere Informationen finden Sie unter Maskierung auf Link-Local-Ziele.

  3. Beschreiben Sie die ip-masq-agent-ConfigMap im Namespace kube-system:

    kubectl describe configmaps/ip-masq-agent -n kube-system
    

    Die entsprechende Ausgabe sieht etwa so aus:

    Name:         ip-masq-agent
    Namespace:    kube-system
    Labels:       <none>
    Annotations:  <none>
    
    Data
    ====
    config:
    ----
    nonMasqueradeCIDRs:
      - 198.15.5.92/24
      - 10.0.0.0/8
    masqLinkLocal: false
    resyncInterval: 60s
    
    BinaryData
    ====
    
    Events:  <none>
    

    Diese Ausgabe enthält den Parameter config, der dem Konfigurationswert aus der von Ihnen erstellten Datei entspricht.

ip-masq-agent-DaemonSet bereitstellen

Nachdem Sie die ip-masq-agent-ConfigMap erstellt oder bearbeitet haben, stellen Sie das ip-masq-agent-DaemonSet bereit.

  1. Speichern Sie das folgende Manifest als YAML-Datei:

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: ip-masq-agent
      namespace: kube-system
    spec:
      selector:
        matchLabels:
          k8s-app: ip-masq-agent
      template:
        metadata:
          labels:
            k8s-app: ip-masq-agent
        spec:
          hostNetwork: true
          containers:
          - name: ip-masq-agent
            image: gke.gcr.io/ip-masq-agent:v2.11.0-gke.23@sha256:f50757332ee45c0fb9f5856552a3ed16548c1de3c33c4e520a02d22e30af96ae
            args:
            # The masq-chain must be IP-MASQ
            - --masq-chain=IP-MASQ
            # To non-masquerade reserved IP ranges by default,
            # uncomment the following line.
            # - --nomasq-all-reserved-ranges
            # Must be set to false when using Dataplane V2.
            - --random-fully=false
            securityContext:
              privileged: false
              capabilities:
                drop: ["ALL"]
                add: ["NET_ADMIN", "NET_RAW"]
              allowPrivilegeEscalation: false
              seccompProfile:
                type: RuntimeDefault
            volumeMounts:
            - name: config-volume
              mountPath: /etc/config
          volumes:
          - name: config-volume
            configMap:
              name: ip-masq-agent
              optional: true
              items:
              - key: config
                path: ip-masq-agent
          tolerations:
          - effect: NoSchedule
            operator: Exists
          - effect: NoExecute
            operator: Exists
          - key: "CriticalAddonsOnly"
            operator: "Exists"

    Dieses Manifest erstellt ein Volume mit dem Namen config-volume, das wie durch das VolumeMount des Containers angegeben bereitgestellt wird.

    Beachten Sie die folgenden Bedingungen, wenn Sie dieses Manifest bearbeiten müssen:

    • Der Volume-Name kann beliebig sein, muss aber mit dem volumeMount-Namen des Containers übereinstimmen.

    • Der ConfigMap-Name muss mit dem Namen der configMap übereinstimmen, auf die im Volume config-volume im Pod verwiesen wird.

    • Der Name der Kette (--masq-chain) muss IP-MASQ lauten. Andernfalls überschreibt GKE die Standardregeln für die Maskierung nicht.

    • DaemonSet-Pods lesen aus der Datei ip-masq-agent. Der Inhalt der Datei ip-masq-agent ist der Wert des Schlüssels config in der ConfigMap.

    • Wenn Sie standardmäßig reservierte IP-Bereiche ohne Maskierung verwenden, entfernen Sie das Kommentarzeichen in der Zeile - --nomasq-all-reserved-ranges im Abschnitt arg.

  2. Stellen Sie das DaemonSet bereit:

    kubectl apply -f LOCAL_FILE_PATH
    

    Ersetzen Sie LOCAL_FILE_PATH durch den Pfad zu der Datei, die Sie im vorherigen Schritt erstellt haben.

Sie können das von Ihnen erstellte DaemonSet ip-masq-agent manuell aktualisieren. Weitere Informationen finden Sie unter DaemonSet aktualisieren.

ip-masq-agent löschen

In diesem Abschnitt erfahren Sie, wie Sie das ip-masq-agent-DaemonSet und die ip-masq-agent-ConfigMap löschen. Beim Löschen von ip-masq-agent werden die bestehenden Einstellungen für das IP-Masquerading auf den Knoten nicht rückgängig gemacht.

ip-masq-agent-DaemonSet löschen

Wenn Sie das ip-masq-agent-DaemonSet manuell erstellt haben, können Sie es mit dem folgenden Befehl löschen:

kubectl delete daemonsets ip-masq-agent -n kube-system

ip-masq-agent-ConfigMap löschen

Führen Sie den folgenden Befehl aus, um die ip-masq-agent-ConfigMap vollständig zu löschen:

kubectl delete configmap ip-masq-agent -n kube-system

Fehlerbehebung

Die folgenden Schritte enthalten Informationen zur Fehlerbehebung:

  • Bestätigen Sie den Status von ip-masq-agent. Wenn die ConfigMap nicht definiert ist, wird der Traffic zu allen Standardzielen nicht maskiert und behält die Pod-IP-Adresse bei. Der Traffic zu anderen Zielen behält die Knoten-IP-Adresse bei.
  • Prüfen Sie, ob die IP-MASQ-Kette in die NAT-IP-Tabellen korrekt eingefügt ist. Führen Sie dazu den Befehl sudo iptables -t nat -L IP-MASQ im betroffenen Knoten aus. Wenn die in der ConfigMap definierte nonMasqueradeCIDRs nicht in den NAT-IP-Tabellen angezeigt wird, prüfen Sie, ob die zum Erstellen der ConfigMap verwendete Konfigurationsdatei keine Tippfehler enthält.
  • Prüfen Sie, ob das Ziel, das der Pod erreichen möchte, in nonMasqueradeCIDRs in der ConfigMap enthalten ist. Wenn sich das Ziel nicht im nonMasqueradeCIDRs befindet, behält der Traffic die Knoten-IP-Adresse bei.
  • Prüfen Sie, ob das Ziel sowohl die Knoten- als auch die Pod-IP-Adressbereiche zulässt.
  • Wenn auf den Traffic vom Knoten oder Pod aus nicht zugegriffen werden kann, führen Sie einen Konnektivitätstest aus.

Nächste Schritte