GKE-pods het ná 1.14 VPN-toegang verloor: twee maniere om die bron reg te maak

'n Opgradering kom deur, en stelsels oorkant die tonnel begin pod-verkeer verwerp wat die vorige week nog gewerk het. Die tonnel is op, die firewall-reëls is ongemoeid, en niemand het die eweknie-beleid gewysig nie. Wat verander het, is onsigbaar in die cluster-logboeke: die bronadres wat daardie stelsels nou sien. Daardie gaping verduidelik 'n fout wat soos 'n netwerkonderbreking lyk en soos 'n regteprobleem optree.

Daar is twee geldige antwoorde, en hulle stuur jou na verskillende plekke. Kies die bronkontrak voordat jy 'n ConfigMap wysig.

Die verstekreël wat nie meer geïnstalleer word nie

Vroeër GKE-weergawes het 'n maskeerreël geïnstalleer wat pod-bronne met die nodusadres vervang het wanneer die bestemming buite 10.0.0.0/8 gelê het. 'n VPN-gateway binne daardie reeks het die pod-adres gesien, terwyl enigiets verder weg gelyk het of dit van die nodus kom. Eweknieë het toelatingslyste en terugroetes rondom nodusadresse gebou, want dit is wat hulle waargeneem het.

Latere weergawes het opgehou om daardie verstekreël te installeer. Pod-verkeer arriveer nou by die gateway met pod-adresse, ongeag die bestemming. 'n Eweknie wat net nodusadresse routeer, laat die antwoorde val, en nie een van die kante skryf 'n nuttige logboekinskrywing nie. Die versoek kan selfs aan die ander kant slaag, en dit is wat die fout verwarrend maak om op te spoor.

Nikshe is stukkend in die sin van 'n dooie komponent nie. Die twee kante verskil bloot oor watter bron wettig is.

Kies die bron wat die eweknie moet sien

Om pod-adresse te behou, is die akkurater kontrak. Die ander kant sien die werklaag wat die verkeer geproduseer het, die logboeke bly eerlik, en beleid per pod word moontlik. Die prys is dat die eweknie die pod-voorvoegsel moet dra.

Om nodusadresse te behou, is die goedkoper kontrak. Skakel maskering weer aan vir daardie bestemming, en die eweknie bly 'n adres sien wat hy reeds vertrou.

Een vraag besluit tussen hulle: wat doen die eweknie met die bron? As dit logboek, beleid per bron toepas of smal terugroetes afdwing, regverdig pod-adresse die ekstra konfigurasie. As dit net antwoorde hoef te stuur, kos maskering minder en vra niks van die ander kant nie. Enige keuse is verdedigbaar solank albei spanne dit neerskryf.

Die derde opsie is gewoonlik 'n fout: maskeer alles en verloor die vermoë om verkeer toe te skryf. Vermy dit, tensy 'n eweknie werklik niks anders as nodusadresse kan routeer nie.

Wys nonMasqueradeCIDRs na die werklike reekse

GKE laat die ip-masq-agent in kube-system loop, en sy ConfigMap lys die bestemmings wat maskering oorslaan. Om pod-bronne na die tonnel te bewaar, hoort die pod-reeks, die nodus-subnet en die plaaslike voorvoegsel almal in daardie lys.

Vervang die voorbeeldwaardes met reekse uit jou eie cluster. Hou die lys nie wyer as wat die vereiste bepaal nie, want elke ekstra inskrywing verander wat een of ander ander bestemming sien. Die drie inskrywings hieronder staan vir die pod-netwerk, die nodus-subnet en die voorvoegsel agter die tonnel:

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

'n Inskrywing van 0.0.0.0/0 skakel maskering vir alle bestemmings af, wat verander hoe onverwante werklaste vir buitedienste lyk en selde bedoel word. Die agent lees sy konfigurasie weer op resyncInterval, so 'n herbegin is gewoonlik onnodig. Kyk of die agent-pod loop en maak dan die gemonteerde lêer daarbinne oop. Die lees van daardie lêer is wat bewys die verandering het aangekom.

Die antwoordroete is die ander helfte

Maskering verander die versoekbron en niks anders nie. Watter bron die eweknie ook al ontvang, hy het steeds 'n roete terug daarheen nodig, en die cluster het steeds 'n roete na die eweknie nodig.

'n Vangs op die VPN-gateway skei die twee foute vinnig. Pakkette wat met pod-adresse aankom en nooit 'n antwoord kry nie, beteken die eweknie het nie 'n roete vir die pod-voorvoegsel nie. 'n Antwoord wat op die gateway verskyn maar nooit die cluster bereik nie, beteken die plaaslike roete ontbreek. Skryf die kontrak in die kaartjie in elk geval: watter bron die eweknie sien, en watter voorvoegsel hy terug routeer.

Kontroleer weer ná elke opgradering

Verstek-maskeergedrag het al een keer verander, en die vervanging van 'n noduspoel kan cluster-netwerking terugstel. Behandel die bronkontrak as iets om te verifieer eerder as iets om te aanvaar.

Stuur ná 'n opgradering een versoek van 'n pod na 'n plaaslike diens en lees die bron wat die eweknie logboek. Daardie enkele waarneming vang 'n regressie wat 'n tonnel-statusbladsy met graagte as gesond sal rapporteer. Om dit te herhaal kos 'n minuut en spaar die volgende persoon 'n aand.