🥇Кубернетес дэх амьд мэдрэгч нь аюултай байж болно

Анхаарна уу. орчуулга.: Заландогийн ахлах инженер Хеннинг Жейкобс Кубернетес хэрэглэгчдийн дунд амьд (болон бэлэн байдлын) датчикуудын зорилго, тэдгээрийн зөв ашиглалтыг ойлгоход бэрхшээлтэй байгааг олон удаа анзаарсан. Тиймээс тэрээр өөрийн бодлоо энэхүү багтаамжтай тэмдэглэлд цуглуулсан бөгөөд энэ нь эцэстээ K8s-ийн баримт бичгийн нэг хэсэг болох болно.

Кубернетес гэж нэрлэгддэг эрүүл мэндийн үзлэг амьд байдлын мэдрэгч (өөрөөр хэлбэл "амьдрах чадварын тест" - ойролцоогоор орчуулга), нэлээд аюултай байж болно. Боломжтой бол эдгээрээс зайлсхийхийг зөвлөж байна: цорын ганц үл хамаарах зүйл бол тэдгээр нь үнэхээр шаардлагатай бөгөөд та тэдгээрийн ашиглалтын онцлог, үр дагаврыг бүрэн мэддэг байх явдал юм. Энэхүү нийтлэл нь амьд байдал, бэлэн байдлын шалгалтын талаар ярих бөгөөд ямар тохиолдолд танд хэлэх болно үнэ цэнэтэй юм мөн та тэдгээрийг ашиглах ёсгүй.

Миний хамтран зүтгэгч Сандор саяхан Твиттер хуудсандаа бэлэн байдал/амьдралын хэмжүүр ашиглахтай холбоотой хамгийн нийтлэг алдаануудаа хуваалцжээ.

Буруу тохируулсан livenessProbe Энэ нь ачаалал ихтэй нөхцөл байдлыг улам хүндрүүлж (цасан бөмбөлөг унтрах + магадгүй урт контейнер/програмыг эхлүүлэх хугацаа) болон хараат байдал буурах зэрэг бусад сөрөг үр дагаварт хүргэж болзошгүй. (мөн үзнэ үү миний саяхны нийтлэл K3s+ACME хослол дахь хүсэлтийн тоог хязгаарлах тухай). Амьдрах датчикийг гадаад мэдээллийн сан болох эрүүл мэндийн үзлэгтэй хослуулах нь бүр ч муу юм. нэг DB алдаа нь таны бүх контейнерийг дахин эхлүүлэх болно!

Ерөнхий мессеж "Амьдрах мэдрэгчийг бүү ашигла" Энэ тохиолдолд энэ нь тийм ч их тус болохгүй тул бэлэн байдал, амьдрах чадварыг шалгах нь юунд зориулагдсан болохыг харцгаая.

Тайлбар: Доорх туршилтын ихэнхийг анх Zalando-ийн дотоод хөгжүүлэгчийн баримт бичигт оруулсан болно.

Бэлэн байдал, амьд байдлыг шалгах

Kubernetes гэж нэрлэгддэг хоёр чухал механизмыг өгдөг амьд байдлын мэдрэгч ба бэлэн байдлын мэдрэгч. Тэд үе үе HTTP хүсэлт илгээх, TCP холболт нээх, эсвэл саванд командыг гүйцэтгэх гэх мэт зарим үйлдлийг хийж, програм нь хүлээгдэж буйгаар ажиллаж байгааг баталгаажуулдаг.

Kubernetes ашигладаг бэлэн байдлын шалгалтуудчингэлэг ачааллыг хүлээн авахад бэлэн болсныг ойлгох. Бүх савнууд нь бэлэн болсон бол савыг хэрэглэхэд бэлэн гэж үзнэ. Энэхүү механизмын нэг хэрэглээ нь Kubernetes үйлчилгээнд (ялангуяа Ingress) ямар подкуудыг арын хэсэг болгон ашиглаж байгааг хянах явдал юм.

Амьдрах мэдрэгч Кубернетесэд савыг дахин эхлүүлэх цаг болсныг ойлгоход тусална уу. Жишээлбэл, ийм шалгалт нь програм нэг газар гацах үед түгжрэлийг таслан зогсоох боломжийг олгодог. Контейнерийг энэ төлөвт дахин эхлүүлэх нь алдаа гарсан хэдий ч програмыг газар дээр нь гаргахад тусалдаг боловч энэ нь шаталсан бүтэлгүйтэлд хүргэж болзошгүй (доороос харна уу).

Хэрэв та ашиглалтын/бэлэн байдлын шалгалтанд амжилтгүй болсон програмын шинэчлэлтийг суулгахыг оролдвол Кубернетес статусыг хүлээж байх үед түүний нээлт зогсох болно. Ready бүх хонхорцогоос.

Жишээ нь:

Замыг шалгаж байгаа бэлэн байдлын датчикийн жишээ энд байна /health өгөгдмөл тохиргоотой HTTP-ээр (завсарлага: 10 секунд, завсарлага: 1 секунд, амжилтын босго: 1, бүтэлгүйтлийн босго: 3):

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

