Ինչու GKE pod-երը VPN-ով չեն հասնում տեղական հոսթերին

Ping-ը աշխատում է հանգույցից և ձախողվում pod-ից, և տեղական կողմ ոչինչ չի հասնում։ Թունելը և երթուղին կարգին են, մալուխի վրա եղած աղբյուրի հասցեն՝ ոչ։ Այս երկու դեպքերը տարբերում է այն, թե ինչ է պնդում փաթեթն իր մասին՝ կլաստերից դուրս գալիս, և GKE-ն այդ հարցում իր կարծիքն ունի։ Մեխանիզմը masquerade բացառությունների ցանկն է, և այն կարդալու համար բավական է մեկ հրաման։

Կարդացեք գործող ցանկը, նախքան որևէ բան կփոխեք

GKE-ն տրամադրում է գործակալ, որը յուրաքանչյուր նպատակակետի տիրույթի համար որոշում է՝ արդյոք pod-երի երթևեկությունը դուրս գալիս կվերագրվի հանգույցի հասցեին։ Նրա մատակարարված կոնֆիգուրացիան անվանում է երեք RFC1918 բլոկները՝ 10.0.0.0/8, 172.16.0.0/12 և 192.168.0.0/16, որպես բացառված նպատակակետեր։ Ուստի այն ամենը, ինչ ուղարկում եք pod-ից տեղական 10.x հոսթին, հանգույցը թողնում է pod-ի սեփական հասցեով դեռ ամրացված։ Հանգույցի սեփական երթևեկությունը չի վերագրվում, և հենց դա է պատճառը, որ նրա ping-ը աշխատում է։

Կարդացեք նախատեսված կոնֆիգուրացիան և տեղադրված կանոնները, որովհետև դրանք կարող են չհամընկնել։ kubectl -n kube-system get configmap ip-masq-agent -o yaml ցույց է տալիս, թե ինչ ասվեց գործակալին, և kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ցույց է տալիս՝ արդյոք ինչ-որ բան աշխատում է այն կիրառելու համար։ Հանգույցի վրա iptables-save | grep -i masq ցույց է տալիս կանոնները, որոնք իրոք կան միջուկում։ Երբ ConfigMap-ը մի բան է ասում, իսկ կանոնները՝ մեկ այլ, կասկածյալը գործակալն է, ոչ թե ցանցը։

Հաստատեք աղբյուրի հասցեն որսով

Որս արեք նախքան ցանկը փոխելը։ Մեկ նպատակակետի վրա զտիչը ելքը պահում է ընթեռնելի՝ tcpdump -ni any host 10.20.30.40։

Համեմատեք դա այն բանի հետ, ինչ հաղորդում է հակառակ կողմը։ Տեղական կողմում արված որսը, որը ցույց է տալիս pod-ի հասցեն և պատասխան չկա, փակում է շրջանակը՝ բացառությունների ցանկը բացատրում է անհամաչափությունը առանց թունելի որևէ խափանման։ Մեկ աղբյուրի հասցեի երկու դիտարկումը բավական է CNI-ի մասին ենթադրությունները դադարեցնելու համար։

Նեղացրեք բացառությունը մինչև pod-երի CIDR

Աջակցվող վերանորոգումը նեղացնում է բացառությունը՝ փոխանակ այն հեռացնելու՝ pod-երի CIDR-ը թողեք բացառված և դեն նետեք 10.x տարածքի մնացած մասը։ Այդ ցանկը գտնվում է գործակալի ConfigMap-ում nonMasqueradeCIDRs-ի տակ, և այն փոխելը խմբագրում է, որին հաջորդում է տեղադրումը։ Փոխարինեք լայն գրառումը կլաստերի իրական pod-երի տիրույթով, պահեք մյուս մասնավոր բլոկները, եթե կլաստերի ներսում երթևեկությանը դեռ պետք են դրանք, և resyncInterval-ին ձեռք չտաք, եթե պատճառ չունեք։ Կիրառեք, հաստատեք, որ գործակալի pod-երը վերագործարկվել են, և հաստատեք, որ միջուկի կանոնները փոխվել են։

