Pse pod-et e GKE nuk arrijnë hostet lokale përmes VPN

Ping-u funksionon nga nodi dhe dështon nga pod-i, dhe lokalisht nuk arrin asgjë. Tuneli dhe rruga janë në rregull; adresa burimore në tel nuk është. Ajo që i dallon këto dy raste është çfarë pretendon paketa se është kur lë grupin, dhe GKE ka një mendim për këtë. Mekanizmi është një listë përjashtimesh masquerade, dhe leximi i saj kërkon një komandë të vetme.

Lexoni listën efektive përpara se të ndryshoni çdo gjë

GKE ofron një agjent që vendos, për çdo interval destinacioni, nëse trafiku i pod-eve rishkruhet në adresën e nodit në dalje. Konfigurimi i tij i dorëzuar emërton tre blloqet RFC1918, 10.0.0.0/8, 172.16.0.0/12 dhe 192.168.0.0/16, si destinacione të përjashtuara. Prandaj çdo gjë që dërgoni nga një pod drejt një hosti lokal 10.x e lë nodin me adresën e vetë pod-it ende të bashkangjitur. Trafiku i vetë nodit nuk rishkruhet, dhe pikërisht për këtë ping-u i tij funksionon.

Lexoni konfigurimin e synuar dhe rregullat e instaluara, sepse mund të mos përputhen. kubectl -n kube-system get configmap ip-masq-agent -o yaml tregon çfarë iu tha agjentit, dhe kubectl -n kube-system get pods -l k8s-app=ip-masq-agent tregon nëse diçka po ekzekutohet për ta zbatuar. Në një nod, iptables-save | grep -i masq tregon rregullat që ekzistojnë vërtet në kernel. Kur ConfigMap thotë një gjë dhe rregullat një tjetër, i dyshuari është agjenti, jo rrjeti.

Konfirmoni adresën burimore me një kapje

Bëni një kapje përpara se të ndryshoni një listë. Një filtër mbi destinacionin e vetëm e mban daljen të lexueshme: tcpdump -ni any host 10.20.30.40.

Krahasojeni këtë me atë që raporton pala tjetër. Një kapje lokalisht që tregon adresën e pod-it dhe asnjë përgjigje e mbyll rrethin: lista e përjashtimeve shpjegon asimetrinë pa asnjë defekt tuneli. Dy vëzhgime të një adrese burimore mjaftojnë për të ndaluar hamendësimin rreth CNI-së.

Ngushtoni përjashtimin te CIDR-i i pod-eve

Riparimi i mbështetur e ngushton përjashtimin në vend që ta heqë: mbani CIDR-in e pod-eve të përjashtuar dhe hiqni pjesën tjetër të hapësirës 10.x. Ajo listë jeton në ConfigMap-in e agjentit nën nonMasqueradeCIDRs, dhe ndryshimi i saj është një redaktim i ndjekur nga një publikim. Zëvendësoni hyrjen e gjerë me intervalin real të pod-eve të grupit, mbani blloqet e tjera private nëse trafiku brenda grupit vazhdon t’i ketë nevojë, dhe lini resyncInterval të qetë nëse nuk keni arsye. Zbatojeni, konfirmoni që pod-et e agjentit u rindezën dhe konfirmoni që rregullat e kernelit ndryshuan.

Ky është një ndryshim në të gjithë grupin me një rreze reale ndikimi. Pasi ai hyn në fuqi, trafiku që më parë mbante burimin e pod-it tani arrin i rishkruar në nod, kështu që çdo gjë që mbështetej në ato adresa pod-i sheh një dërgues tjetër. Viktimat janë regjistrat, listat e lejimit dhe rregullat lokale të firewall-it që emërtojnë adresa pod-i, dhe ato dështojnë në heshtje. Shpallni ndryshimin si ndryshim sjelljeje, jo si rregullim.

Në një grup me disa pishina nyjesh, kontrolloni që agjenti është planifikuar në nyjet ku pod-et e prekura vërtet ekzekutohen. Një pishinë pa DaemonSet mban rregullat e saj të vjetra, dhe asgjë në ConfigMap nuk do ta tregojë atë.

Alternativa dhe kostoja e saj

Opsioni tjetër i mban adresat e pod-eve të paprekura dhe e mëson rrugën rreth tyre. CIDR-i i pod-eve hyn në përzgjedhësit e trafikut të Cloud VPN, dhe pala lokale ka nevojë për një rrugë kthimi për të, që përgjigjet të dinë ku të shkojnë. Kjo ruan identitetin e pod-it, të cilin disa modele sigurie e duan, dhe zgjeron si shtrirjen e rrugëzimit ashtu edhe atë të firewall-it që pala tjetër duhet të pranojë.

Shkëmbimi është lexueshmëria kundrejt shtrirjes. Përkthimi e bën palën lokale të shohë një adresë për nyje, që është e lehtë për t’u vendosur në një listë lejimi dhe fsheh se cili pod dërgoi çfarë. Pa përkthim, adresa e pod-it mbahet nga fillimi në fund, që është më mirë për atribuimin dhe më keq për çdo pajisje në rrugë që duhet të mësojë një interval të ri. Asnjë opsion nuk është defekt i Docker ose i CNI-së; të dyja janë vendime rrugëzimi me një faturë operative. Zgjidhni atë që fatura e saj mund të paguhet nga ekipi juaj, dhe shkruani pse.

Verifikoni dhe ktheni mbrapsht

Ekzekutoni të njëjtën kapje përsëri. Një kapje në nivel nyje që pas redaktimit tuaj ende shtyp adresën e pod-it do të thotë që rregullat nuk ndryshuan kurrë, çfarëdo që thotë ConfigMap. Teli është fakti; gjithçka tjetër është konkluzion.

Më pas kontrolloni drejtimin e kundërt, sepse gjysma e këtyre ndryshimeve verifikohen vetëm në dalje. Konfirmoni që përgjigjja arrin nyjen ose pod-in që dërgoi kërkesën, dhe konfirmoni që aplikacioni përfundoi në vend që thjesht të merrte një SYN. Një kapje që tregon një kërkesë pa përgjigje është problem rrugëzimi në palën tjetër, jo problem masquerade në këtë palë.

Kthimi mbrapsht është ConfigMap-i i mëparshëm, i zbatuar në të njëjtën mënyrë, me të njëjtin konfirmim që agjenti u rindez dhe rregullat ndryshuan. Ruani adresën burimore para dhe pas për një kërkesë të njohur në regjistrin e ndryshimeve, sepse pikërisht ai rresht i vetëm provon që ndryshimi bëri atë që thatë. Udhëzuesi i GKE për agjentin masquerade IP dokumenton parazgjedhjet dhe fushat e ConfigMap. Nëse adresa burimore është e pandryshuar pas publikimit, agjenti nuk po ekzekutohet në atë nyje dhe asnjë redaktim YAML nuk do ta rregullojë.