Kubernetes-də Pod VPN-i, yoxsa çıxış şlüzü: tunel kimə aiddir?

Adı vpn-gateway olan bir Pod yerləşdirirsiniz, test müştərisini onun ünvanına yönləndirirsiniz və paketlərin yox olduğunu görürsünüz. Manifestdə heç nə səhv deyil və kubelet-in heç bir şikayəti yoxdur. Səbəb konfiqurasiya deyil, struktur xarakterlidir: Kubernetes hər Pod-a öz şəbəkə ad məkanını verir, ona görə ad, etiket və ya ortaq API ad məkanı paketlərin hara getdiyini dəyişmir. Buna görə VPN trafikinin klasterdən necə çıxacağına qərar vermək konteyner imajları ilə deyil, sahiblik sualı ilə başlayır.

İki mexanizm real yerləşdirmələrin əksəriyyətini əhatə edir və onlar bir-birini əvəz etmir. Biri tuneli iş yükünün öz şəbəkə ad məkanına qoyur. Digəri CNI-dən seçilmiş trafiki təyin edilmiş şlüz düyünündən keçirməyi xahiş edir. Onlar fərqli şəkildə sıradan çıxır, fərqli miqyaslanır və fərqli komandalara tabedir, buna görə konteyner sualı adətən heç vaxt həll olunmayan mübahisələr doğurur.

Pod sərhədi ad məkanıdır, atlama hostu deyil

Linux şəbəkə ad məkanı öz interfeyslərinə, ünvanlarına, marşrutlarına və firewall qaydalarına sahibdir və hər Pod birini alır. O Pod-un içindəki konteynerlər ona qoşulur, buna görə köməkçi konteyner tətbiqin sonra izlədiyi marşrutları yenidən yaza bilir. Qonşu Pod eyni görünən, lakin tamamilə ayrı yığıma malikdir. Şlüz Pod-unun miras ala biləcəyi ortaq cədvəl və bir ad məkanından digərinə trafikin gizli ötürülməsi yoxdur.

Buna görə də şlüz-Pod nümunəsi yalnız yuxarıda nəsə paketləri həqiqətən ona göndərdikdə işləyir: bir Service, düyündə statik marşrut və ya CNI-də idarəetmə siyasəti. Tək ünvan heç nə cəlb etmir.

Hər Pod üçün tunel nə qazandırır və nəyə başa gəlir

İş yükünün ad məkanında işləyən tunel həmin iş yükünə öz müştəri identikliyini verir, bir çox uzaqdan giriş xidməti sessiyanı icazələndirməzdən və ya hesablaşmazdan əvvəl bunu tələb edir. Təsir radiusu da yerli qalır: pozulmuş tunel hər şeyin istifadə etdiyi ortaq yolun əvəzinə bir Deployment-i sıradan çıxarır. Onun necə işləməsi tətbiqdən asılıdır və insanlar məhz burada səhv təxmin edir.

Yalnız kernel vəziyyəti tələb edən quraşdırma init konteynerində bitib çıxa bilər. Pod-un ömrü boyu yaşamalı olan istifadəçi məkanı demonu Kubernetes 1.29-da yerli yan konteyner kimi təqdim edilmiş yenidən başladıla bilən init konteyner formasını tələb edir və bu fərq zövqdən deyil, tunelin tətbiqindən qaynaqlanır. Bu modelin qiyməti təkrarlanmadır: hər replika autentifikasiya edir, öz tunel ünvanını alır və uzaq sessiya yuvasını tutur, beləliklə avtomiqyaslama hadisəsi linkin o biri tərəfində tutum hadisəsinə çevrilir. Bir etimadnaməni bütün replikalara köçürmək bu qiyməti aradan qaldırmır, audit izini aradan qaldırır. İmkanlar da eyni diqqətə layiqdir, çünki öz ad məkanında NET_ADMIN istəyən tunelin privileged: true nümunəsinin host miqyaslı səlahiyyətini miras almağa heç bir səbəbi yoxdur.

