🥇Kubernetesdəki canlılıq zondları təhlükəli ola bilər

Qeyd. tərcümə.: Zalandodan olan aparıcı mühəndis Henning Jacobs, Kubernetes istifadəçiləri arasında canlılıq (və hazırlıq) zondlarının məqsədini və onlardan düzgün istifadəni başa düşməkdə dəfələrlə problemlər müşahidə edib. Buna görə də, o, öz fikirlərini bu tutumlu qeyddə topladı, nəticədə K8s sənədlərinin bir hissəsi olacaq.

Sağlamlıq yoxlamaları, Kubernetesdə olaraq bilinir canlılıq zondları (yəni, sözün əsl mənasında, "həyata qabiliyyəti testləri" - təqribən tərcümə.), olduqca təhlükəli ola bilər. Mümkünsə, onlardan qaçmağı məsləhət görürəm: istisnalar həqiqətən zəruri olduqda və onlardan istifadənin xüsusiyyətlərini və nəticələrini tam bildiyiniz zamandır. Bu nəşr canlılıq və hazırlıq yoxlamaları haqqında danışacaq və hansı hallarda sizə məlumat verəcəkdir Qiymət və siz onlardan istifadə etməməlisiniz.

Həmkarım Sandor bu yaxınlarda Twitter-də qarşılaşdığı ən çox yayılmış səhvləri, o cümlədən hazırlıq/canlılıq zondlarının istifadəsi ilə bağlı səhvləri paylaşdı:

Yanlış konfiqurasiya edilib livenessProbe yüksək yüklə vəziyyətləri ağırlaşdıra bilər (qar yükünün bağlanması + potensial olaraq uzun konteyner/tətbiq işə salınma vaxtı) və asılılığın azalması kimi digər mənfi nəticələrə səbəb ola bilər. (həmçinin bax son məqaləm K3s+ACME birləşməsində sorğuların sayının məhdudlaşdırılması haqqında). Canlılıq zondu xarici verilənlər bazası olan sağlamlıq yoxlaması ilə birləşdirildikdə daha da pisdir: bir DB uğursuzluğu bütün konteynerlərinizi yenidən işə salacaq!

Ümumi mesaj "Canlılıq zondlarından istifadə etməyin" bu halda çox kömək etmir, ona görə də gəlin hazırlıq və canlılıq yoxlamalarının nə üçün olduğuna baxaq.

Qeyd: Aşağıdakı testlərin əksəriyyəti əvvəlcə Zalandonun daxili tərtibatçı sənədlərinə daxil edilmişdir.

Hazırlıq və Canlılıq yoxlanışı

Kubernetes adlı iki mühüm mexanizm təmin edir canlılıq zondları və hazırlıq zondları. Tətbiqin gözlənildiyi kimi işlədiyini təsdiqləmək üçün onlar vaxtaşırı bəzi hərəkətləri yerinə yetirirlər - məsələn, HTTP sorğusu göndərmək, TCP bağlantısını açmaq və ya konteynerdə əmr yerinə yetirmək.

Kubernetes istifadə edir hazırlıq zondlarıkonteynerin trafiki qəbul etməyə hazır olduğunu anlamaq üçün. Pod bütün qabları hazır olduqda istifadəyə hazır sayılır. Bu mexanizmdən bir istifadə Kubernetes xidmətləri (və xüsusilə Ingress) üçün hansı podların arxa uç kimi istifadə edildiyinə nəzarət etməkdir.

Canlılıq zondları Kubernetes-ə konteyneri yenidən işə salmağın vaxtının gəldiyini anlamağa kömək edin. Məsələn, belə bir yoxlama, bir proqram bir yerdə ilişib qaldıqda, kilidin qarşısını almağa imkan verir. Konteynerin bu vəziyyətdə yenidən işə salınması, səhvlərə baxmayaraq, tətbiqi yerdən çıxarmağa kömək edir, lakin bu, eyni zamanda sıralanan uğursuzluqlara səbəb ola bilər (aşağıya baxın).

Canlılıq/hazırlıq yoxlamalarından keçməyən tətbiq yeniləməsini yerləşdirməyə cəhd etsəniz, Kubernetes statusu gözlədiyi üçün onun yayımı dayandırılacaq. Ready bütün podlardan.

Misal