зөвлөмж

HTTP төгсгөлийн цэг бүхий микро үйлчилгээнд (REST гэх мэт) бэлэн байдлын шалгалтыг үргэлж тодорхойлно, энэ нь програм (pod) нь урсгалыг хүлээн авахад бэлэн эсэхийг шалгадаг.
Бэлэн байдлын шалгалтыг шалгана уу бодит вэб серверийн портын бэлэн байдлыг хамарна:
- "админ" эсвэл "удирдлага" гэж нэрлэгддэг портуудыг захиргааны зорилгоор ашиглах (жишээ нь, 9090) readinessProbe, үндсэн HTTP порт (жишээ нь 8080) траффик хүлээн авахад бэлэн бол эцсийн цэг нь зөвхөн OK буцаадаг эсэхийг шалгаарай*;
  *Заландо хотод ийм тохиолдол гараагүй дор хаяж нэг тохиолдлыг би мэднэ. readinessProbe Би "удирдлага" портыг шалгасан боловч кэшийг ачаалахад асуудал үүссэн тул сервер өөрөө ажиллаж эхлээгүй.
- бэлэн байдлын датчикийг тусдаа порт руу залгах нь үндсэн порт дээрх хэт ачааллыг эрүүл мэндийн үзлэгт тусгахгүй (өөрөөр хэлбэл сервер дээрх урсгалын сан дүүрсэн боловч эрүүл мэндийн шалгалт нь бүх зүйл хэвийн байгааг харуулж байна) ).
Үүнийг шалгаарай бэлэн байдлын шалгалт нь мэдээллийн санг эхлүүлэх/шилжүүлэх боломжийг олгодог;
- Үүнд хүрэх хамгийн хялбар арга бол эхлүүлж дууссаны дараа л HTTP сервертэй холбогдох явдал юм (жишээлбэл, өгөгдлийн санг шилжүүлэх Нислэгийн зам гэх мэт.); өөрөөр хэлбэл, эрүүл мэндийн хяналтын статусыг өөрчлөхийн оронд мэдээллийн баазыг шилжүүлж дуустал вэб серверийг эхлүүлэхгүй байх*.
  * Мөн та pod-ын гаднах init контейнеруудаас өгөгдлийн сангийн шилжилтийг ажиллуулж болно. Би бие даасан програмуудын шүтэн бишрэгч хэвээр байна, өөрөөр хэлбэл програмын контейнер нь мэдээллийн санг гадны зохицуулалтгүйгээр хүссэн төлөвт хэрхэн оруулахыг мэддэг програмуудын шүтэн бишрэгч хэвээр байна.
