IP-Masquerade-Agent

Auf dieser Seite wird erläutert, wie die IP-Maskierung in Google Kubernetes Engine (GKE) funktioniert. Außerdem werden Konfigurationsoptionen für verschiedene Szenarien angegeben.

Übersicht über die IP-Maskierung

IP-Maskierung ist eine Form von Quellnetzwerkadressübersetzung (SNAT), die n:1-IP-Adressübersetzungen durchführt. GKE kann die IP-Maskierung verwenden, um die Quell-IP-Adressen von Pods gesendeter Pakete zu ändern.

Eine allgemeine Übersicht über die IP-Maskierung in beliebigen Kubernetes-Implementierungen finden Sie im Nutzerhandbuch des IP-Masquerade-Agenten.

GKE-IP-Maskierung

Wenn IP-Maskierung für ein von einem Pod ausgegebenes Paket gilt, ändert GKE die IP-Quelladresse des Pakets von der Pod-IP-Adresse in die IP-Adresse des zugrunde liegenden Knotens. Die Maskierung der Quell-IP-Adresse eines Pakets ist hilfreich, wenn ein Empfänger so konfiguriert ist, dass er nur Pakete von den Knoten-IP-Adressen des Clusters empfängt.

Auf Linux-Knoten konfiguriert GKE iptables-Regeln. GKE verwendet das DaemonSet ip-masq-agent, um die entsprechende Datenebene zu konfigurieren.

Die IP-Maskierung wird in Windows Server-Knotenpools nicht unterstützt.

IP-Maskierung für Standardcluster

In Standard-Clustern wird das Verhalten der IP-Maskierung des Clusters von drei Faktoren gesteuert:

In der folgenden Tabelle sind die IP-Maskierungskonfigurationen für GKE-Standardcluster zusammengefasst:

Clusterkonfiguration Daraus resultierendes SNAT-Verhalten

Das ip-masq-agent-DaemonSet ist im Cluster vorhanden und eine benutzerdefinierte nonMasqueradeCIDRs-Liste ist in der ip-masq-agent-ConfigMap vorhanden.

GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an Ziele in der nonMasqueradeCIDRs-Liste gesendet werden.

GKE ändert die Quell-Pod-IP-Adressen in Quellknoten-IP-Adressen für Pakete, die an Ziele gesendet werden, die nicht in der nonMasqueradeCIDRs-Liste angegeben sind.

Das ip-masq-agent-DaemonSet ist im Cluster vorhanden, aber eine benutzerdefinierte nonMasqueradeCIDRs-Liste existiert nicht in der ip-masq-agent-ConfigMap oder die ip-masq-agent-ConfigMap ist überhaupt nicht vorhanden.

GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an eine Reihe von Standardzielen ohne Maskierung gesendet werden.

GKE ändert Quell-Pod-IP-Adressen in Quellknoten-IP-Adressen für Pakete, die an Ziele außerhalb der Standardziele ohne Maskierung gesendet werden.

Das ip-masq-agent-DaemonSet ist nicht im Cluster vorhanden, und Sie haben den Cluster ohne das Flag --disable-default-snat erstellt.

GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an eine Reihe von Standardzielen ohne Maskierung gesendet werden.

GKE ändert Quell-Pod-IP-Adressen in Quellknoten-IP-Adressen für Pakete, die an Ziele außerhalb der Standardziele ohne Maskierung gesendet werden.

Das ip-masq-agent-DaemonSet ist nicht im Cluster vorhanden, und Sie haben den Cluster mit dem Flag --disable-default-snat erstellt.

GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an alle Ziele gesendet werden.

Unter Pod-IPv4-Adressquellen an Internetziele beibehalten finden Sie wichtige Überlegungen zum Routing, wenn Pod-IPv4-Quelladressen beibehalten werden und Pakete an das Internet weitergeleitet werden müssen.

IP-Maskierung für Autopilot-Cluster