CNI çıxışa sahib olduqda

Əgər CNI bunu dəstəkləyirsə, çıxış şlüzü trafiki iş yükünə və təyinat aralığına görə seçir, sonra onu seçilmiş düyünlərdən bir proqnozlaşdırıla bilən mənbə ünvanı altında göndərir. Cilium versiyası ümumi istinaddır və onun sənədləri açıq şəkildə bildirir ki, funksiya xüsusi Cilium konfiqurasiyası və düzgün interfeyslərlə, ünvanlarla təchiz edilmiş şlüz düyünləri tələb edir. O, həmçinin Pod yaradıldıqdan sonra idarəetmənin hələ tətbiq olunmadığı ilkin dövrü qeyd edir ki, bu da haşiyə deyil, dizayn girişidir.

Bu gecikməni öz vədinizlə tutuşdurun. Əgər qayda heç bir trafikin başqa yolla çıxmamasıdırsa, boşluq zamanı ötürən yeni Pod onu artıq pozub, buna görə başlanğıc ardıcıllığının öz cavabı olmalıdır: siyasət tətbiq olunana qədər tətbiqi saxla və ya pəncərəni qəbul et və sənədləşdir.

İddianı dar saxlayın. Çıxış şlüzü yolu seçir və çevirir. O, VPN-i sonlandırmır və arxasında dəstəklənən bağlantı olmadan klasteri uzaq şəbəkənizin müştərisinə çevirmir.

Tərcümə uzaq tərəfin gördüyünü sakitcə dəyişir

Şlüz mənbəni yenidən yazdıqdan sonra hər Pod-un ünvanı yox olur, beləliklə identikliyə bağlanmış icazə siyahısı bir ortaq ünvana bağlanmış siyahıya çevrilir. Bu qüsur deyil, mübadilədir: saxlanacaq daha az qayda, nəsə pis davrandıqda daha qaba atribusiya.

Tətbiq səviyyəsində autentifikasiya və sorğu qeydiyyatı şəbəkənin artıq bildirmədiyini daşımalıdır. Şlüz tutumuna və dəyişdirilməsinə ortaq infrastruktur kimi baxın, çünki bir düyünün yenidən başlaması indi arxasındakı hər iş yükünü kəsir, və qayıdış yolunu erkən yoxlayın: uzaq tərəf çevrilmiş ünvana necə çatacağını bilməlidir, adətən manifest deyil, insan tərəfindən idarə olunmalı marşrut və ya NAT vasitəsilə. Ünvan planlaşdırması da buraya aiddir, çünki üst-üstə düşən klaster və uzaq aralıqlar hər iki modeli pozur və IPv6-nın qəbulu ziddiyyətli planı əsaslandırmır.

Sahibliyə görə qərar verin, sonra vəd etdiyiniz nasazlığı sınayın

Hər Pod üçün tuneli o zaman seçin ki, uzaq xidmət fərdi iş yüklərini autentifikasiya edir, yalnız bir neçə Deployment linkə ehtiyac duyur və nasazlıq yerli qalmalıdır. Şlüzü o zaman seçin ki, şəbəkə komandası artıq yola sahibdir, çoxlu iş yükü bir təyinatı bölüşür və sabit mənbə ünvanı bütün məşqin məqsədidir.

Hər halda, sabit vəziyyəti deyil, satdığınız xassəni yoxlayın. Bir Pod yaradın, dərhal ötürməsinə icazə verin və vəd tuneldən heç nə qaçmaması idisə ilk saniyələri izləyin. Beş replikaya miqyaslayın və vəd hər iş yükü üçün identiklik idisə uzaq tərəfin bildirdiyi sessiyaları sayın. Bu iki yoxlama mexanizmin hüdudlarını manifestin nəzərdən keçirilməsindən qat-qat tez üzə çıxarır və növbəti insidentin hansı komandaya aid olduğunu deyir.