Kubernetes klasterini fasiləsiz təkmilləşdirmək

Kubernetes klasteriniz üçün təkmilləşdirmə prosesi

Bir nöqtədə, bir Kubernetes klasterindən istifadə edərkən, işləyən qovşaqları yeniləməyə ehtiyac var. Bura paket yeniləmələri, nüvə yeniləmələri və ya yeni virtual maşın şəkillərinin yerləşdirilməsi daxil ola bilər. Kubernetes terminologiyasında buna deyilir "Könüllü pozulma".

Bu yazı 4 yazı seriyasının bir hissəsidir:

1. Bu yazı.
2. Kubernetes klasterində podların düzgün bağlanması
3. Pod silindikdə onun gecikdirilməsi
4. PodDisruptionBudgets-dan istifadə edərək Kubernetes Cluster-in işləməməsinin qarşısını necə almaq olar

(təqribən. Serialda qalan məqalələrin tərcüməsini yaxın gələcəkdə gözləyirik)

Bu yazıda biz Kubernetes-in klasterinizdə işləyən qovşaqlar üçün sıfır iş vaxtı əldə etmək üçün təmin etdiyi bütün vasitələri təsvir edəcəyik.

Problemi müəyyənləşdirin

Əvvəlcə sadəlövh bir yanaşma aparacağıq, problemləri müəyyən edəcəyik və bu yanaşmanın potensial risklərini qiymətləndirəcəyik və dövr ərzində qarşılaşdığımız problemlərin hər birini həll etmək üçün biliklər quracağıq. Nəticə, sıfır dayanma müddəti hədəfimizə çatmaq üçün həyat dövrü qarmaqlarından, hazırlıq zondlarından və Pod-un pozulması büdcələrindən istifadə edən konfiqurasiyadır.

Səyahətimizə başlamaq üçün konkret bir nümunə götürək. Deyək ki, bizdə iki qovşaqdan ibarət Kubernetes klasteri var, orada proqram arxada yerləşən iki pod ilə işləyir. Service:

İki Kubernetes klaster qovşağında işləyən Nginx və Service ilə iki poddan başlayaq.

Biz klasterimizdəki iki işçi qovşağının nüvə versiyasını yeniləmək istəyirik. Bunu necə edirik? Sadə bir həll, yenilənmiş konfiqurasiya ilə yeni qovşaqları yükləmək və sonra yeniləri işə salarkən köhnə qovşaqları bağlamaq olardı. Bu işləsə də, bu yanaşma ilə bağlı bir neçə problem olacaq:

• Köhnə qovşaqları söndürdüyünüz zaman, onların üzərində işləyən podlar da söndürüləcək. Zərif bağlanma üçün podların təmizlənməsi lazımdırsa nə etməli? İstifadə etdiyiniz virtuallaşdırma sistemi təmizləmə prosesinin tamamlanmasını gözləməyə bilər.
• Bütün qovşaqları eyni anda söndürsəniz nə olacaq? Podlar yeni qovşaqlara keçərkən layiqli dayanma vaxtı əldə edəcəksiniz.

Qovşaqları köhnə qovşaqlardan zərif şəkildə köçürmək üçün bir yola ehtiyacımız var, eyni zamanda qovşaqda dəyişiklik edərkən işçi proseslərimizin heç birinin işləməməsini təmin edirik. Və ya nümunədəki kimi klasterin tam dəyişdirilməsini etdikdə (yəni VM şəkillərini əvəz edirik) biz işləyən proqramları köhnə qovşaqlardan yenilərinə köçürmək istəyirik. Hər iki halda biz köhnə qovşaqlarda yeni podların planlaşdırılmasının qarşısını almaq və sonra bütün işləyən podları onlardan çıxarmaq istəyirik. Bu məqsədlərə çatmaq üçün əmrdən istifadə edə bilərik kubectl drain.

Bir qovşaqdan bütün podların yenidən paylanması

Drenaj əməliyyatı bir qovşaqdan bütün podları yenidən paylamağa imkan verir. Drenajın icrası zamanı qovşaq planlaşdırılmamış kimi qeyd olunur (bayraq NoSchedule). Bu, üzərində yeni podların görünməsinin qarşısını alır. Sonra drenaj qovşaqları qovşaqdan çıxarmağa başlayır, hazırda qovşaqda işləyən konteynerləri bağlayır, siqnal göndərir. TERM qabda qablar.

baxmayaraq ki kubectl drain podları çıxarmaq üçün əla iş görəcək, drenaj əməliyyatının uğursuzluğuna səbəb ola biləcək digər iki amil var:

• Müraciətiniz təqdim edildikdən sonra zərif şəkildə dayandırıla bilməlidir TERM siqnal. Podlar çıxarıldıqda, Kubernetes siqnal göndərir TERM konteynerləri saxlayır və onların müəyyən müddət ərzində dayanmasını gözləyir, bundan sonra, əgər dayanmayıbsa, onları məcburi şəkildə dayandırır. İstənilən halda, konteyneriniz siqnalı düzgün qəbul etmirsə, siz hələ də podları səhv söndürə bilərsiniz, əgər onlar hazırda işləyirsə (məsələn, verilənlər bazası əməliyyatı aparılır).
• Tətbiqinizi ehtiva edən bütün podları itirirsiniz. Yeni qovşaqlarda yeni konteynerlər işə salındıqda o, mövcud olmaya bilər və ya podlarınız nəzarətçilər olmadan yerləşdirilirsə, onlar ümumiyyətlə yenidən başlamaya bilər.

Boş vaxtların qarşısını almaq

Bir qovşaqda drenaj əməliyyatı kimi könüllü pozulmalardan yaranan fasilələri minimuma endirmək üçün Kubernetes aşağıdakı nasazlıqların aradan qaldırılması variantlarını təqdim edir:

• Zərif xitam
• Həyat dövrü qarmaqları
• PodDisruptionBudgets

Seriyanın qalan hissəsində pod miqrasiyasının təsirini azaltmaq üçün bu Kubernetes xüsusiyyətlərindən istifadə edəcəyik. Əsas fikrə əməl etməyi asanlaşdırmaq üçün yuxarıdakı nümunəmizi aşağıdakı resurs konfiqurasiyası ilə istifadə edəcəyik:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Bu konfiqurasiya minimal bir nümunədir Deployment, klasterdə nginx podlarını idarə edən. Bundan əlavə, konfiqurasiya resursu təsvir edir Service, bir çoxluqdakı nginx podlarına daxil olmaq üçün istifadə edilə bilər.

Bütün dövr ərzində biz bu konfiqurasiyanı təkrar-təkrar genişləndirəcəyik ki, o, nəhayət Kubernetes-in dayanma müddətini azaltmaq üçün təmin etdiyi bütün imkanları ehtiva etsin.

AWS və ondan kənarda sıfır fasilə üçün Kubernetes klaster yeniləmələrinin tam tətbiq edilmiş və sınaqdan keçirilmiş versiyası üçün buranı ziyarət edin Gruntwork.io.

Bloqumuzdakı digər məqalələri də oxuyun:

• Sıfır fasilə zamanı yerləşdirmə və verilənlər bazası
• Kubernetes: sistem resurslarının idarə edilməsini konfiqurasiya etmək niyə bu qədər vacibdir?
• Tekton Pipeline - Kubernetes-doğma boru kəmərləri
• Nginx üçün dinamik modulların qurulması
• Hashicorp Konsulunun Kubernetes Səlahiyyətinə giriş
• ClickHouse-dan icazəsiz icazəli ClickHouse-a köçmə nəyə gətirib çıxardı?

Mənbə: www.habr.com