Budur, bir yolu yoxlayan hazırlıq zondunun nümunəsi /health standart parametrlərlə HTTP vasitəsilə (interval: 10 Saniyə, zaman aşımı: 1 saniyə, uğur həddi: 1, uğursuzluq həddi: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

tövsiyələr

HTTP son nöqtəsi olan mikroservislər üçün (REST və s.) həmişə bir hazırlıq zondu müəyyənləşdirin, tətbiqin (pod) trafiki qəbul etməyə hazır olub-olmadığını yoxlayır.
Hazırlıq zonduna əmin olun faktiki veb server portunun mövcudluğunu əhatə edir:
- "admin" və ya "idarəetmə" adlanan (məsələn, 9090) inzibati məqsədlər üçün portlardan istifadə etmək readinessProbe, əmin olun ki, son nöqtə yalnız əsas HTTP portu (məsələn, 8080) trafiki qəbul etməyə hazırdırsa, OK qaytarır*;
  *Zalandoda bunun baş vermədiyi ən azı bir hadisədən xəbərim var, yəni. readinessProbe "İdarəetmə" portunu yoxladım, amma serverin özü keşi yükləməkdə problemlərə görə işə başlamadı.
- hazırlıq zondunun ayrı bir porta qoşulması, əsas portun həddindən artıq yüklənməsinin sağlamlıq yoxlanışında əks olunmayacağına səbəb ola bilər (yəni serverdəki ip hovuzu doludur, lakin sağlamlıq yoxlaması hələ də hər şeyin qaydasında olduğunu göstərir. ).
Buna əmin olun Hazırlıq zondu verilənlər bazasının işə salınmasına/miqrasiyasına imkan verir;
- Buna nail olmağın ən asan yolu yalnız işə salma tamamlandıqdan sonra HTTP serveri ilə əlaqə saxlamaqdır (məsələn, verilənlər bazasını buradan köçürmək). Uçuş yolu və s.); yəni sağlamlıq yoxlanışı statusunu dəyişmək əvəzinə verilənlər bazası miqrasiyası tamamlanana qədər sadəcə veb serveri işə salmayın*.
  * Siz həmçinin verilənlər bazası miqrasiyasını poddan kənar başlanğıc konteynerlərindən icra edə bilərsiniz. Mən hələ də müstəqil proqramların, yəni tətbiq konteynerinin verilənlər bazasını xarici koordinasiya olmadan istədiyiniz vəziyyətə necə gətirəcəyini bildiyi proqramların pərəstişkarıyam.
