Kubernetes əsasları

Konteyner prosesi və onun asılılıqlarını paketləyir. Lakin üç nüsxənin harada işləyəcəyini seçmir və maşın sıradan çıxanda itirilən nüsxəni özü əvəz etmir. Bunu əl ilə idarə etmək maşınları təkrar yoxlamaq, prosesləri işə salmaq və dəyişiklikləri əlaqələndirmək deməkdir.

Kubernetes hədəfi təsvir etməyə imkan verir və təkrarlanan qərarları birlikdə işləyən komponentlərə həvalə edir. Klaster birlikdə idarə olunan, node adlanan maşınlar qrupudur. Nümunəmiz kiçik, vəziyyət saxlamayan veb tətbiqidir: hər replika öz lokal sessiya məlumatına ehtiyac duymadan sorğuya cavab verə bilir.

API obyekti sistemdə saxlanan qeyddir. Məsələn, foundations-web adlı Deployment belə bir obyektdir. Onun spec hissəsi tələb olunan konfiqurasiyanı təsvir edir. Bu Deployment üçün spec.replicas: 3 üç nüsxə tələb edir. status isə Kubernetes komponentlərinin müşahidələrini, o cümlədən nüsxə saylarını və gedişat barədə vəziyyət şərtlərini göstərir.

spec yeniləndikdə hədəf dəyişir, faktiki vəziyyət isə dərhal dəyişməyə bilər. status da hadisələrdən bir qədər geri qala bilər. Buna görə aradakı fərq araşdırılmalıdır, lakin təkbaşına nasazlığı sübut etmir. Manifest obyektləri təsvir edən fayldır. kubectl sənin adından Kubernetes API-sinə sorğular göndərir.

İdarəetmə müstəvisi (control plane) klasterin işini əlaqələndirir. İşçi node-lar tətbiqin konteynerləri üçün icra mühiti təmin edir. Bunlar ayrı rollardır; kiçik tədris klasterində hər ikisi eyni maşında yerləşə bilər.

Pod Kubernetes-in node-a təyin etdiyi vahiddir: şəbəkəni və lazım gəldikdə saxlama resurslarını paylaşan bir və ya bir neçə əlaqəli konteynerdən ibarətdir. Nümunə tətbiqimizdə hər Pod bir konteyner işlədir.

Deployment tətbiqin versiyalarının yayımını ReplicaSet-lər vasitəsilə idarə edir. ReplicaSet tələb olunan sayda aktiv Pod saxlayır: bunlar işi başa çatmamış və silinmə prosesində olmayan Pod-lardır. Aktiv olmaq hazır olmaq demək deyil. Sadə, sabit vəziyyətdə Deployment bir aktiv ReplicaSet-i, həmin ReplicaSet isə üç Pod-u idarə edir. Yenilənmə zamanı bir neçə ReplicaSet prosesdə iştirak edə bilər.

ownerReferences sahəsi bu sahiblik əlaqəsini qeydə alır: Deployment → ReplicaSet → Pod.

Arxitekturadakı “Pod yarat” ssenarisinə başlamazdan əvvəl düşün: API Deployment-i qəbul edən kimi hansı obyektlər mövcuddur? Pod obyektini hansı komponent yaradır, node-u hansı seçir, konteyneri hansı başladır? Addımlarla irəliləyərək cavablarını yoxla.

Yaradılmış Pod API-də mövcuddur. Node-a təyin olunmuş Pod-un işləyəcəyi maşın seçilib. Pending mərhələsi həm node seçimini, həm də konteynerin hazırlanmasını gözləməyi əhatə edə bilər. Buna görə təkcə Pending səbəbi göstərmir.

Running həyat dövrünün mərhələsidir, tətbiqin sağlamlığına zəmanət deyil. Ready isə trafik qəbul etməyə hazırlığı göstərən şərtdir. Readiness probe tətbiqə məxsus endpoint-i yoxlaya bilər; proses işləsə də, bu yoxlama uğursuz ola bilər. Məqsədəuyğun hazırlıq yoxlaması olmadıqda Ready gözlədiyindən daha az məlumat verə bilər.

