Pod, հանգույց թե կլաստեր. ինչ է իրականում վերահասցեավորում VPN sidecar-ը

Kubernetes Pod-ում VPN sidecar-ը նման է հոսթի մակարդակի VPN-ի՝ ավելի լավ վարքով, և նմանությունը վերջանում է անվանատարածքի սահմանին։ Մեկ Pod-ի կոնտեյներները կիսում են ցանցի անվանատարածքը՝ ներառյալ հասցեների և պորտերի տարածքը, ուստի երթուղիներ և քաղաքականություն տեղադրող sidecar-ը իսկապես փոխում է, թե ուր են գնում հավելվածի փաթեթները։ Այն ոչինչ չի փոխում հանգույցի մյուս Pod-երի համար և չի դիպչում հանգույցի սեփական ստեկին, եթե դուք այդպես չկարգավորեք։ Այդ սահմանը ճիշտ հասկանալը որոշում է և՛ ինչ կարող եք տեղակայել, և՛ ինչ պետք է փորձարկել։ Ստորև բաժինները հետևում են դրան անվանատարածքից դուրս։

Կիսված անվանատարածք, կիսված հետևանքներ

Մեկ Pod-ի երկու կոնտեյներ խոսում են loopback-ով և տեսնում նույն ինտերֆեյսները, և հենց դրա համար է sidecar-ի ձևանմուշն ընդհանրապես աշխատում՝ հավելվածը պետք չէ իմանա, որ թունել գոյություն ունի, քանի որ այն երթուղին, որին այն լուծում է, տեղադրվել է այն անվանատարածքում, որն օգտագործում է։ Նույն հատկությունը նշանակում է, որ sidecar-ի սխալները հավելվածի սխալներն են։ Չափից շատ բռնող երթուղին կամ DNS-ի փոփոխությունը, որը ցույց է տալիս թունելի ներսի լուծիչին, անմիջապես գործում է այդ Pod-ի յուրաքանչյուր գործընթացի վրա։ Կիսված անվանատարածքում կոնտեյներով երթուղավորում չկա, ուստի sidecar-ը հնարավոր չէ սահմանափակել մեկ գործընթացով։

Սա այն մեխանիզմն է, որ պետք է հիշել վերանայման ընթացքում՝ ազդեցության շառավիղը Pod-ն է, ոչ հանգույցը և ոչ կլաստերը։

Ուր sidecar-ը չի հասնում

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

Կլաստերի ծառայությունների տրաֆիկը մյուս սովորական անակնկալն է։ Pod-ի ներսում լայն լռելյայն երթուղին կարող է բռնել API սերվերին կամ ClusterIP ծառայությանը ուղղված հարցումները, և դրանք հետո ձախողվում են այնպես, կարծես թունելը կոտրված է։

Երթուղային պլան՝ Pod, ծառայության, հանգույցի և VPN միջակայքեր

Գրեք չորս միջակայքերը և ստուգեք դրանք համընկնման համար նախքան որևէ բան տեղակայելը՝ Pod CIDR, ծառայության CIDR, հանգույցի հասցեներ և VPN-ի հետևում գտնվող նպատակակետեր։ VPN-ի մասնավոր միջակայքերի և կլաստերի սեփական տարածքի համընկնումը հազվադեպ չէ, և լռելյայն երթուղին դրա համար սխալ լուծում է։ Երթուղային պլանը պետք է լինի նույն պահոցում, ինչ մանիֆեստը, որովհետև հաջորդ կլաստերը կարող է տալ բոլորովին այլ Pod և ծառայության միջակայքեր։

DNS-ը պլանի մասն է, ոչ առանձին անհանգստություն։ Sidecar-ը, որը վերագրում է լուծիչի կարգավորումը, կարող է կոտրել ծառայությունների հայտնաբերումը կլաստերի ներսում, մինչ արտաքին հարցումները կատարյալ աշխատում են։

Մեկնարկը և ձախողումը բացահայտ վիճակներ են

Աշխատող sidecar գործընթացը ելքի քաղաքականություն չէ։ Որոշեք, թե որ տրաֆիկը կարող է հոսել նախքան թունելի պատրաստ լինելը, և ինչ կլինի, եթե այն հետո մահանա, ապա իրականացրեք այդ որոշումը՝ զոնդ, որը դարպասում է հավելվածի կոնտեյները, ցանցային քաղաքականություն, որը լռելյայն մերժում է, կամ երկուսը միասին։ Դրանցից մեկի բացակայության դեպքում հավելվածը մեկնարկում է, լուծում է անունները և տրաֆիկը ուղարկում հանգույցի սովորական ուղով, մինչ թունելը դեռ միանում է։

Այդ բացը կարճ է առողջ կլաստերում և մշտական՝ կոտրվածում, և հենց այդ հատկությունն են նախընտրում հարձակվողը կամ պատահական տվյալների արտահոսքը։

Զուգակցեք հերթականությունը ձախողման թեստի հետ։ Սպանեք sidecar-ը և հաստատեք, որ հավելվածը կորցնում է իր նախատեսված ելքը, այլ ոչ թե լուռ հետ է ընկնում։

Հնարավորություններ, քաղաքականություններ և փորձարկում հավելվածի կոնտեյներից

Ինտերֆեյսներ ստեղծելու և երթուղիներ փոխելու համար անհրաժեշտ հնարավորություններ տալը արտոնության որոշում է, և մեկուսացված Pod-ի համար հարմար արտոնությունը ինքնաբերաբար հարմար չէ հանգույցի ստեկում։ Օգտագործեք կլաստերի աջակցած ցանցային և անվտանգության քաղաքականության մեխանիզմները և մի՛ ենթադրեք, որ յուրաքանչյուր CNI կամ քաղաքականության իրականացում VPN ինտերֆեյսին նույն կերպ է վերաբերվում. տարբերությունները երևում են հենց այն ձախողման դեպքերում, որոնք ձեզ համար կարևոր են։

Փորձարկեք իրական հավելվածի կոնտեյներից՝ նոր հարցումներով մասնավոր նպատակակետին, կլաստերի ծառայությանը և հանրային ինտերնետին։ Sidecar-ից արված թեստը ապացուցում է, որ թունելն աշխատում է, ոչ թե որ հավելվածը հասնում է իրեն անհրաժեշտին։

Փաստաթղթավորեք կլաստերի ցանցային ենթադրությունները VPN-ի կարգավորման կողքին։ Այդ դեպքում աշխատանքային բեռը այլ կլաստեր տեղափոխելը երթուղային պլանի ստուգման վարժություն է, այլ ոչ թե պատկերի փոփոխություն, որը լուռ դադարում է աշխատել։