Pod-et e GKE humbën aksesin në VPN pas 1.14: dy mënyra për të rregulluar burimin

Vjen një përditësim dhe sistemet në anën tjetër të tunelit fillojnë të refuzojnë trafikun e pod-eve që funksiononte javën e kaluar. Tuneli është lart, rregullat e firewall-it janë të paprekura dhe askush nuk e ka redaktuar politikën e partnerit. Ajo që ndryshoi është e padukshme në regjistrat e klusterit: adresa e burimit që këto sisteme shohin tani. Ky hendek shpjegon një dështim që duket si ndërprerje rrjeti dhe sillet si problem lejeve.

Ekzistojnë dy përgjigje të vlefshme dhe ato të çojnë në vende të ndryshme. Zgjidhni kontratën e burimit përpara se të redaktoni një ConfigMap.

Rregulli i parazgjedhur që u ndal së instaluari

Versionet e mëparshme të GKE instalonin një rregull masquerade që zëvendësonte burimet e pod-eve me adresën e nyjës sa herë që destinacioni ndodhej jashtë 10.0.0.0/8. Një portë VPN brenda atij intervali shihte adresën e pod-it, ndërsa çdo gjë më larg dukej sikur vinte nga nyja. Partnerët ndërtuan lista lejimesh dhe rrugë kthimi rreth adresave të nyjave, sepse kjo është ajo që vëzhguan.

Versionet e mëvonshme ndaluan së instaluari atë rregull të parazgjedhur. Trafiku i pod-eve tani arrin në portë me adresa pod-esh, cilido qoftë destinacioni. Një partner që rrugëton vetëm adresa nyjash i hedh poshtë përgjigjet dhe asnjëra palë nuk shkruan një hyrje të dobishme regjistri. Kërkesa mund të ketë sukses edhe në skajin e largët, dhe kjo është ajo që e bën dështimin konfuz për t'u ndjekur.

Asgjë nuk është prishur në kuptimin e një komponenti të vdekur. Të dyja palët thjesht nuk bien dakord se cili burim është legjitim.

Zgjidhni burimin që partneri duhet të shohë

Mbajtja e adresave të pod-eve është kontrata më e saktë. Ana e largët sheh ngarkesën e punës që prodhoi trafikun, regjistrat mbeten të ndershëm dhe politika për çdo pod bëhet e mundur. Çmimi është që partneri duhet të mbajë prefiksin e pod-eve.

Mbajtja e adresave të nyjave është kontrata më e lirë. Riktheni masquerade për atë destinacion dhe partneri vazhdon të shohë një adresë që tashmë i beson.

Një pyetje vendos midis tyre: çfarë bën partneri me burimin? Nëse regjistron, zbaton politikë për çdo burim ose imponon rrugëtim të ngushtë kthimi, adresat e pod-eve justifikojnë konfigurimin shtesë. Nëse i duhet vetëm të dërgojë përgjigje, masquerade kushton më pak dhe nuk kërkon asgjë nga ana tjetër. Secila zgjedhje është e mbrojtshme për sa kohë të dy ekipet e shkruajnë.

Opsioni i tretë zakonisht është gabim: masquerade për gjithçka dhe humbja e aftësisë për të atribuuar trafikun. Shmangeni, përveçse kur një partner vërtet nuk mund të rrugëtojë asgjë tjetër përveç adresave të nyjave.

Drejtojeni nonMasqueradeCIDRs drejt intervaleve reale

GKE ekzekuton ip-masq-agent në kube-system, dhe ConfigMap-i i tij liston destinacionet që anashkalojnë masquerade. Për të ruajtur burimet e pod-eve drejt tunelit, intervali i pod-eve, nënrrjeti i nyjës dhe prefiksi lokal të gjithë i përkasin atij listi.

Zëvendësoni vlerat e shembullit me intervale nga klusteri juaj. Mos e bëni listën më të gjerë sesa kërkon nevoja, sepse çdo hyrje shtesë ndryshon atë që sheh një destinacion tjetër. Tre hyrjet më poshtë përfaqësojnë rrjetin e pod-eve, nënrrjetin e nyjës dhe prefiksin pas tunelit:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Një hyrje 0.0.0.0/0 çaktivizon masquerade për të gjitha destinacionet, gjë që ndryshon si duken ngarkesat e punës të palidhura për shërbimet e jashtme dhe rrallë është e qëllimshme. Agjenti e rilexon konfigurimin e tij në resyncInterval, kështu që një rinisje zakonisht nuk është e nevojshme. Kontrolloni nëse pod-i i agjentit po punon dhe më pas hapni skedarin e montuar brenda tij. Është leximi i atij skedari ai që provon se ndryshimi ka mbërritur.

Rruga e përgjigjes është gjysma tjetër

Masquerade ndryshon burimin e kërkesës dhe asgjë tjetër. Cilindo burim që partneri merr, ai ende ka nevojë për një rrugë kthimi drejt tij, dhe klusteri ende ka nevojë për një rrugë drejt partnerit.

Një kapje në portën VPN i ndan shpejt të dyja dështimet. Paketat që vijnë me adresa pod-esh dhe nuk marrin kurrë përgjigje nënkuptojnë se partnerit i mungon një rrugë për prefiksin e pod-eve. Një përgjigje që shfaqet në portë por nuk arrin kurrë në kluster nënkupton se rruga lokale mungon. Shkruajeni kontratën në tiketë sidoqoftë: cilin burim sheh partneri dhe në cilin prefiks e rrugëton përgjigjen.

Rikontrolloni pas çdo përditësimi

Sjellja e parazgjedhur e masquerade ka ndryshuar tashmë një herë, dhe zëvendësimi i një grupi nyjash mund të rivendosë rrjetin e klusterit. Trajtojeni kontratën e burimit si diçka për t'u verifikuar, jo për t'u supozuar.

Pas një përditësimi, dërgoni një kërkesë nga një pod te një shërbim lokal dhe lexoni burimin që regjistron partneri. Ai vëzhgim i vetëm kap një regres që një faqe statusi e tunelit do ta raportonte me gëzim si të shëndoshë. Përsëritja kushton një minutë dhe i kursen një mbrëmje personit tjetër.