In Autopilot-Clustern stellt GKE immer ein ip-masq-agent-DaemonSet bereit. Mit Ausnahme von Paketen, die von Pods an die Knoten-, Pod- oder Servicebereiche des Clusters gesendet werden, können Sie das Verhalten der IP-Maskierung mit einer EgressNATPolicy steuern. Damit Sie eine EgressNATPolicy verwenden können, muss der Autopilot-Cluster die beiden folgenden Anforderungen erfüllen:

  • Der Cluster muss die GKE-Version 1.23.4-gke.1600 oder höher oder die Version 1.22.7-gke.1500 oder höher verwenden.
  • Der Cluster muss mit aktiviertem GKE Dataplane V2 erstellt worden sein.

In der folgenden Tabelle sind die IP-Maskierungskonfigurationen für Autopilot GKE-Cluster zusammengefasst:

Autopilot-Clusterkonfiguration Daraus resultierendes SNAT-Verhalten

Der Cluster enthält eine benutzerdefinierte EgressNATPolicy, deren spec.action NoSNAT ist, die Ziele ohne Maskierung enthält, die in spec.destinations[] angegeben sind.

GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an Ziele in spec.destinations[] der EgressNATPolicy gesendet werden. GKE erreicht dies durch die Übersetzung von spec.destinations[] in eine nonMasqueradeCIDRs-Liste in einer ip-masq-agent-configMap.

GKE ändert die Quell-Pod-IP-Adressen in Quellknoten-IP-Adressen für Pakete, die an Ziele gesendet werden, die nicht in spec.destinations[] der EgressNATPolicy angegeben sind.

Der Cluster enthält keine benutzerdefinierte EgressNATPolicy.

Sowohl die Standard-EgressNATPolicy als auch die von GKE verwaltete Richtlinie gelten, was zu folgendem Verhalten führt:

  • GKE behält die Quell-Pod-IP-Adressen für Pakete bei, die an eine Reihe von Standardzielen ohne Maskierung gesendet werden.
  • GKE ändert Quell-Pod-IP-Adressen in Quellknoten-IP-Adressen für Pakete, die an Ziele außerhalb der Standardziele ohne Maskierung gesendet werden.

Konfigurationsbeispiele

Maximieren Sie die folgenden Abschnitte, um Beispiele für die IP-Maskierung und -Konfiguration basierend auf dem Clustertyp anzuzeigen.

Erweiterte Konfigurationsreferenz

Wenn der ip-masq-agent automatisch bereitgestellt wird

In Autopilot-Modus-Clustern stellt GKE immer ein ip-masq-agent-DaemonSet bereit.

In Standardclustern stellt GKE ein ip-masq-agent-DaemonSet bereit, wenn das Flag --disable-default-snat nicht festgelegt ist und der Cluster eine der folgenden Konfigurationskombinationen verwendet:

  • Der Cluster verwendet GKE Dataplane V2 nicht und die Durchsetzung von Netzwerkrichtlinien ist aktiviert.

  • Der Cluster verwendet einen Pod-IP-Adressbereich, der nicht in 10.0.0.0/8 passt.

Damit das DaemonSet ip-masq-agent wirksam ist, müssen Sie auch die Liste nonMasqueradeCIDRs in der ConfigMap ip-masq-agent angeben. Weitere Informationen finden Sie unter IP-Masquerade-Agent konfigurieren.

Wenn ein ip-masq-agent-DaemonSet in einem Cluster vorhanden ist, aktualisiert GKE einen Bereitstellungs-Pod auf jedem Knoten des Clusters und gleicht ihn ab.

Standardziele ohne Maskierung

Das Standardziel ohne Maskierung ist:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

Die Standardziele ohne Maskierung gelten für Cluster mit den folgenden Konfigurationen:

Die Standardziele ohne Maskierung gelten nicht für Cluster mit den folgenden Konfigurationen:

Auswirkungen des Flags --disable-default-snat

