Warum GKE-Pods über VPN keine lokalen Hosts erreichen

Ping funktioniert vom Node und schlägt vom Pod aus fehl, und lokal kommt nichts an. Der Tunnel und die Route sind in Ordnung; die Quelladresse auf dem Draht ist es nicht. Was sich zwischen diesen beiden Fällen unterscheidet, ist, was das Paket zu sein behauptet, wenn es den Cluster verlässt, und GKE hat dazu eine Meinung. Der Mechanismus ist eine Masquerade-Ausnahmeliste, und sie zu lesen kostet einen Befehl.

Lesen Sie die wirksame Liste, bevor Sie etwas ändern

GKE liefert einen Agenten mit, der pro Zielbereich entscheidet, ob Pod-Verkehr beim Verlassen auf die Node-Adresse umgeschrieben wird. Seine mitgelieferte Konfiguration nennt die drei RFC1918-Blöcke, 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16, als ausgenommene Ziele. Alles, was Sie von einem Pod an einen lokalen 10.x-Host senden, verlässt den Node daher mit der eigenen Adresse des Pods noch daran. Der Verkehr des Nodes selbst wird nicht umgeschrieben, und genau deshalb funktioniert sein Ping.

Lesen Sie die beabsichtigte Konfiguration und die installierten Regeln, denn sie können sich widersprechen. kubectl -n kube-system get configmap ip-masq-agent -o yaml zeigt, was dem Agenten gesagt wurde, und kubectl -n kube-system get pods -l k8s-app=ip-masq-agent zeigt, ob etwas läuft, das es anwendet. Auf einem Node zeigt iptables-save | grep -i masq die Regeln, die tatsächlich im Kernel existieren. Wenn die ConfigMap das eine sagt und die Regeln das andere, ist der Agent der Verdächtige und nicht das Netzwerk.

Bestätigen Sie die Quelladresse mit einem Mitschnitt

Machen Sie einen Mitschnitt, bevor Sie eine Liste ändern. Ein Filter auf das eine Ziel hält die Ausgabe lesbar: tcpdump -ni any host 10.20.30.40.

Vergleichen Sie das mit dem, was die Gegenseite meldet. Ein Mitschnitt vor Ort, der die Pod-Adresse und keine Antwort zeigt, schließt den Kreis: Die Ausnahmeliste erklärt die Asymmetrie ohne jeden Tunnel-Fehler. Zwei Beobachtungen einer Quelladresse genügen, um aufzuhören, über das CNI zu spekulieren.

Verengen Sie die Ausnahme auf das Pod-CIDR

Die unterstützte Reparatur verengt die Ausnahme, statt sie zu entfernen: Lassen Sie das Pod-CIDR ausgenommen und den Rest des 10.x-Raums fallen. Diese Liste liegt in der ConfigMap des Agenten unter nonMasqueradeCIDRs, und sie zu ändern ist eine Bearbeitung, gefolgt von einem Rollout. Ersetzen Sie den breiten Eintrag durch den tatsächlichen Pod-Bereich des Clusters, behalten Sie die anderen privaten Blöcke, wenn clusterinterner Verkehr sie noch braucht, und lassen Sie resyncInterval in Ruhe, solange Sie keinen Grund haben. Wenden Sie es an, bestätigen Sie, dass die Agent-Pods neu gestartet wurden, und bestätigen Sie, dass sich die Kernel-Regeln geändert haben.

Dies ist eine clusterweite Änderung mit echter Wirkung. Nachdem sie greift, kommt Verkehr, der zuvor seine Pod-Quelle behielt, nun auf den Node umgeschrieben an, sodass alles, was auf diese Pod-Adressen abgestellt war, einen anderen Absender sieht. Die Opfer sind Protokolle, Positivlisten und lokale Firewall-Regeln, die Pod-Adressen nennen, und sie scheitern still. Kündigen Sie die Änderung als Verhaltensänderung an, nicht als Fehlerbehebung.

Prüfen Sie in einem Cluster mit mehreren Node-Pools, ob der Agent auf den Nodes eingeplant ist, auf denen die betroffenen Pods tatsächlich laufen. Ein Pool ohne das DaemonSet behält seine alten Regeln, und nichts in der ConfigMap wird das zeigen.

Die Alternative und ihre Kosten

Die andere Option lässt Pod-Adressen unangetastet und bringt dem Pfad bei, sie zu kennen. Das Pod-CIDR kommt in die Verkehrsselektoren von Cloud VPN, und die lokale Seite braucht eine Rückroute dafür, damit Antworten wissen, wohin sie sollen. Das bewahrt die Pod-Identität, die manche Sicherheitsmodelle wollen, und es erweitert sowohl den Routing- als auch den Firewall-Umfang, den die Gegenseite akzeptieren muss.

Der Handel ist Lesbarkeit gegen Umfang. Übersetzung lässt die lokale Seite eine Adresse pro Node sehen, was leicht auf eine Positivliste kommt und verbirgt, welcher Pod was gesendet hat. Keine Übersetzung hält die Pod-Adresse durchgehend, was für die Zuordnung besser und für jedes Gerät im Pfad schlechter ist, das einen neuen Bereich lernen muss. Keine der Optionen ist ein Docker- oder CNI-Defekt; beide sind Routing-Entscheidungen mit einer Betriebsrechnung. Wählen Sie die, deren Rechnung Ihr Team bezahlen kann, und schreiben Sie auf, warum.

Prüfen und zurückrollen

Führen Sie denselben Mitschnitt erneut aus. Ein Mitschnitt auf Node-Ebene, der nach Ihrer Bearbeitung noch die Pod-Adresse ausgibt, bedeutet, dass sich die Regeln nie geändert haben, was auch immer die ConfigMap sagt. Der Draht ist die Tatsache; alles andere ist Schlussfolgerung.

Prüfen Sie dann die Gegenrichtung, denn die Hälfte dieser Änderungen wird nur ausgehend verifiziert. Bestätigen Sie, dass die Antwort den Node oder Pod erreicht, der die Anfrage gesendet hat, und bestätigen Sie, dass die Anwendung fertig wurde, statt nur ein SYN zu empfangen. Ein Mitschnitt, der eine Anfrage ohne Antwort zeigt, ist ein Routing-Problem auf der Gegenseite, kein Masquerade-Problem auf dieser.

Zurückrollen heißt: die vorherige ConfigMap, auf dieselbe Weise angewendet, mit derselben Bestätigung, dass der Agent neu gestartet ist und sich die Regeln geändert haben. Halten Sie die Quelladresse vorher und nachher für eine bekannte Anfrage im Änderungsdatensatz fest, denn genau diese eine Zeile beweist, dass die Änderung getan hat, was Sie gesagt haben. Der GKE-Leitfaden zum IP-Masquerade-Agenten dokumentiert die Standardwerte und die ConfigMap-Felder. Wenn die Quelladresse nach dem Rollout unverändert ist, läuft der Agent nicht auf diesem Node, und keine YAML-Bearbeitung wird das beheben.