Kubernetes Pod-u daxilində VPN sidecar yaxşı davranışlı host səviyyəli VPN-ə bənzəyir və bu oxşarlıq ad məkanı sərhədində bitir. Bir Pod daxilindəki konteynerlər ünvan və port fəzası daxil olmaqla şəbəkə ad məkanını paylaşır, buna görə marşrutlar və siyasətlər quraşdıran sidecar tətbiqin paketlərinin hara getdiyini həqiqətən dəyişir. Digər Pod-lar üçün heç nəyi dəyişmir və konfiqurasiya etməsəniz, düyünün öz yığınına toxunmur. Bu sərhədi düzgün qurmaq həm nəyi yerləşdirə biləcəyinizi, həm də nəyi sınaqdan keçirməli olduğunuzu müəyyən edir. Aşağıdakı bölmələr bunu ad məkanından xaricə doğru izləyir.

Paylaşılan ad məkanı, paylaşılan nəticələr

Bir Pod daxilində iki konteyner loopback üzərindən danışır və eyni interfeysləri görür, sidecar nümunəsinin ümumiyyətlə işləməsinin səbəbi budur: tətbiqin tunelin varlığını bilməsinə ehtiyac yoxdur, çünki həll etdiyi marşrut istifadə etdiyi ad məkanında quraşdırılıb. Eyni xassə o deməkdir ki, sidecar-ın səhvləri tətbiqin səhvləridir. Həddindən artıq çox şeyi tutan marşrut və ya tunel daxilindəki həll ediciyə yönələn DNS dəyişikliyi həmin Pod-dakı hər prosesə dərhal tətbiq olunur. Paylaşılan ad məkanında konteyner üzrə marşrutlaşdırma yoxdur, buna görə sidecar bir proseslə məhdudlaşdırıla bilməz.

İcmal zamanı yadda saxlamalı mexanizm budur: təsir radiusu Pod-dur, düyün deyil və klaster deyil.

Sidecar-ın çatmadığı yerlər

Digər Pod-lar öz ad məkanlarını və öz marşrutlaşdırmalarını saxlayır, buna görə eyni çıxışa ehtiyacı olan iş yükü eyni sidecar-a, yaxud düyün səviyyəli dizayna ehtiyac duyur. Düyünün trafiki də Pod ad məkanından kənardadır və host şəbəkəli Pod-lar bu təcriddən tamamilə qəsdən imtina edir. Əlverişli bir şeyə çatmaq üçün sidecar-ı host şəbəkəsi ilə işlədirsinizsə, əhatəni bir Pod-dan bütün düyünə genişlətmişsiniz və bunu açıq deməlisiniz.

Klaster xidmətlərinin trafiki digər ümumi sürprizdir. Pod daxilindəki geniş default marşrut API serverinə və ya ClusterIP xidmətinə nəzərdə tutulan sorğuları tuta bilər və onlar sonra tunelin pozulduğunu xatırladan şəkildə uğursuz olur.

Marşrut planı: Pod, xidmət, düyün və VPN diapazonları

Dörd diapazonu yazın və hər hansı bir şeyi yerləşdirməzdən əvvəl onları üst-üstə düşmə baxımından yoxlayın: Pod CIDR, xidmət CIDR, düyün ünvanları və VPN-in arxasındakı təyinatlar. VPN-in özəl diapazonları ilə klasterin öz fəzası arasında üst-üstə düşmə nadir deyil və bunun üçün default marşrut yanlış həlldir. Marşrut planı manifestlə eyni repozitoriyada olmalıdır, çünki növbəti klaster tamamilə başqa Pod və xidmət diapazonları verə bilər.

DNS planın bir hissəsidir, ayrı bir narahatlıq deyil. Həll edici konfiqurasiyasını yenidən yazan sidecar klaster daxilində xidmət kəşfini poza bilər, halbuki xarici sorğular mükəmməl işləyir.

Başlanğıc və uğursuzluq açıq vəziyyətlərdir

İşləyən sidecar prosesi çıxış siyasəti deyil. Tunel hazır olmadan hansı trafikin axa biləcəyini və sonradan ölsə nə olacağını qərarlaşdırın, sonra bu qərarı tətbiq edin: tətbiq konteynerini qapıdan keçirən zond, standart olaraq rədd edən şəbəkə siyasəti və ya hər ikisi. Bunlardan biri olmadan tətbiq başlayır, adları həll edir və tunel hələ qoşularkən trafiki düyünün normal yolundan göndərir.

Bu boşluq sağlam klasterdə qısa, pozulmuş klasterdə isə daimidir və bu, hücumçunun və ya təsadüfi məlumat sızmasının üstünlük verdiyi xassədir.

Sıralamanı uğursuzluq testi ilə birləşdirin. Sidecar-ı öldürün və tətbiqin səssizcə geri çəkilmək əvəzinə nəzərdə tutulan çıxışını itirdiyini təsdiqləyin.

İmkanlar, siyasətlər və tətbiq konteynerindən test

İnterfeyslər yaratmaq və marşrutları dəyişmək üçün lazım olan imkanları vermək imtiyaz qərarıdır və təcrid olunmuş Pod üçün uyğun imtiyaz avtomatik olaraq düyün yığınında uyğun deyil. Klasterin dəstəklədiyi şəbəkə və təhlükəsizlik siyasəti mexanizmlərindən istifadə edin və hər CNI və ya siyasət tətbiqinin VPN interfeysinə eyni cür yanaşdığını güman etməyin; fərqlər məhz sizi maraqlandıran uğursuzluq hallarında üzə çıxır.

Real tətbiq konteynerindən, özəl təyinat, klaster xidməti və açıq internetə təzə sorğularla test edin. Sidecar-dan edilən test tunelin işlədiyini sübut edir, tətbiqin lazım olan şeyə çata bildiyini yox.

Klaster şəbəkə fərziyyələrini VPN konfiqurasiyasının yanında sənədləşdirin. Onda iş yükünü başqa klasterə köçürmək səssizcə işləməyi dayandıran obraz dəyişikliyi deyil, marşrut planını yoxlamaq məşqi olur.

Əlaqəli məqalələr