Das Flag --disable-default-snat ändert das standardmäßige GKE-SNAT-Verhalten, sodass die Quell-Pod-IP-Adressen für Pakete beibehalten werden, die an alle Ziele gesendet werden. GKE implementiert das Standard-SNAT-Verhalten, indem kein ip-masq-agent-DaemonSet im Cluster bereitgestellt wird.

Das Flag --disable-default-snat hat keine Auswirkungen, wenn ein Cluster ein ip-masq-agent-DaemonSet enthält:

  • Da Autopilot-Cluster immer ein ip-masq-agent-DaemonSet enthalten, hat das Flag --disable-default-snat keine Auswirkungen auf Autopilot-Cluster.

Sie können das Flag --disable-default-snat festlegen, indem Sie einen Cluster aktualisieren, nachdem er erstellt wurde. Wenn für den Cluster kein ip-masq-agent-DaemonSet bereitgestellt ist, wird die Deaktivierung des Standard-SNAT wirksam, nachdem der Cluster alle Knoten ersetzt hat – in manchen Fällen erst Stunden später. Dies liegt daran, dass GKE Ihre konfigurierten Wartungsfenster berücksichtigt, wenn Knoten im Cluster ersetzt werden. Wenn Sie kein Wartungsfenster konfiguriert haben, müssen Sie die Knoten im Cluster manuell rotieren, bevor das Flag --disable-default-snat Auswirkungen hat.

Link-Local-Maskierung

Der Bereich 169.254.0.0/16 wird für Link-Local-IP-Adressen verwendet. Die Link-Local-Maskierung bezieht sich auf das Ändern einer Quell-Pod-IP-Adresse in eine Quellknoten-IP-Adresse für Pakete, die an die 169.254.0.0/16-Ziele gesendet werden.

Autopilot-Cluster behalten immer Quell-Pod-IP-Adressen für Pakete bei, die an 169.254.0.0/16-Ziele gesendet werden.

Standardmäßig behalten Standardcluster auch die Quell-Pod-IP-Adressen für Pakete bei, die an 169.254.0.0/16-Ziele gesendet werden.

Sie können die Link-Local-IP-Maskierung in einem Standard-Cluster aktivieren. Gehen Sie dazu so vor:

Diagnosecontainer und Pods mit hostNetwork: true

Solange Sie keine benutzerdefinierte Quell-IP-Adresse für Pakete angeben, senden Pods, die mit hostNetwork: true und Diagnosecontainer ausgeführt werden, Pakete mit Quellen, die mit der IP-Adresse des Knotens übereinstimmen. Bei Pods, die mit hostNetwork: true ausgeführt werden, weist GKE dem Pod die IP-Adresse des Knotens zu. GKE verwaltet keine IP-Adressen für Diagnosecontainer, einschließlich Containern zum Beheben von Knotenproblemen mit der Toolbox.

Autopilot-Cluster unterstützen die Ausführung von Pods mit spec.hostNetwork: true nicht. Da auf die Knoten eines Autopilot-Clusters nicht über SSH zugegriffen werden kann, können Sie keine Diagnosecontainer darauf ausführen.

Pod-IPv4-Adressquellen an Internetziele beibehalten

Wenn die IP-Masquerade-Konfiguration Ihres Clusters eine der folgenden ist, behält GKE Pod-IP-Adressquellen für Pakete bei, die an alle Ziele gesendet werden, einschließlich Internetziele:

  • In Standardclustern mit einem ip-masq-agent-DaemonSet, wenn Sie nonMasqueradeCIDRs in der ip-masq-agent-ConfigMap auf 0.0.0.0 festgelegt haben.
  • In Standardclustern ohne das DaemonSet ip-masq-agent, wenn Sie das Flag --disable-default-snat festgelegt haben.