Ашиглах httpGet ердийн эрүүл мэндийн хяналтын цэгүүдээр дамжуулан бэлэн байдлыг шалгах (жишээлбэл, /health).
Анхдагч шалгах параметрүүдийг ойлгох (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- өгөгдмөл сонголтууд нь подвол болно гэсэн үг бэлэн биш ойролцоогоор 30 секундын дараа (3 удаа эрүүл мэндийн шалгалт амжилтгүй болсон).
Технологийн стек (жишээ нь Java/Spring) зөвшөөрвөл "админ" эсвэл "удирдлага"-д зориулж тусдаа порт ашиглан эрүүл мэнд, хэмжүүрийн удирдлагыг ердийн урсгалаас тусгаарлана уу:
- гэхдээ 2-р цэгийн талаар бүү мартаарай.
Шаардлагатай бол бэлэн байдлын мэдрэгчийг кэшийг дулаацуулж/ачааж, сав дулаарах хүртэл 503 статусын кодыг буцаана.
- Мөн би танд шинэ чекийг уншихыг зөвлөж байна startupProbe, 1.16 хувилбар дээр гарсан (бид энэ тухай орос хэл дээр бичсэн энд - ойролцоогоор. орчуул.).

Анхаарах зүйл

Гадны хамааралд бүү найд (өгөгдлийн агуулах гэх мэт) бэлэн байдал/амьдралын туршилтыг явуулах үед - энэ нь шаталсан бүтэлгүйтэлд хүргэж болзошгүй:
- Жишээ болгон, нэг Postgres мэдээллийн баазаас хамааран 10 pods бүхий төлөвтэй REST үйлчилгээг авч үзье: шалгалт нь DB-тэй ажиллаж байгаа холболтоос хамаарах үед сүлжээ/DB тал дээр саатал гарсан тохиолдолд 10 pod бүгд амжилтгүй болж магадгүй. бүх зүйл байж болохоос илүү муугаар төгсдөг;
- Spring Data нь мэдээллийн сангийн холболтыг анхдагчаар шалгадаг болохыг анхаарна уу*;
  * Энэ бол Spring Data Redis-ийн анхдагч үйлдэл юм (ядаж л энэ нь миний хамгийн сүүлд шалгаж байсан) бөгөөд энэ нь "гамшгийн" бүтэлгүйтэлд хүргэсэн: Redis богино хугацаанд ажиллахгүй байх үед бүх pods "гацсан".
- Энэ утгаараа "гадаад" гэдэг нь ижил програмын бусад pods гэсэн утгатай байж болно, өөрөөр хэлбэл шалгалт нь шаталсан эвдрэлээс урьдчилан сэргийлэхийн тулд ижил кластерын бусад pods-ийн төлөв байдлаас хамаарах ёсгүй.
  - Үр дүн нь тархсан төлөвтэй програмуудын хувьд өөр байж болно (жишээ нь, хонхорцог дахь санах ойн кэш).
Амьдрах мэдрэгчийг бүү ашигла хонхорцогуудын хувьд (үл хамаарах зүйл бол тэдгээр нь үнэхээр зайлшгүй шаардлагатай бөгөөд та тэдгээрийн ашиглалтын онцлог, үр дагаврыг бүрэн мэдэж байгаа тохиолдол юм):
- Амьдрах датчик нь өлгөгдсөн савыг сэргээхэд тусалж чадна, гэхдээ та програмаа бүрэн хянах боломжтой тул өлгөгдсөн процесс, түгжрэл зэрэг зүйл тохиолдох ёсгүй: хамгийн сайн сонголт бол програмыг зориудаар эвдэж, өмнөх тогтвортой байдалд нь буцаах явдал юм;
- Амжилтгүй амьдрах чадварыг шалгах нь савыг дахин эхлүүлэхэд хүргэж, улмаар ачаалахтай холбоотой алдааны үр дагаврыг улам хүндрүүлж болзошгүй: савыг дахин эхлүүлэх нь ажиллахгүй байх хугацаа (наад зах нь програмыг эхлүүлэх хугацаанд, жишээ нь 30 сондгой секунд) үүсгэж, шинэ алдаа гаргах болно. , бусад савны ачааллыг нэмэгдүүлэх, тэдгээрийн бүтэлгүйтлийн магадлалыг нэмэгдүүлэх гэх мэт;
- Амьдрах чадварыг гадны хамааралтай хослуулах нь хамгийн муу хослол бөгөөд шаталсан алдаа гарахад заналхийлж байна: өгөгдлийн сангийн тал дээр бага зэрэг саатал гарах нь таны бүх контейнерийг дахин эхлүүлэхэд хүргэнэ!
Амьдрах, бэлэн байдлыг шалгах параметрүүд өөр байх ёстой:
- Та ижил эрүүл мэндийн үзлэгтэй боловч хариу өгөх босго өндөр (failureThreshold), жишээ нь статусыг оноох бэлэн биш 3 оролдлогын дараа, 10 оролдлогын дараа амьд байдлын датчик амжилтгүй болсон гэж үзэх;
Exec шалгалтыг бүү ашигла, учир нь тэдгээр нь зомби үйл явц үүсэхэд хүргэдэг мэдэгдэж буй асуудлуудтай холбоотой байдаг.
- дэлгэрэнгүй: үзнэ үү Datadog мэргэжилтнүүдийн илтгэл.

Хураангуй

Под урсгалыг хүлээн авахад бэлэн байгаа эсэхийг тодорхойлохын тулд бэлэн байдлын датчик ашиглана уу.
Амьдрах датчикийг үнэхээр шаардлагатай үед л ашиглаарай.
Бэлэн байдал/амьдралын датчикийг зохисгүй ашиглах нь хүртээмжийг бууруулж, шаталсан бүтэлгүйтэлд хүргэдэг.

Сэдвийн талаархи нэмэлт материалууд

1-2019-09-ний өдрийн 29-р шинэчлэл

Өгөгдлийн санг шилжүүлэхэд зориулсан init контейнеруудын тухай: Зүүлт тайлбар нэмсэн.

EJ надад санууллаа PDB-ийн тухай: Амьдрах чадварыг шалгахад тулгарч буй бэрхшээлүүдийн нэг нь хонхорцог хоорондын уялдаа холбоо дутмаг байдаг. Кубернетес байна Pod тасалдсан төсөв (PDB) Програмд тохиолдож болох нэгэн зэрэг алдааны тоог хязгаарлах боловч шалгалтууд нь PDB-г харгалздаггүй. Бид K8-д "Туршилт амжилтгүй болбол дахин эхлүүлээрэй, гэхдээ нөхцөл байдлыг улам дордуулахгүйн тулд бүгдийг дахин эхлүүлж болохгүй" гэж хэлж болно.

Брайан үүнийг төгс хэлсэн: "Чи яг юуг мэдэж байгаа бол liveness probing ашигла Хамгийн сайн хийх зүйл бол програмыг устгах явдал юм"(дахин хэлэхэд битгий уурлаарай).

2-2019-09-ний өдрийн 29-р шинэчлэл

Хэрэглэхийн өмнө баримт бичгийг унших талаар: Би холбогдох хүсэлтийг үүсгэсэн (онцлог хүсэлт) амьд байдлын датчикуудын талаархи баримт бичгийг нэмэх.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

Кубернетес дэх амьд байдлыг шалгах нь аюултай байж болно