Kwa nini pod za GKE hazifiki kwenye host za ndani kupitia VPN

Ping inafanya kazi kutoka kwa nodi na kushindwa kutoka kwa pod, na hakuna kinachofika ndani. Handaki na njia ni sawa; anwani ya chanzo kwenye waya si sawa. Kinachotofautisha visa hivi viwili ni kile ambacho pakiti inadai kuwa wakati inaondoka kwenye kundi, na GKE ina maoni kuhusu hilo. Utaratibu ni orodha ya misamaha ya masquerade, na kuisona kunahitaji amri moja.

Soma orodha inayotumika kabla ya kubadilisha chochote

GKE hutoa wakala anayeamua, kwa kila anuwai ya marudio, ikiwa trafiki ya pod itaandikwa upya kwa anwani ya nodi wakati wa kutoka. Mipangilio yake iliyowasilishwa inataja vitalu vitatu vya RFC1918, 10.0.0.0/8, 172.16.0.0/12 na 192.168.0.0/16, kama marudio yaliyosamehewa. Kwa hivyo kila kitu unachotuma kutoka kwa pod kwenda kwa host ya ndani ya 10.x kinaondoka kwenye nodi na anwani ya pod yenyewe bado imeambatishwa. Trafiki ya nodi yenyewe haiandikwi upya, na ndiyo sababu ping yake inafanya kazi.

Soma mipangilio iliyokusudiwa na kanuni zilizosakinishwa, kwa sababu zinaweza kutokubaliana. kubectl -n kube-system get configmap ip-masq-agent -o yaml inaonyesha kile wakala alichoambiwa, na kubectl -n kube-system get pods -l k8s-app=ip-masq-agent inaonyesha ikiwa kuna kitu kinachoendesha ili kuitumia. Kwenye nodi, iptables-save | grep -i masq inaonyesha kanuni zilizopo kweli kwenye kerneli. Wakati ConfigMap inasema kitu kimoja na kanuni kingine, mtuhumiwa ni wakala, si mtandao.

Thibitisha anwani ya chanzo kwa kunasa

Fanya kunasa kabla ya kubadilisha orodha. Kichujio kwenye marudio moja huweka matokeo yakiwa yanasomeka: tcpdump -ni any host 10.20.30.40.

Linganisha hilo na kile upande wa pili unaripoti. Kunasa ndani kunakoonyesha anwani ya pod na hakuna jibu hufunga mduara: orodha ya misamaha inaeleza utofauti bila hitilafu yoyote ya handaki. Uchunguzi wa mara mbili wa anwani moja ya chanzo unatosha kuacha kukisia kuhusu CNI.

Punguza msamaha hadi CIDR ya pod

Ukamilishaji unaoungwa mkono hupunguza msamaha badala ya kuuondoa: weka CIDR ya pod kama msamaha na uondoe sehemu iliyobaki ya nafasi ya 10.x. Orodha hiyo inakaa kwenye ConfigMap ya wakala chini ya nonMasqueradeCIDRs, na kuibadilisha ni uhariri unaofuatiwa na uenezaji. Badilisha ingizo pana kwa anuwai halisi ya pod za kundi, weka vitalu vingine vya kibinafsi ikiwa trafiki ndani ya kundi bado inavihitaji, na uache resyncInterval kama ilivyo isipokuwa una sababu. Itumie, thibitisha kwamba pod za wakala zilianza upya, na thibitisha kwamba kanuni za kerneli zilibadilika.

Huu ni mabadiliko ya kundi zima lenye athari halisi. Mara yanapotekelezwa, trafiki iliyokuwa ikihifadhi chanzo chake cha pod sasa inafika ikiwa imeandikwa upya kwa nodi, kwa hivyo kila kitu kilichotegemea anwani hizo za pod kinaona mtumaji tofauti. Waathirika ni kumbukumbu, orodha za ruhusa na kanuni za firewall za ndani zinazotaja anwani za pod, na zote hushindwa kimya kimya. Tangaza mabadiliko kama mabadiliko ya tabia, si kama ukamilishaji.

Katika kundi lenye mabwawa kadhaa ya nodi, angalia ikiwa wakala amepangwa kwenye nodi ambazo pod zilizoathirika zinaendeshwa kweli. Bwawa lisilo na DaemonSet huweka kanuni zake za zamani, na hakuna chochote kwenye ConfigMap kitakachoonyesha hilo.

Njia mbadala na gharama yake

Chaguo lingine huweka anwani za pod zikiwa hazijaguswa na hufundisha njia kuzihusu. CIDR ya pod inaingia kwenye vichaguzi vya trafiki vya Cloud VPN, na upande wa ndani unahitaji njia ya kurudi kwa ajili yake ili majibu yajue wapi pa kwenda. Hii huhifadhi utambulisho wa pod, ambao baadhi ya mifumo ya usalama inautaka, na hupanua wigo wa uelekezaji na wigo wa firewall ambao upande wa pili lazima ukubali.

Biashara ni usomaji dhidi ya wigo. Tafsiri hufanya upande wa ndani uone anwani moja kwa kila nodi, ambayo ni rahisi kuweka kwenye orodha ya ruhusa na huficha pod ipi ilituma nini. Bila tafsiri, anwani ya pod huhifadhiwa kutoka mwanzo hadi mwisho, ambayo ni bora kwa uhusishaji na mbaya kwa kila kifaa kilicho kwenye njia kinachopaswa kujifunza anuwai mpya. Hakuna chaguo ambalo ni kasoro ya Docker au CNI; zote ni maamuzi ya uelekezaji yenye bili ya uendeshaji. Chagua ile ambayo timu yako inaweza kulipa bili yake, na uandike kwa nini.

Thibitisha na urudishe

Endesha kunasa hicho hicho tena. Kunasa kwa kiwango cha nodi ambacho bado kinachapisha anwani ya pod baada ya uhariri wako kunamaanisha kanuni hazikubadilika kamwe, chochote ConfigMap inachosema. Waya ndiyo ukweli; kila kitu kingine ni makisio.

Kisha angalia mwelekeo kinyume, kwa sababu nusu ya mabadiliko haya huthibitishwa kwa njia ya kutoka tu. Thibitisha kwamba jibu linafika kwa nodi au pod iliyotuma ombi, na thibitisha kwamba programu ilikamilika badala ya kupokea SYN tu. Kunasa kunakoonyesha ombi lisilo na jibu ni tatizo la uelekezaji upande wa pili, si tatizo la masquerade upande huu.

Kurudisha ni ConfigMap ya awali, ikitumika kwa njia ile ile, na uthibitisho ule ule kwamba wakala alianza upya na kanuni zilibadilika. Hifadhi anwani ya chanzo kabla na baada kwa ombi moja linalojulikana kwenye rekodi ya mabadiliko, kwa sababu mstari huo mmoja ndio unaothibitisha kwamba mabadiliko yalifanya ulichosema. Mwongozo wa GKE wa wakala wa masquerade IP unaandika chaguo-msingi na sehemu za ConfigMap. Ikiwa anwani ya chanzo haijabadilika baada ya uenezaji, wakala hafanyi kazi kwenye nodi hiyo na hakuna uhariri wowote wa YAML utakaorekebisha hilo.