Sowohl in öffentlichen als auch in privaten Clustern sind Pod-IPv4-Quellen interne IPv4-Adressen. Das bedeutet, dass sie im Internet nicht routingfähig sind. Wenn Sie Quell-Pod-IPv4-Adressen für an das Internet gesendete Pakete beibehalten, müssen Sie daher eine Technik wie eine der folgenden verwenden, um Pakete weiterzuleiten, nachdem sie die Knoten des Clusters verlassen haben:

  • Achten Sie darauf, dass Ihr VPC-Netzwerk eine Standardroute mit dem Standard-Internetgateway als nächsten Hop hat und konfigurieren Sie ein Cloud NAT-Gateway, um öffentliche NAT-Dienste für mindestens die sekundären Subnetz-IPv4-Adressbereiche bereitzustellen, die von Pods in Ihrem Cluster verwendet werden. Weitere Informationen finden Sie unter GKE-Interaktion in der Cloud NAT-Übersicht.
  • Konfigurieren Sie Ihr VPC-Netzwerk für die Verwendung einer benutzerdefinierten Standardroute, deren nächster Hop eine VM-Instanz oder ein interner Passthrough-Netzwerk-Load-Balancer ist, wobei die VM oder die Back-Ends des Load-Balancers so konfiguriert wurden, dass Pakete im Namen der Pods an das Internet weitergeleitet werden.

Standard-SNAT-Verhalten wiederherstellen

Wenn Sie das Standard-SNAT-Verhalten wiederherstellen möchten, wenn sich ein ip-masq-agent-DaemonSet in einem Cluster befindet, löschen Sie die zugehörige ip-masq-agent-ConfigMap. Das ip-masq-agent-DaemonSet stellt das standardmäßige IP-Masquerading-Verhalten auf den verwalteten Knoten wieder her.

Wenn Sie das Standard-SNAT-Verhalten wiederherstellen möchten, wenn kein ip-masq-agent-DaemonSet in einem Cluster vorhanden ist, müssen Sie den Knotenpool aktualisieren. Achten Sie darauf, dass --disable-default-snat nicht für den Cluster festgelegt ist.

Wirkungen der NAT-Richtlinie für ausgehenden Traffic in Autopilot-Clustern

Mit der GKE-NAT-Richtlinie für ausgehenden Traffic können Sie die IP-Maskierung für Autopilot-Cluster konfigurieren. Sie können die benutzerdefinierte Ressourcendefinition (CRD) der GKE-NAT-Richtlinie für ausgehenden Traffic verwenden, um die Quell-IP-Adressen der von Pods gesendeten Pakete zu ändern.

Aus Sicherheits- oder IP-Adressüberlastungsgründen können Sie IP-Adressen von Pod-zu-Knoten-IP-Adressbereichen für ausgehenden Traffic zu lokalen Netzwerken maskieren. Beispiel: Sie können einen Bereich außerhalb von RFC 1918 für Autopilot-Cluster und einen RFC-1918-Bereich für die Knoten verwenden. Wenn Pods jedoch mit lokalen Netzwerken kommunizieren müssen, die auch einen Bereich außerhalb von RFC 1918 verwenden, können sich die IP-Adressen überschneiden. Um Trafficverluste zu vermeiden, können Sie eine NAT-Richtlinie für ausgehenden Traffic konfigurieren, um lokalen Netzwerken die Pod-Bereiche außerhalb von RFC-1918 nicht anzubieten. Die NAT-Richtlinie für ausgehenden Traffic maskiert den Bereich außerhalb des RFC-1918-Bereichs der Pods, damit der RFC-1918-Bereich des Knotens verwendet wird. Achten Sie darauf, dass sich kein Knotenbereich mit einem lokalen Bereich überschneidet, da dies eine Trafficschleife verursachen kann.

GKE erzwingt das IP-Maskierungsverhalten für Autopilot-Cluster so:

  1. GKE stellt den NAT-Controller für ausgehenden Traffic und das ip-masq-agent.
  2. Sie erstellen die NAT-Richtlinie für ausgehenden Traffic.
  3. Der GKE-Controller übersetzt die Richtlinie in die ip-masq-agent-ConfigMap.
  4. Das DaemonSet ip-masq-agent liest die ConfigMap und GKE erzwingt dann das IP-Maskierungsverhalten.

