Paylanmış sistemləri idarə etmək çətin ola bilər, çünki onlar sistemin işləməsi üçün hamısının düzgün işləməsi lazım olan çoxlu hərəkət edən, dəyişən elementlərə malikdir. Elementlərdən biri uğursuz olarsa, sistem onu aşkar etməli, yan keçməli və düzəltməlidir və bütün bunlar avtomatik olaraq həyata keçirilməlidir. Bu Kubernetes Ən Yaxşı Təcrübələr seriyasında biz Kubernetes klasterinin sağlamlığını yoxlamaq üçün Hazırlıq və Canlılıq testlərini necə qurmağı öyrənəcəyik.
Sağlamlıq Yoxlanışı sistemə tətbiq nümunənizin işlək olub-olmadığını bildirməyin sadə yoludur. Tətbiq nümunəniz işləmirsə, digər xidmətlər ona daxil olmamalı və ona sorğu göndərməməlidir. Bunun əvəzinə sorğu artıq işləyən və ya daha sonra işə salınacaq tətbiqin başqa nümunəsinə göndərilməlidir. Bundan əlavə, sistem tətbiqinizin itirilmiş funksionallığını bərpa etməlidir.
Defolt olaraq, Kubernetes qovşaqlardakı bütün konteynerlər işləyərkən poda trafik göndərməyə başlayacaq və konteynerlər qəzaya uğradıqda onları yenidən işə salacaq. Bu defolt sistem davranışı başlamaq üçün kifayət qədər yaxşı ola bilər, lakin siz fərdi ağlı başında olma yoxlamalarından istifadə etməklə məhsulunuzun yerləşdirilməsinin etibarlılığını artıra bilərsiniz.
Xoşbəxtlikdən, Kubernetes bunu olduqca asanlaşdırır, buna görə də bu yoxlamalara məhəl qoymamaq üçün heç bir bəhanə yoxdur. Kubernetes iki növ Sağlamlıq Yoxlanışı təqdim edir və hər birinin necə istifadə olunduğundakı fərqləri anlamaq vacibdir.
Hazırlıq testi Kubernetes-ə tətbiqinizin trafiki idarə etməyə hazır olduğunu bildirmək üçün nəzərdə tutulub. Xidmətin poda trafik göndərməsinə icazə verməzdən əvvəl Kubernetes hazırlıq yoxlamasının uğurlu olduğunu yoxlamalıdır. Hazırlıq testi uğursuz olarsa, Kubernetes sınaqdan keçənə qədər poda trafik göndərməyi dayandıracaq.
Canlılıq testi Kubernetes-ə müraciətinizin diri və ya ölü olduğunu bildirir. Birinci halda, Kubernetes onu tək qoyacaq, ikincidə ölü podu silib yenisi ilə əvəz edəcək.
Tətbiqinizin istiləşməsi və işə salınması 1 dəqiqə çəkdiyi bir ssenari təsəvvür edək. Tətbiq tam yüklənənə və işə başlayana qədər xidmətiniz işə başlamayacaq, baxmayaraq ki, iş prosesi artıq başlamışdır. Bu yerləşdirməni bir neçə nüsxəyə genişləndirmək istəsəniz, probleminiz də olacaq, çünki həmin nüsxələr tam hazır olana qədər trafik qəbul etməməlidir. Bununla belə, standart olaraq, Kubernetes konteyner daxilində proseslər başlayan kimi trafik göndərməyə başlayacaq.
Hazırlıq testindən istifadə edərkən, Kubernetes xidmətin yeni nüsxəyə trafik göndərməsinə icazə verməzdən əvvəl tətbiqin tam işləməsini gözləyəcək.
Tətbiqin uzun müddət dayandığı, sorğulara xidmət göstərməsini dayandırdığı başqa bir ssenarini təsəvvür edək. Proses davam etdikcə, defolt olaraq Kubernetes hər şeyin qaydasında olduğunu güman edəcək və işləməyən pod-a sorğu göndərməyə davam edəcək. Lakin Liveness istifadə edərkən, Kubernetes tətbiqin artıq sorğulara xidmət etmədiyini aşkar edəcək və standart olaraq ölü podu yenidən işə salacaq.
Hazırlıq və həyat qabiliyyətinin necə yoxlanıldığına baxaq. Üç sınaq üsulu var - HTTP, Əmr və TCP. Yoxlamaq üçün onlardan hər hansı birini istifadə edə bilərsiniz. İstifadəçini sınamağın ən çox yayılmış yolu HTTP probudur.
Tətbiqiniz HTTP serveri olmasa belə, Canlılıq testi ilə qarşılıqlı əlaqədə olmaq üçün tətbiqinizdə hələ də yüngül HTTP server yarada bilərsiniz. Bundan sonra Kubernetes podda ping atmağa başlayacaq və HTTP cavabı 200 və ya 300 ms diapazonunda olarsa, bu podun sağlam olduğunu göstərəcək. Əks halda, modul "sağlam deyil" kimi qeyd olunacaq.
Komanda testləri üçün Kubernetes konteynerinizin daxilində əmri icra edir. Əgər əmr sıfır çıxış kodu ilə qayıdırsa, o zaman konteyner sağlam kimi qeyd olunacaq, əks halda 1-dən 255-ə qədər çıxış statusu nömrəsi alındıqdan sonra konteyner “xəstə” kimi qeyd olunacaq. HTTP serverini işlədə bilmirsinizsə və ya istəmirsinizsə, lakin tətbiqinizin sağlamlığını yoxlayacaq bir əmr işlədə bilirsinizsə, bu test üsulu faydalıdır.
Son yoxlama mexanizmi TCP testidir. Kubernetes göstərilən portda TCP bağlantısı qurmağa çalışacaq. Əgər bu mümkün olarsa, qab sağlam, yoxsa, yararsız sayılır. HTTP sorğusu və ya əmr icrası ilə testin yaxşı işləmədiyi bir ssenaridən istifadə edirsinizsə, bu üsul faydalı ola bilər. Məsələn, TCP istifadə edərək yoxlama üçün əsas xidmətlər gRPC və ya FTP olacaqdır.
Testlər müxtəlif parametrlərlə bir neçə yolla konfiqurasiya edilə bilər. Onların nə qədər tez-tez yerinə yetirilməli olduğunu, uğur və uğursuzluq həddinin nə olduğunu və cavabları nə qədər gözləyəcəyini təyin edə bilərsiniz. Əlavə məlumat üçün Hazırlıq və Canlılıq testləri üçün sənədlərə baxın. Bununla belə, Canlılıq testinin qurulmasında çox vacib bir məqam var - sınaq gecikməsinin ilkin parametrləri initialDelaySeconds. Qeyd etdiyim kimi, bu testin uğursuzluğu modulun yenidən işə salınması ilə nəticələnəcək. Beləliklə, əmin olmalısınız ki, proqram işə hazır olana qədər sınaq başlamaz, əks halda yenidən işə salınma yolu ilə velosiped sürməyə başlayacaq. Mən P99 başlanğıc vaxtını və ya buferdən tətbiqin orta başlanğıc vaxtını istifadə etməyi tövsiyə edirəm. Tətbiqinizin başlama vaxtı daha sürətli və ya yavaşlaşdıqca bu dəyəri tənzimləməyi unutmayın.
Əksər ekspertlər təsdiq edəcək ki, Sağlamlıq Yoxlamaları hər hansı bir paylanmış sistem üçün məcburi yoxlamadır və Kubernetes də istisna deyil. Xidmət sağlamlığı yoxlamalarından istifadə Kubernetes-in etibarlı, problemsiz işləməsini təmin edir və istifadəçilər üçün heç bir çətinlik yaratmır.
Tezliklə davamı olacaq...
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com