Wêrom GKE-pods gjin lokale hosts berikke oer VPN

Ping wurket fan 'e node en mislearret fan 'e pod, en lokaal komt neat oan. De tunnel en de rûte binne yn oarder; it boarneadres op 'e tried is dat net. Wat tusken dy beide gefallen ferskilt, is wat it pakket seit te wêzen as it it kluster ferlit, en GKE hat dêr in miening oer. It meganisme is in masquerade-útsûnderingslist, en it lêzen dêrfan kostet ien opdracht.

Lês de jildende list foardat jo wat feroarje

GKE leveret in agent dy't per bestimmingsberik beslút oft pod-ferkear by it útgien nei it node-adres weromskreaun wurdt. Syn meilevere konfiguraasje neamt de trije RFC1918-blokken, 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16, as útsûndere bestimmingen. Alles wat jo fan in pod nei in lokale 10.x-host stjoere, ferlit dêrom de node mei it eigen adres fan 'e pod noch deroan. It ferkear fan 'e node sels wurdt net weromskreaun, en dêrom wurket syn ping.

Lês de bedoelde konfiguraasje en de ynstallearre regels, want se kinne faninoar ferskille. kubectl -n kube-system get configmap ip-masq-agent -o yaml lit sjen wat tsjin de agent sein is, en kubectl -n kube-system get pods -l k8s-app=ip-masq-agent lit sjen oft der wat rint om it ta te passen. Op in node lit iptables-save | grep -i masq de regels sjen dy't wier yn 'e kearn besteane. As de ConfigMap it iene seit en de regels it oare, is de agent de fertochte en net it netwurk.

Befêstigje it boarneadres mei in opname

Meitsje in opname foardat jo in list feroarje. In filter op 'e iene bestimming hâldt de útfier lêsber: tcpdump -ni any host 10.20.30.40.

Fergelykje dat mei wat de oare kant rapportearret. In opname lokaal dy't it pod-adres sjen lit en gjin antwurd, slút de sirkel: de útsûnderingslist ferklearret de asymmetry sûnder hokker tunneldefekt dan ek. Twa waarnimmings fan ien boarneadres binne genôch om op te hâlden mei gissen oer it CNI.

Beheine de útsûndering ta it pod-CIDR

De stipe reparaasje beheint de útsûndering ynstee fan him te ferwiderjen: hâld it pod-CIDR útsûndere en lit de rest fan 'e 10.x-romte falle. Dy list wennet yn 'e ConfigMap fan 'e agent ûnder nonMasqueradeCIDRs, en it feroarjen dêrfan is in bewurking folge troch in útrol. Ferfang de brede yngong troch it wiere pod-berik fan it kluster, hâld de oare partikuliere blokken as ferkear binnen it kluster se noch nedich hat, en lit resyncInterval gewurde, útsein as jo in reden hawwe. Pas it ta, befêstigje dat de pods fan 'e agent opnij start binne, en befêstigje dat de kearnregels feroare binne.

Dit is in feroaring foar it hiele kluster mei in echte ynfloedsradius. Nei't it lânnet, komt ferkear dat earder syn pod-boarne hold, no weromskreaun by de node oan, sadat alles wat op dy pod-adressen sleutele, in oare stjoerder sjocht. De slachtoffers binne logs, tasteanlisten en lokale firewallregels dy't pod-adressen neame, en se mislearje stil. Kundigje de feroaring oan as in gedrachsferoaring, net as in repaaraasje.

Op in kluster mei ferskate node-pools, kontrolearje oft de agent pland is op 'e nodes dêr't de troffen pods wier rinne. In pool sûnder de DaemonSet hâldt syn âlde regels, en neat yn 'e ConfigMap sil dat sjen litte.

It alternatyf en syn kosten

De oare opsje hâldt pod-adressen ûnoantaast en leart it paad deroer. It pod-CIDR giet yn 'e ferkearsselekteurs fan Cloud VPN, en de lokale kant hat in weromrûte dêrfoar nedich sadat antwurden witte wêr't se hinne moatte. Dat behâldt de pod-identiteit, dy't guon feiligensmodellen wolle, en it ferbreedet sawol it routing- as it firewall-berik dat de oare kant akseptearje moat.

De ruil is lêsberens tsjin berik. Fertaaljen lit de lokale kant ien adres per node sjen, wat maklik is om op in tasteanlist te setten en ferberget hokker pod wat stjoerd hat. Gjin fertaling hâldt it pod-adres fan ein oant ein, wat better is foar taskriuwing en slimmer foar elk apparaat yn it paad dat in nij berik leare moat. Gjin fan beide opsjes is in Docker- of CNI-defekt; beide binne routingbesluten mei in operasjonele rekken. Kies dy't syn rekken jo team betelje kin, en skriuw op wêrom.

Ferifiearje en rol werom

Rin deselde opname wer. In opname op nodenivo dy't nei jo bewurking noch it pod-adres printsjet, betsjut dat de regels nea feroare binne, wat de ConfigMap ek seit. De tried is it feit; al it oare is konklúzje.

Kontrolearje dan de tsjinoerstelde rjochting, want de helte fan dizze feroarings wurdt allinnich útgeand ferifiearre. Befêstigje dat it antwurd de node of pod berikt dy't it fersyk stjoerd hat, en befêstigje dat de applikaasje klear wie ynstee fan allinnich in SYN te ûntfangen. In opname dy't in fersyk sûnder antwurd sjen lit, is in routingprobleem oan 'e oare kant, net in masquerade-probleem oan dizze kant.

Weromroljen is de foarige ConfigMap, op deselde manier tapast, mei deselde befêstiging dat de agent opnij start is en de regels feroare binne. Hâld it boarneadres foar en nei foar ien bekend fersyk yn it feroaringsrekord, want krekt dy iene rigel bewiist dat de feroaring die wat jo seine. De GKE-gids foar de IP-masquerade-agent dokumintearret de standertwearden en de ConfigMap-fjilden. As it boarneadres nei de útrol ûnferoare is, rint de agent net op dy node en gjin inkel YAML-bewurking sil dat oplosse.