İstifadə edin httpGet tipik sağlamlıq yoxlanış məntəqələri vasitəsilə hazırlığın yoxlanılması üçün (məsələn, /health).
Standart yoxlama parametrlərini anlayın (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- standart seçimlər podun olacağını bildirir hazır deyil təxminən 30 saniyədən sonra (3 uğursuz ağlı başında olma yoxlanışı).
Sağlamlıq və ölçü idarəetməsini adi trafikdən ayırmaq üçün texnologiya yığını (məsələn, Java/Spring) icazə verirsə, "admin" və ya "idarəetmə" üçün ayrıca portdan istifadə edin:
- lakin 2-ci bəndi unutma.
Lazım gələrsə, hazırlıq zondu keşi qızdırmaq/yükləmək və konteyner isinənə qədər 503 status kodunu qaytarmaq üçün istifadə edilə bilər:
- Mən də sizə yeni çeki oxumağı tövsiyə edirəm startupProbe, 1.16 versiyasında ortaya çıxdı (bu barədə rus dilində yazmışdıq burada - təqribən. tərcümə.).

Caveats

Xarici asılılıqlara etibar etməyin (məlumat anbarları kimi) hazırlıq/canlılıq testlərini həyata keçirərkən - bu, ardıcıl uğursuzluqlara səbəb ola bilər:
- Nümunə olaraq, bir Postgres verilənlər bazasından asılı olaraq 10 podlu dövlət REST xidmətini götürək: yoxlama DB ilə işləyən əlaqədən asılı olduqda, şəbəkə/DB tərəfində gecikmə olarsa, bütün 10 pod uğursuz ola bilər - adətən bu hər şey ola biləcəyindən daha pis başa çatır;
- Nəzərə alın ki, Spring Data standart olaraq verilənlər bazası bağlantısını yoxlayır*;
  * Bu, Spring Data Redis-in defolt davranışıdır (ən azı sonuncu dəfə yoxlamışdım), bu, "fəlakətli" uğursuzluğa səbəb oldu: Redis qısa müddət ərzində əlçatmaz olduqda, bütün podlar "çatıldı".
- Bu mənada "xarici" eyni tətbiqin digər podlarını da ifadə edə bilər, yəni kaskad qəzaların qarşısını almaq üçün ideal olaraq yoxlama eyni klasterin digər podlarının vəziyyətindən asılı olmamalıdır:
  - nəticələr paylanmış vəziyyətə malik tətbiqlər üçün fərqli ola bilər (məsələn, podlarda yaddaşdaxili keşləmə).
Canlılıq zondundan istifadə etməyin podlar üçün (istisnalar həqiqətən zəruri olduqda və onların istifadəsinin xüsusiyyətləri və nəticələrindən tam xəbərdar olduğunuz hallardır):
- Canlılıq zondu asılmış konteynerləri bərpa etməyə kömək edə bilər, lakin tətbiqinizə tam nəzarət etdiyiniz üçün asılmış proseslər və çıxılmaz vəziyyətlər kimi şeylər ideal olaraq baş verməməlidir: ən yaxşı alternativ tətbiqi qəsdən sındırmaq və onu əvvəlki sabit vəziyyətə qaytarmaqdır;
- uğursuz canlılıq zondu konteynerin yenidən işə salınmasına səbəb olacaq və bununla da yükləmə ilə bağlı xətaların təsirlərini potensial olaraq gücləndirəcək: konteynerin yenidən işə salınması fasilələrlə nəticələnəcək (ən azı proqramın işə salınması müddətində, deyək ki, 30-tək saniyə) yeni xətalara səbəb olacaq. , digər qablardakı yükün artırılması və onların sıradan çıxma ehtimalının artırılması və s.;
- Xarici asılılıqla birləşən canlılıq yoxlamaları mümkün olan ən pis kombinasiyadır və kaskad uğursuzluqları təhdid edir: verilənlər bazası tərəfində bir qədər gecikmə bütün konteynerlərinizin yenidən işə salınmasına səbəb olacaq!
Canlılıq və hazırlıq yoxlamalarının parametrləri fərqli olmalıdır:
- eyni sağlamlıq yoxlanışı ilə canlılıq zondundan istifadə edə bilərsiniz, lakin daha yüksək cavab həddi (failureThreshold), məsələn, status təyin edin hazır deyil 3 cəhddən sonra və hesab edin ki, canlılıq zondu 10 cəhddən sonra uğursuz olub;
İcra yoxlamalarından istifadə etməyin, çünki onlar zombi proseslərinin yaranmasına səbəb olan məlum problemlərlə əlaqələndirilir:
- təfərrüatlar: bax Datadog mütəxəssisləri tərəfindən təqdimat.

Xülasə

Bir podun trafiki qəbul etməyə nə vaxt hazır olduğunu müəyyən etmək üçün hazırlıq zondlarından istifadə edin.
Canlılıq zondlarından yalnız onlara həqiqətən ehtiyac olduqda istifadə edin.
Hazırlıq/canlılıq zondlarından düzgün istifadə edilməməsi əlçatanlığın azalmasına və ardıcıl uğursuzluqlara səbəb ola bilər.

Mövzu ilə əlaqədar əlavə materiallar

Kubernetes sənədləri: Canlılıq və Hazırlıq Zondlarını konfiqurasiya edin;
Kubernetes Canlılıq və Hazırlıq Problarına yenidən baxıldı: Başqa Ayağa Özünüzü Atmaqdan Necə Qaçmaq olar;
Ölümdən sonra NRE Laboratoriyalarının kəsilməsi (o da livenessProbe haqqında danışır).

1 tarixindən №2019 yeniləmə

Verilənlər bazası miqrasiyası üçün init konteynerləri haqqında: Haşiyə əlavə edildi.

EJ mənə xatırlatdı PDB haqqında: canlılığın yoxlanılması ilə bağlı problemlərdən biri podlar arasında koordinasiyanın olmamasıdır. Kubernetes var Pod pozulması büdcələri (PDB) tətbiqin qarşılaşa biləcəyi paralel uğursuzluqların sayını məhdudlaşdırmaq üçün, lakin yoxlamalar PDB-ni nəzərə almır. İdeal olaraq, biz K8-lərə deyə bilərik ki, "Sınaq uğursuz olarsa, bir podu yenidən başladın, lakin vəziyyəti daha da pisləşdirməmək üçün hamısını yenidən başlatmayın".

Bryan bunu mükəmməl ifadə etdi: “Dəqiq nə olduğunu bildiyiniz zaman canlılığı yoxlayın ediləcək ən yaxşı şey tətbiqi öldürməkdir"(Yenə də çaşmayın).

2 tarixindən №2019 yeniləmə

İstifadədən əvvəl sənədlərin oxunması ilə bağlı: Mən müvafiq sorğu yaratdım (xüsusiyyət istəyi) canlılıq zondları haqqında sənədlər əlavə etmək.

Tərcüməçidən PS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

Kubernetesdəki canlılıq zondları təhlükəli ola bilər