GKE-pods ferlearen nei 1.14 de VPN-tagong: twa manieren om de boarne te reparearjen

Nei 1.14 berikke pods de VPN mei har eigen adressen, dat peers smite antwurden fuort. Kies it boarnekontrakt en set dan nonMasqueradeCIDRs dêrop ôf.

In upgrade komt del, en systemen oan 'e oare kant fan 'e tunnel begjinne podferkear te wegerjen dat de foarige wike noch wurke. De tunnel is omheech, de firewallregels binne ûnoantaaste, en nimmen hat it peerbelied bewurke. Wat feroare is, is ûnsichtber yn 'e clusterlogs: it boarne-adres dat dy systemen no sjogge. Dat gat ferklearret in flater dy't op in netwurkútfal liket en him as in rjochteprobleem hâldt.

Der binne twa jildige antwurden, en se stjoere jo nei ferskillende plakken. Kies it boarnekontrakt foardat jo in ConfigMap bewurkje.

De standertregel dy't net mear ynstallearre waard

Eardere GKE-útjeften ynstallearren in masquerade-regel dy't podboarnen ferfong troch it node-adres wannear't de bestimming bûten 10.0.0.0/8 lei. In VPN-gateway binnen dat berik seach it pod-adres, wylst alles fierder fuort like fan 'e node te kommen. Peers bouden listlisten en weromrûtes om node-adressen hinne, om't se dat waarnamen.

Lettere útjeften stoppen mei it ynstallearjen fan dy standertregel. Podferkear komt no by de gateway oan mei pod-adressen, hokker bestimming dan ek. In peer dy't allinnich node-adressen rûtelet, smyt de antwurden fuort, en gjin fan beide kanten skriuwt in nuttige logynfiering. It fersyk kin sels oan 'e fiere kant slagje, en dat is wat de flater dreech te efterfolgjen makket.

Neat is stikken yn 'e sin fan in dea komponint. De twa kanten binne it gewoan net iens oer hokker boarne legit is.

Kies de boarne dy't de peer sjen moat

Pod-adressen hâlde is it krekter kontrakt. De fiere kant sjocht de wurkbelesting dy't it ferkear makke, de logs bliuwe earlik, en belied per pod wurdt mooglik. De priis is dat de peer it pod-prefiks drage moat.

Node-adressen hâlde is it goedkeapere kontrakt. Set masquerade foar dy bestimming wer oan en de peer bliuwt in adres sjen dat er al fertrout.

Ien fraach beslút tusken beide: wat docht de peer mei de boarne? As er logt, belied per boarne tapast of smelle weromrûteleas jout, rjochtfeardigje pod-adressen de ekstra konfiguraasje. As er allinnich antwurden stjoere moat, kostet masquerade minder en freget er neat fan 'e oare kant. Elke kar is ferdigenber salang't beide teams it opskriuwe.

In tredde opsje is meastentiids in flater: alles masquerade en de mooglikheid ferlieze om ferkear ta te skriuwen. Foarkom it, útsein as in peer wier neat oars as node-adressen rûtele kin.

Rjochtsje nonMasqueradeCIDRs op 'e echte berikken

GKE draait de ip-masq-agent yn kube-system, en syn ConfigMap listet de bestimmingen dy't masquerade oerslaan. Om podboarnen rjochting de tunnel te bewarjen, hearre it pod-berik, it node-subnet en it lokale prefiks allegear yn dy list.

Ferfang de foarbyldwearden troch berikken út jo eigen cluster. Meitsje de list net breder as de eask bepaalt, om't elke ekstra ynfiering feroaret wat in oare bestimming sjocht. De trije ynfieringen hjirûnder steane foar it pod-netwurk, it node-subnet en it prefiks efter de tunnel:

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

In ynfiering fan 0.0.0.0/0 skeakelet masquerade foar alle bestimmingen út, wat feroaret hoe't net-relatearre wurkbelestings foar eksterne tsjinsten ferskine en it is selden bedoeld. De agent lêst syn konfiguraasje op resyncInterval op 'e nij, dus in werstart is meastentiids net nedich. Kontrolearje oft de agent-pod draait, iepenje dan it montearre bestân deryn. It lêzen fan dat bestân is wat bewiist dat de feroaring oankaam.

It antwurdpaad is de oare helte

Masquerade feroaret de boarne fan it fersyk en neat oars. Hokker boarne de peer ek krijt, hy hat noch hieltyd in rûte werom dêrhinne nedich, en it cluster hat noch hieltyd in rûte rjochting de peer nedich.

In opname op 'e VPN-gateway skiedt de twa flaters fluch. Pakketten dy't mei pod-adressen oankomme en nea in antwurd krije, betsjutte dat de peer gjin rûte hat foar it pod-prefiks. In antwurd dat op 'e gateway ferskynt mar nea it cluster berikt, betsjut dat de lokale rûte ûntbrekt. Skriuw it kontrakt yn 'e ticket hoe dan ek: hokker boarne de peer sjocht, en hokker prefiks er werom rûtelet.

Kontrolearje opnij nei elke upgrade

It standertgedrach fan masquerade is al ien kear feroare, en it ferfangen fan in nodepool kin it clusternetwurk weromsette. Behannelje it boarnekontrakt as eat om te ferifiearjen, net as eat om oan te nimmen.

Stjoer nei in upgrade ien fersyk fan in pod nei in lokale tsjinst en lês de boarne dy't de peer logt. Dy iene waarnimming fangt in regression dy't in tunnelstatusside graach as sûn rapportearje soe. It werheljen kostet in minút en sparret de folgjende persoan in jûn.

Relatearre artikelen