Zergatik ezin duten GKE pod-ek VPN bidez tokiko zerbitzarietara iritsi

Ping-ak nodotik funtzionatzen du eta pod-etik huts egiten du, eta ezer ez da tokiko sarera iristen. Tunela eta bidea ondo daude; kableko jatorrizko helbidea ez. Bi kasu horien arteko aldea paketeak klusterretik irtetean zer dela dioen da, eta GKEk iritzia du horri buruz. Mekanismoa masquerade salbuespenen zerrenda da, eta hura irakurtzeko komando bat besterik ez da behar.

Irakurri indarrean dagoen zerrenda ezer aldatu aurretik

GKEk agente bat dakar, helmuga-tarte bakoitzeko erabakitzen duena pod-en trafikoa irteeran nodoaren helbidera berridatziko den. Bere konfigurazio lehenetsiak RFC1918 blokeak aipatzen ditu, 10.0.0.0/8, 172.16.0.0/12 eta 192.168.0.0/16, salbuetsitako helmuga gisa. Beraz, pod batetik tokiko 10.x ostalari batera bidaltzen duzun guztia nodotik irteten da pod-aren beraren helbidea oraindik itsatsita. Nodoaren beraren trafikoa ez da berridazten, eta horrexegatik funtzionatzen du haren ping-ak.

Irakurri nahi den konfigurazioa eta instalatutako arauak, bat etorri ez daitezkeelako. kubectl -n kube-system get configmap ip-masq-agent -o yaml-k agentearekin zer esan zen erakusten du, eta kubectl -n kube-system get pods -l k8s-app=ip-masq-agent-k hori aplikatzeko zerbait exekutatzen ari den. Nodo batean, iptables-save | grep -i masq-k nukleoan benetan dauden arauak erakusten ditu. ConfigMap-ak gauza bat esaten duenean eta arauek beste bat, agentea da susmagarria, ez sarea.

Egiaztatu jatorrizko helbidea harrapaketa batekin

Egin harrapaketa bat zerrenda bat aldatu aurretik. Helmuga bakarreko iragazkiak irteera irakurgarri mantentzen du: tcpdump -ni any host 10.20.30.40.

Konparatu hori beste aldeak jakinarazten duenarekin. Tokian egindako harrapaketa batek pod-aren helbidea eta erantzunik eza erakusten baditu, zirkulua ixten da: salbuespen-zerrendak asimetria azaltzen du tunelaren hutsegiterik gabe. Jatorrizko helbide beraren bi behaketa nahikoa dira CNIari buruz espekulatzeari uzteko.

Murriztu salbuespena pod-en CIDR-ra

Onartutako konponketak salbuespena murrizten du, ezabatu ordez: utzi pod-en CIDR salbuetsita eta utzi 10.x espazioaren gainerakoa. Zerrenda hori agentearen ConfigMap-ean dago nonMasqueradeCIDRs gakoaren pean, eta hura aldatzea edizio bat da, ondoren hedapen bat. Ordeztu sarrera zabala klusterraren benetako pod-tartearekin, mantendu beste bloke pribatu batzuk kluster barneko trafikoak oraindik behar baditu, eta utzi resyncInterval bakean arrazoiren bat ez baduzu. Aplikatu, egiaztatu agentearen pod-ak berrabiarazi direla eta egiaztatu nukleoko arauak aldatu direla.

Hau kluster osoan zeharreko aldaketa da, benetako eragin-erradioarekin. Indarrean sartzen denean, lehen pod-jatorria mantentzen zuen trafikoa nodora berridatzita iristen da orain, beraz pod helbide horietan oinarritzen zen edozeinek beste bidaltzaile bat ikusten du. Biktimak pod helbideak izendatzen dituzten erregistroak, baimen-zerrendak eta tokiko suhesi-arauak dira, eta isil-isilik huts egiten dute. Iragarri aldaketa portaera-aldaketa gisa, konponketa gisa baino.

Nodo-pool batzuk dituen kluster batean, egiaztatu agentea eragindako pod-ak benetan exekutatzen diren nodoetan programatuta dagoela. DaemonSet-ik gabeko pool batek bere arau zaharrak mantentzen ditu, eta ConfigMap-ean ezerk ez du hori erakutsiko.

Alternatiba eta haren kostua

Beste aukerak pod helbideak ukitu gabe mantentzen ditu eta bidea haiei buruz irakasten du. Pod-en CIDR-a Cloud VPNren trafiko-hautatzaileetara doa, eta tokiko aldeak itzulera-bide bat behar du hura lortzeko, erantzunek nora jo jakin dezaten. Horrek pod-aren identitatea gordetzen du, segurtasun-eredu batzuek nahi dutena, eta beste aldeak onartu behar duen bideratze- eta suhesi-eremua zabaltzen ditu.

Trukea irakurgarritasuna eremuaren aurka da. Itzulketak tokiko aldeak nodo bakoitzeko helbide bat ikustea eragiten du, baimen-zerrenda batean jartzeko erraza eta zein pod-ek zer bidali zuen ezkutatzen duena. Itzuli gabe, pod helbideak muturretik muturrera mantentzen dira, hobea da egozpenarentzat eta okerragoa bidean tarte berri bat ikasi behar duen gailu bakoitzarentzat. Bi aukerak ez dira Docker edo CNI akats bat; biak bideratze-erabakiak dira, faktura operatibo batekin. Aukeratu zure taldeak ordaindu dezakeen faktura duena, eta idatzi zergatia.

Egiaztatu eta itzuli

Exekutatu harrapaketa bera berriro. Nodo-mailako harrapaketa batek zure edizioaren ondoren pod-aren helbidea oraindik inprimatzen badu, arauak ez ziren inoiz aldatu, ConfigMap-ak zer esan ere. Kablea da egitatea; gainerako guztia inferentzia da.

Gero egiaztatu alderantzizko noranzkoa, aldaketa hauen erdia irteerako noranzkoan soilik egiaztatzen delako. Egiaztatu erantzuna eskaera bidali zuen nodora edo pod-era iristen dela, eta egiaztatu aplikazioak amaitu zuela, SYN bat jaso soilik egin beharrean. Erantzunik gabeko eskaera erakusten duen harrapaketa beste aldeko bideratze-arazo bat da, ez alde honetako masquerade-arazo bat.

Itzultzea aurreko ConfigMap-a da, modu berean aplikatuta, agentea berrabiarazi dela eta arauak aldatu direla berretsiz. Gorde ezagututako eskaera baten jatorrizko helbidea aldaketaren erregistroan, aurretik eta ondoren, lerro hori bakarrik frogatzen duelako aldaketak esan zenuena egin zuela. GKEren IP masquerade agentearen gidak lehenetsitako balioak eta ConfigMap-eremuak dokumentatzen ditu. Hedapenaren ondoren jatorrizko helbidea aldatzen ez bada, agentea ez da nodo horretan exekutatzen eta YAML editatzeak ez du konponduko.