Pody GKE ztratily přístup k VPN po verzi 1.14: dva způsoby, jak opravit zdroj

Po verzi 1.14 pody dosahují VPN s vlastními adresami, takže peerové zahazují odpovědi. Zvolte kontrakt zdroje a potom nastavte nonMasqueradeCIDRs podle něj.

Přijde aktualizace a systémy na druhé straně tunelu začnou odmítat provoz podů, který předchozí týden fungoval. Tunel je nahoře, pravidla firewallu jsou nedotčená a nikdo needitoval politiku peera. Co se změnilo, není v logech clusteru vidět: zdrojová adresa, kterou tyto systémy nyní vidí. Tato mezera vysvětluje poruchu, která vypadá jako výpadek sítě a chová se jako problém s oprávněním.

Existují dvě platné odpovědi a vedou na různá místa. Zvolte kontrakt zdroje, než začnete editovat ConfigMap.

Výchozí pravidlo, které se přestalo instalovat

Starší verze GKE instalovaly pravidlo masquerade, které nahrazovalo zdroje podů adresou uzlu, kdykoli cíl ležel mimo 10.0.0.0/8. VPN brána uvnitř tohoto rozsahu viděla adresu podu, zatímco cokoli dál vypadalo, že přichází z uzlu. Peerové stavěli seznamy povolených adres a zpětné trasy kolem adres uzlů, protože to pozorovali.

Novější verze přestaly toto výchozí pravidlo instalovat. Provoz podů nyní dorazí na bránu s adresami podů, ať je cíl jakýkoli. Peer, který směruje jen adresy uzlů, odpovědi zahazuje a žádná strana nezapíše užitečný záznam do logu. Požadavek může na vzdálené straně dokonce uspět, a právě to dělá poruchu matoucí při hledání.

Nic není rozbité ve smyslu mrtvé komponenty. Obě strany se prostě neshodnou, který zdroj je legitimní.

Zvolte zdroj, který má peer vidět

Zachování adres podů je přesnější kontrakt. Vzdálená strana vidí úlohu, která provoz vytvořila, logy zůstávají poctivé a politika pro jednotlivé pody je možná. Cenou je, že peer musí nést prefix podů.

Zachování adres uzlů je levnější kontrakt. Zapněte maskování pro tento cíl znovu a peer dál vidí adresu, které už věří.

Mezi oběma rozhoduje jedna otázka: co peer se zdrojem dělá? Pokud loguje, uplatňuje politiku pro jednotlivé zdroje nebo vynucuje úzké zpětné směrování, adresy podů dodatečnou konfiguraci ospravedlňují. Pokud potřebuje jen odesílat odpovědi, maskování stojí méně a od druhé strany nic nechce. Každá volba je obhajitelná, dokud si ji oba týmy zapíšou.

Třetí možnost je obvykle chyba: maskovat vše a ztratit schopnost provoz přiřadit. Vyhněte se jí, pokud peer opravdu neumí směrovat nic jiného než adresy uzlů.

Namiřte nonMasqueradeCIDRs na skutečné rozsahy

GKE spouští ip-masq-agent v kube-system a jeho ConfigMap uvádí cíle, které maskování přeskakují. Aby se zdroje podů směrem k tunelu zachovaly, patří do tohoto seznamu rozsah podů, podsíť uzlů i lokální prefix.

Nahraďte ukázkové hodnoty rozsahy z vašeho clusteru. Neširte seznam víc, než požadavek vyžaduje, protože každý další záznam mění, co vidí nějaký jiný cíl. Tři záznamy níže představují síť podů, podsíť uzlů a prefix za tunelem:

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

Záznam 0.0.0.0/0 vypne maskování pro všechny cíle, což mění, jak nesouvisející úlohy vypadají pro externí služby, a málokdy je zamýšlený. Agent znovu čte svou konfiguraci při resyncInterval, takže restart obvykle není potřeba. Zkontrolujte, že pod agenta běží, a pak otevřete připojený soubor uvnitř něj. Právě přečtení toho souboru dokazuje, že změna dorazila.

Zpětná cesta je druhá polovina

Maskování mění zdroj požadavku a nic jiného. Ať peer obdrží jakýkoli zdroj, stále k němu potřebuje trasu zpět a cluster stále potřebuje trasu k peerovi.

Snímek na VPN bráně obě poruchy rychle oddělí. Pakety, které dorazí s adresami podů a nikdy nedostanou odpověď, znamenají, že peer nemá trasu pro prefix podů. Odpověď, která se objeví na bráně, ale nikdy nedorazí do clusteru, znamená, že chybí lokální trasa. Zapište kontrakt do tiketu tak jako tak: který zdroj peer vidí a na který prefix směruje odpověď.

Po každé aktualizaci znovu zkontrolujte

Výchozí chování maskování se už jednou změnilo a nahrazení poolu uzlů může resetovat síť clusteru. Berte kontrakt zdroje jako něco k ověření, ne k předpokladu.

Po aktualizaci pošlete jeden požadavek z podu na lokální službu a přečtěte zdroj, který peer loguje. To jediné pozorování zachytí regresi, kterou stránka stavu tunelu ráda nahlásí jako zdravou. Opakování stojí minutu a ušetří dalšímu člověku večer.

Související články