Սա ամբողջ կլաստերի փոփոխություն է՝ իրական ազդեցության շառավղով։ Կիրառվելուց հետո երթևեկությունը, որը նախկինում պահում էր իր pod-ի աղբյուրը, այժմ հասնում է հանգույցին վերագրված, ուստի այն ամենը, ինչ հենվում էր այդ pod-երի հասցեների վրա, տեսնում է այլ ուղարկող։ Զոհերը լոգերն են, թույլատրելի ցանկերը և տեղական firewall-ի կանոնները, որոնք նշում են pod-երի հասցեները, և դրանք լուռ ձախողվում են։ Հայտարարեք փոփոխությունը որպես վարքի փոփոխություն, ոչ թե վերանորոգում։

Մի քանի հանգույցային պուլ ունեցող կլաստերում ստուգեք, թե արդյոք գործակալը պլանավորված է այն հանգույցներում, որտեղ տուժած pod-երն իրոք աշխատում են։ DaemonSet չունեցող պուլը պահում է իր հին կանոնները, և ConfigMap-ում ոչինչ դա ցույց չի տա։

Այլընտրանքը և դրա գինը

Մյուս տարբերակը pod-երի հասցեները թողնում է անփոփոխ և ուղուն սովորեցնում դրանց մասին։ Pod-երի CIDR-ը մտնում է Cloud VPN-ի երթևեկության ընտրիչների մեջ, և տեղական կողմին դրա համար պետք է վերադարձի երթուղի, որպեսզի պատասխանները իմանան ուր գնալ։ Սա պահպանում է pod-ի ինքնությունը, որն ուզում են որոշ անվտանգության մոդելներ, և լայնացնում է ինչպես երթուղավորման, այնպես էլ firewall-ի այն ծավալը, որը պետք է ընդունի հակառակ կողմը։

Փոխանակումը ընթեռնելիությունն է ընդդեմ ծավալի։ Թարգմանությունը տեղական կողմին ցույց է տալիս մեկ հասցե յուրաքանչյուր հանգույցի համար, ինչը հեշտ է ավելացնել թույլատրելի ցանկում և թաքցնում է, թե որ pod-ն ինչ ուղարկեց։ Առանց թարգմանության pod-ի հասցեն պահպանվում է ծայրից ծայր, ինչը լավ է վերագրության համար և վատ՝ ուղու յուրաքանչյուր սարքի համար, որը պետք է սովորի նոր տիրույթ։ Ոչ մի տարբերակ Docker-ի կամ CNI-ի արատ չէ. երկուսն էլ երթուղավորման որոշումներ են՝ գործառնական հաշիվով։ Ընտրեք այն, որի հաշիվը ձեր թիմը կարող է վճարել, և գրեք ինչու։

Ստուգեք և հետ վերցրեք

Կրկին գործարկեք նույն որսը։ Եթե ձեր խմբագրումից հետո հանգույցի մակարդակի որսը դեռ տպում է pod-ի հասցեն, նշանակում է կանոնները երբեք չեն փոխվել, ինչ էլ որ ասի ConfigMap-ը։ Փաստը մալուխն է, մնացածը՝ ենթադրություն։

Ապա ստուգեք հակառակ ուղղությունը, որովհետև այս փոփոխությունների կեսը ստուգվում է միայն դուրս գալիս։ Հաստատեք, որ պատասխանը հասնում է հարցումն ուղարկած հանգույցին կամ pod-ին, և հաստատեք, որ հավելվածը ավարտվեց, այլ ոչ թե պարզապես SYN ստացավ։ Որսը, որը ցույց է տալիս հարցում առանց պատասխանի, հակառակ կողմի երթուղավորման խնդիր է, ոչ թե այս կողմի masquerade խնդիր։

Հետ վերցնելը նախորդ ConfigMap-ն է՝ նույն ձևով կիրառված, նույն հաստատմամբ, որ գործակալը վերագործարկվել է և կանոնները փոխվել են։ Փոփոխությունների գրառման մեջ պահեք մեկ հայտնի հարցման աղբյուրի հասցեն առաջ և հետո, որովհետև հենց այդ մեկ տողն է ապացուցում, որ փոփոխությունը արեց այն, ինչ դուք ասացիք։ GKE-ի IP masquerade գործակալի ուղեցույցը նկարագրում է լռելյայն արժեքները և ConfigMap-ի դաշտերը։ Եթե տեղադրումից հետո աղբյուրի հասցեն չի փոխվել, գործակալը այդ հանգույցում չի աշխատում, և YAML-ի ոչ մի խմբագրում դա չի շտկի։