Automatisch generierte Richtlinien

GKE unterstützt die folgenden zwei automatisch generierten NAT-Richtlinien für ausgehenden Traffic:

  • Standard: Diese Richtlinien können bearbeitet werden.
  • Von GKE verwaltet: Diese Richtlinien sind fixiert und können nicht bearbeitet werden.

Standardrichtlinie

GKE definiert eine Reihe von Standard-IP-Adressbereichen. Wenn Pakete an diese Ziele gesendet werden, maskiert Ihr Cluster keine IP-Adressquellen und behält Quell-Pod-IP-Adressen bei. Informationen zum Ändern dieser Standard-IP-Adressbereiche finden Sie unter NAT-Richtlinie für ausgehenden Traffic bearbeiten und bereitstellen.

Das folgende Manifest beschreibt eine Standard-NAT-Richtlinie für ausgehenden Traffic:

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  networking.gke.io/v1
    Kind:         EgressNATPolicy
    Metadata:
      Creation Timestamp:  2022-03-16T21:05:45Z
      Generation:          2
      Managed Fields:
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            .:
            f:action:
          f:status:
        Manager:      egress-nat-controller
        Operation:    Update
        Time:         2022-03-16T21:05:45Z
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            f:destinations:
        Manager:         kubectl
        Operation:       Update
        Time:            2022-03-17T01:58:13Z
      Resource Version:  189346
      UID:               06acbb5a-23ba-4c2a-bb34-9b6ed8c4a87f
    Spec:
      Action:  NoSNAT
      Destinations:
        Cidr:  10.0.0.0/8
        Cidr:  172.16.0.0/12
        Cidr:  192.168.0.0/16
        Cidr:  240.0.0.0/4
        Cidr:  192.0.2.0/24
        Cidr:  198.51.100.0/24
        Cidr:  203.0.113.0/24
        Cidr:  100.64.0.0/10
        Cidr:  198.18.0.0/15
        Cidr:  192.0.0.0/24
        Cidr:  192.88.99.0/24
    Status:
    Events:  <none>

Die CIDR-Bereiche sind mit den Standardzielbereichen ohne Maskierung identisch.

Von der GKE-Richtlinie verwaltet

Die NAT-Richtlinie für ausgehenden Traffic reserviert einen statischen Bereich von IP-Adressen, der für den Betrieb des Clusters erforderlich ist. Dieser statische Bereich enthält die Pod-, Dienst- und Knoten-IP-Adressbereiche des Clusters und kann sich mit der Standardrichtlinie überschneiden.

Sie können diese Richtlinie durch einen dynamischen 8-Byte-Hash (gke-{CLUSTER_SHORT_HASH}) identifizieren, der von GKE zugewiesen wird. Sie können diese Richtlinie nicht bearbeiten.

Das folgende Manifest definiert eine von GKE verwaltete Richtlinie namens gke-bbfa6c0e-1:

    Name:         gke-bbfa6c0e-1
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  networking.gke.io/v1
    Kind:         EgressNATPolicy
    Metadata:
      Creation Timestamp:  2022-03-16T21:05:46Z
      Generation:          1
      Managed Fields:
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            .:
            f:action:
            f:destinations:
          f:status:
        Manager:         egress-nat-controller
        Operation:       Update
        Time:            2022-03-16T21:05:46Z
      Resource Version:  11699
      UID:               0201b5de-a6f6-4926-822b-31ed7cdee2c6
    Spec:
      Action:  NoSNAT
      Destinations:
        Cidr:  10.119.128.0/17
        Cidr:  10.120.0.0/22
        Cidr:  10.128.0.0/20
    Status:
    Events:  <none>

Nächste Schritte