Adi Service üçün hazır olmayan Pod-lara normal tətbiq trafiki yönləndirilmir. Hazırlıq vəziyyəti və şəbəkə əlçatanlığı yenə də bütün biznes əməliyyatlarının düzgün işlədiyini sübut etmir.

Uzlaşdırma (reconciliation) vəziyyəti müşahidə edib lazım gəldikdə onu yenidən hədəfə yaxınlaşdırmaqdır. Konteyner dayandıqda kubelet restart siyasətinə uyğun olaraq eyni Pod daxilində konteyneri yenidən başlada bilər. İdarə olunan Pod silindikdə isə kontroller yeni unikal identifikatoru (UID) olan başqa Pod yarada bilər.

Pod bütöv şəkildə başqa node-a köçmür. Onu əvəz edən Pod yeni obyektdir və node-a təyin olunub başladılmalıdır. Node nasazlığının aşkarlanması və təsirlənən tətbiq nüsxələrinin əvəzlənməsi vaxt aparır. Siyasətlər və mövcud resurslar bərpaya təsir edir.

Kontrollerlər əlavə CPU resursunu yoxdan yarada, səhv image ünvanını düzəldə və ya tətbiq kodundakı xətanı aradan qaldıra bilməz. Əsas məhdudiyyəti həll edənədək təkrar cəhdlər nəticəsiz qala bilər.

Tutaq ki, ReplicaSet-in üç aktiv Pod-u var, lakin uyğun node-larda yalnız ikisi üçün yer çatır. İkisi hazır vəziyyətə keçə, üçüncüsü isə node-a təyin olunmadan Pending qala bilər. İstənilən say üç, aktiv Pod sayı üç, hazır Pod sayı isə ikidir.

Bir Pod hazır deyil deyə ReplicaSet əlavə Pod-lar yaratmağa davam etmir. Problem yerləşdirmə mərhələsindədir. Scheduler təkcə maşının hazırda boş olan CPU-sunu deyil, tələb olunan resursları və yerləşdirmə məhdudiyyətlərini nəzərə alır.

Hədəflə müşahidə arasındakı fərqdən başla. Üç nüsxə tələb edilibsə, əvvəl üç Pod obyektinin mövcudluğunu, sonra node-a təyin olunmasını və konteynerlərin hazırlığını yoxla. Hər cavab araşdırmanın istiqamətini daraldır.

• Pod sayı tələbdən azdırsa, Deployment və ReplicaSet şərtlərində və hadisələrində yaradılma xətalarını, məsələn, kvota məhdudiyyətlərini araşdır.
• Pod mövcuddur, amma node-u yoxdursa, yerləşdirmə hadisələrini, resurs tələblərini və yerləşdirmə qaydalarını yoxla.
• Pod-un node-u var, amma konteynerlər başlamayıbsa, gözləmə səbəblərini və hadisələri yoxlayaraq image, saxlama və ya hazırlıq problemlərini araşdır.
• Konteyner başlayır, amma təkrar başladılır və ya hazır olmursa, onun vəziyyətini, restart tarixçəsini, tətbiq loglarını və probe konfiqurasiyasını araşdır.

Komandaya bir neçə maşın və xidmət üzrə ardıcıl yerləşdirmə, idarə olunan versiya yayımı və bərpa lazımdırsa, Kubernetes faydalı ola bilər. Bununla yanaşı giriş icazələri, şəbəkə, yeniləmələr, monitorinq, resurslar və tətbiqlərin özü üçün məsuliyyət də qalır.

Kiçik bir xidməti virtual maşında, idarə olunan tətbiq platformasında və ya idarə olunan konteyner xidmətində işlətmək daha sadə ola bilər. Lokal inkişaf mühiti üçün konteynerləri birlikdə başladan alət kifayət edə bilər. Seçimi real əlçatanlıq, yayım, miqyaslama və komanda tələblərinə əsaslandır.