Kubernetes-ի Pod-VPN-ը և ելքի դարպասը. ով է տիրում թունելին

Դուք տեղադրում եք vpn-gateway անունով Pod, ուղղորդում եք փորձնական հաճախորդին նրա հասցեին և տեսնում, թե ինչպես փաթեթները անհետանում են։ Մանիֆեստում ոչինչ սխալ չէ, և kubelet-ը բողոք չունի։ Պատճառը կառուցվածքային է, ոչ կարգավորման: Kubernetes-ը յուրաքանչյուր Pod-ի տալիս է իր ցանցային անվանատարածքը, ուստի անունը, պիտակը կամ ընդհանուր API անվանատարածքը ոչինչ չեն փոխում փաթեթների ուղղության մեջ։ Ուստի VPN երթևեկության կլաստերից դուրս գալու որոշումը սկսվում է սեփականության հարցով, ոչ կոնտեյներային պատկերների հարցով։

Երկու մեխանիզմ ծածկում են իրական տեղադրումների մեծ մասը, և դրանք փոխարինելի չեն։ Մեկը թունելը դնում է աշխատանքային բեռի սեփական ցանցային անվանատարածքի ներսում։ Մյուսը CNI-ից խնդրում է ընտրված երթևեկն անցկացնել նշանակված դարպասային հանգույցով։ Նրանք տարբեր կերպ են ձախողվում, տարբեր կերպ են մասշտաբվում և պատասխանատու են տարբեր թիմերի առաջ, ինչի պատճառով կոնտեյներային հարցը սովորաբար առաջացնում է վեճեր, որոնք երբեք չեն լուծվում։

Pod-ի սահմանը անվանատարածք է, ոչ թռիչքային հոսթ

Linux ցանցային անվանատարածքը տիրում է իր ինտերֆեյսներին, հասցեներին, երթուղիներին և firewall-ի կանոններին, և յուրաքանչյուր Pod ստանում է մեկը։ Այդ Pod-ի ներսի կոնտեյներները միանում են դրան, և հենց դրա համար օժանդակ կոնտեյները կարող է վերագրել երթուղիներ, որոնց հետո հետևում է հավելվածը։ Հարևան Pod-ն ունի նույն տեսքը, բայց լիովին առանձին կույտ։ Չկա ընդհանուր աղյուսակ, որը դարպաս-Pod-ը կարող է ժառանգել, և չկա երթևեկության անուղղակի փոխանցում մի անվանատարածքից մյուսը։

Այդ պատճառով դարպաս-Pod օրինակը աշխատում է միայն այն ժամանակ, երբ վերևում ինչ-որ բան իրոք փաթեթներ է ուղարկում դրան՝ Service, հանգույցի ստատիկ երթուղի կամ CNI-ի ուղղորդման քաղաքականություն։ Միայն հասցեն ոչինչ չի գրավում։

Ինչ է տալիս թունելը յուրաքանչյուր Pod-ի համար և ինչ արժե

Աշխատանքային բեռի անվանատարածքում աշխատող թունելը տալիս է այդ բեռին իր սեփական հաճախորդի ինքնությունը, որը հեռավոր մուտքի շատ ծառայություններ պահանջում են նստաշրջանը թույլատրելուց կամ հաշվառելուց առաջ։ Վնասի շառավիղը նույնպես մնում է տեղային: կոտրված թունելը դուրս է հանում մեկ Deployment-ը՝ բոլորի օգտագործած ընդհանուր ուղու փոխարեն։ Ինչպես է այն աշխատում, կախված է իրականացումից, և հենց այստեղ են մարդիկ սխալ գուշակում։

Կարգավորումը, որին միայն միջուկի վիճակ է պետք, կարող է ավարտվել init կոնտեյներում և դուրս գալ։ Օգտագործողի տարածության դեմոնը, որը պետք է կենդանի մնա Pod-ի ողջ կյանքի ընթացքում, կարիք ունի վերսկսվող init կոնտեյների ձևի, որը որպես ներկառուցված sidecar ներկայացվել է Kubernetes 1.29-ում, և այդ տարբերությունը գալիս է թունելի իրականացումից, ոչ ճաշակից։ Այս մոդելի գինը կրկնօրինակումն է: յուրաքանչյուր կրկնօրինակ նույնականացվում է, ստանում իր թունելի հասցեն և զբաղեցնում հեռավոր նստաշրջանի տեղ, ուստի ավտոմասշտաբավորման իրադարձությունը դառնում է կարողության իրադարձություն կապի մյուս կողմում։ Մեկ հավատարմագրի պատճենումը բոլոր կրկնօրինակներում չի վերացնում այդ գինը, այն վերացնում է աուդիտի հետքը։ Իրավունքները նույն ստուգման կարիքն ունեն, քանի որ թունելը, որը ցանկանում է NET_ADMIN իր սեփական անվանատարածքում, պատճառ չունի ժառանգելու ամբողջ հոսթի իշխանությունը privileged: true օրինակից։

Երբ CNI-ն է տիրում ելքին

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

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

Պահեք պնդումը նեղ։ Ելքի դարպասը ընտրում և թարգմանում է ուղի։ Այն չի ավարտում VPN-ը և կլաստերը չի դարձնում ձեր հեռավոր ցանցի հաճախորդ առանց դրա հետևում աջակցվող կապի։

Թարգմանությունը լուռ փոխում է այն, ինչ տեսնում է հեռավոր կողմը

Հենց դարպասը վերագրում է աղբյուրը, յուրաքանչյուր Pod-ի հասցեները անհետանում են, ուստի ինքնության վրա հիմնված թույլատրելի ցանկը դառնում է մեկ ընդհանուր հասցեի վրա հիմնված ցանկ։ Սա փոխանակում է, ոչ թերություն: ավելի քիչ կանոններ պահպանելու համար, ավելի կոպիտ վերագրում, երբ ինչ-որ բան վատ է վարվում։

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

Որոշեք ըստ սեփականության, ապա փորձարկեք խոստացված ձախողումը

Ընտրեք թունելը յուրաքանչյուր Pod-ի համար, երբ հեռավոր ծառայությունը նույնականացնում է առանձին աշխատանքային բեռներ, երբ կապը պետք է միայն մի քանի Deployment-ի, և երբ ձախողումը պետք է մնա տեղային։ Ընտրեք դարպասը, երբ ցանցային թիմն արդեն տիրում է ուղուն, երբ շատ բեռներ կիսում են մեկ նպատակակետ, և երբ կայուն աղբյուրի հասցեն ամբողջ վարժության իմաստն է։

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