🥇Кубернетестеги жандуу зонддор кооптуу болушу мүмкүн

Эскертүү. котормо.: Заландодон келген жетектөөчү инженер Хеннинг Джейкобс Кубернетестин колдонуучулары арасында жандуу (жана даяр) зонддордун максатын жана аларды туура колдонууда көйгөйлөрдү бир нече жолу байкаган. Ошондуктан, ал акырында K8s документтеринин бир бөлүгү болуп калат, бул сыйымдуулук жазууда өз ойлорун чогулткан.

Ден соолук текшерүүлөрү, Кубернетесте белгилүү жандуу зонддор (б.а., сөзмө-сөз, "жашоо жөндөмдүүлүгүн текшерүү" - болжол менен котормосу.), абдан коркунучтуу болушу мүмкүн. Мүмкүн болсо, алардан качууну сунуштайм: алар чындап зарыл болгондо гана өзгөчөлүктөр болуп саналат жана сиз аларды колдонуунун өзгөчөлүктөрүн жана кесепеттерин толук билесиз. Бул басылма жандуу жана даярдыгын текшерүү жөнүндө сөз болот, ошондой эле кандай учурларда айтып берет чыгымдар жана сиз аларды колдонбошуңуз керек.

Менин кесиптешим Шандор жакында Твиттерде эң көп кездешкен каталар менен бөлүштү, анын ичинде даярдык/жандуу зоналарды колдонууга байланыштуу:

Туура эмес конфигурацияланган livenessProbe жогорку жүктөмдүү кырдаалдарды күчөтүшү мүмкүн (кар тополоңунун өчүрүлүшү + мүмкүн болгон узак контейнер/тиркеменин ишке киргизүү убактысы) жана көз карандылыктын төмөндөшү сыяктуу башка терс кесепеттерге алып келиши мүмкүн (ошондой эле кара менин акыркы макалам K3s+ACME айкалышында суроо-талаптардын санын чектөө жөнүндө). Жандуу зонду ден соолукту текшерүү менен айкалыштырганда, андан да жаманы, бул тышкы маалымат базасы: бир DB катасы бардык контейнерлериңизди кайра иштетет!

Жалпы кабар "Жашоо зонддорун колдонбоңуз" бул учурда ал көп жардам бербейт, ошондуктан, келгиле, даярдык жана жандуу текшерүүлөр эмне үчүн экенин карап көрөлү.

Эскертүү: Төмөндөгү тесттердин көбү башында Заландонун ички иштеп чыгуучу документтерине киргизилген.

Даярдыкты жана жандуулукту текшерет

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, ж.б.) ар дайым даярдыгын аныктоотиркеме (под) трафикти кабыл алууга даярбы же жокпу текшерет.
Даярдык текшерүүсүн текшериңиз реалдуу веб-сервер портунун болушун камтыйт:
- "администратор" же "башкаруу" деп аталган портторду административдик максаттар үчүн колдонуу (мисалы, 9090) readinessProbe, негизги HTTP порту (мисалы, 8080) трафикти кабыл алууга даяр болгондо гана акыркы чекит OK кайтараарын текшериңиз*;
  * Мен Заландодо мындай болбогон жок дегенде бир окуяны билем, б.а. readinessProbe Мен "башкаруу" портун текшердим, бирок кэшти жүктөөдөгү көйгөйлөрдөн улам сервер өзү иштей баштаган жок.
- өзүнчө портко даярдоо зонду тиркөө негизги порттун ашыкча жүктөө ден соолукту текшерүүдө чагылдырылбай калышына алып келиши мүмкүн (б.а. сервердеги жип бассейни толгон, бирок ден соолукту текшерүү баары жакшы экенин көрсөтөт. ).
Муну тактаңыз Даярдык текшерүүсү маалымат базасын инициализациялоо/көчүрүү мүмкүнчүлүгүн берет;
- Буга жетишүүнүн эң оңой жолу - инициализация аяктагандан кийин гана HTTP сервери менен байланышуу (мисалы, маалымат базасын көчүрүү Жол учуу жана башка.); башкача айтканда, ден соолукту текшерүү статусун өзгөртүүнүн ордуна, маалымат базасын көчүрүү аяктаганга чейин веб-серверди жөн эле иштетпеңиз*.
  * Сиз ошондой эле поддондун сыртындагы init контейнерлеринен маалымат базасын көчүрө аласыз. Мен дагы эле өз алдынча тиркемелердин күйөрманымын, башкача айтканда, тиркемелердин контейнери маалымат базасын тышкы координациясыз каалаган абалга кантип алып келүүнү билет.
колдонуу httpGet типтүү ден соолукту текшерүү пункттары аркылуу даярдыгын текшерүү үчүн (мисалы, /health).
Демейки текшерүү параметрлерин түшүнүү (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- демейки параметрлер подколько болуп калат дегенди билдирет даяр эмес болжол менен 30 секунддан кийин (3 ийгиликсиз акыл-эсти текшерүү).
Технология стек (мисалы, Java/Spring) уруксат берсе, ден соолукту жана көрсөткүчтөрдү башкарууну кадимки трафиктен бөлүү үчүн "администратор" же "башкаруу" үчүн өзүнчө порт колдонуңуз:
- бирок 2-пунктту унутпаңыз.
Зарыл болсо, даяр зонду кэшти жылытуу/жүктөө жана контейнер жылыганга чейин 503 статус кодун кайтаруу үчүн колдонулушу мүмкүн:
- Мен дагы жаңы чекти окуп чыгууну сунуш кылам startupProbe, 1.16 версиясында пайда болгон (бул тууралуу орусча жазганбыз бул жерде — болжол менен. котормо.).

алчу

Тышкы көз карандылыкка ишенбеңиз (мисалы, маалымат кампалары) даярдуулук/жашоо тесттерин жүргүзүүдө - бул каскаддык каталарга алып келиши мүмкүн:
- Мисал катары, бир Postgres маалымат базасына жараша 10 подпускадан турган мамлекеттик REST кызматын алалы: текшерүү МБга иштеген туташуудан көз каранды болгондо, тармакта/МБ тарабында кечигүү болсо, бардык 10 поддон иштебей калышы мүмкүн - адатта бул баары мүмкүн болушунча жаман аяктайт;
- Жазгы маалыматтар базалык байланышты демейки боюнча текшерерин эске алыңыз*;
  * Бул Spring Data Redis демейки жүрүм-туруму (жок дегенде бул мен акыркы жолу текшергеним эле), бул "катастрофиялык" катага алып келди: Редис кыска убакытка жеткиликсиз болгондо, бардык подборкалар "кырсык" болду.
- Бул мааниде "тышкы" бир эле тиркеменин башка подъезддерин да билдириши мүмкүн, башкача айтканда, каскаддык кыйроолордон сактануу үчүн текшерүү ошол эле кластердин башка бөлүкчөлөрүнүн абалынан көз каранды болбошу керек:
  - натыйжалар бөлүштүрүлгөн абалы бар колдонмолор үчүн ар кандай болушу мүмкүн (мисалы, подкасттарда эстутумдагы кэштөө).
Жашоо зондун колдонбоңуз кабыктар үчүн (айрыкча, алар чындап эле зарыл болгон жана сиз аларды колдонуунун өзгөчөлүктөрүн жана кесепеттерин толук билесиз):
- Жашоо зонду илинип калган контейнерлерди калыбына келтирүүгө жардам берет, бирок сиз колдонмоңузду толук көзөмөлдөй тургандыктан, илинип турган процесстер жана туюктар сыяктуу нерселер идеалдуу түрдө болбошу керек: эң жакшы альтернатива – тиркемени атайылап бузуп, аны мурунку туруктуу абалга алып келүү;
- ишке ашпай калган жандык иликтөө контейнерди кайра иштетүүгө алып келет, ошону менен жүктөө менен байланышкан каталардын кесепеттерин күчөтүшү мүмкүн: контейнерди кайра иштетүү токтоп калууга алып келет (жок дегенде колдонмону ишке киргизүү учурунда, айталы, 30 так секунд) жаңы каталарды пайда кылат , башка контейнерлерге жүктү көбөйтүү жана алардын иштебей калуу ыктымалдыгын жогорулатуу ж.б.;
- тышкы көз карандылык менен айкалышкан жандуу текшерүүлөр - бул мүмкүн болгон эң начар комбинация, каскаддык мүчүлүштүктөргө коркунуч туудурат: маалымат базасы тарабында бир аз кечигүү бардык контейнерлериңизди кайра иштетүүгө алып келет!
Жандуулукту жана даярдыкты текшерүүнүн параметрлери башкача болушу керек:
- ошол эле ден соолук текшерүүсү менен жандуу зонду колдоно аласыз, бирок жооп босогосу жогору (failureThreshold), мисалы, статусту дайындаңыз даяр эмес 3 аракеттен кийин жана 10 аракеттен кийин жандуу зонд ишке ашпай калды деп эсептеңиз;
Exec текшерүүлөрүн колдонбоңуз, алар зомби процесстеринин пайда болушуна алып келген белгилүү көйгөйлөр менен байланышкан:
- чоо-жайы: карагыла Datadog адистеринин презентациясы.

на

Подгон трафикти кабыл алууга качан даяр экенин аныктоо үчүн даярдык зонддорун колдонуңуз.
Жандуу зонддорду алар чындап керек болгондо гана колдонуңуз.
Даярдык/жандуу зоналарды туура эмес колдонуу жеткиликтүүлүктүн төмөндөшүнө жана каскаддык каталарга алып келиши мүмкүн.

Тема боюнча кошумча материалдар

Kubernetes docs: Жашоо жана Даярдык текшерүүлөрүн конфигурациялаңыз;
Кубернетестин жандуулугу жана даярдыгы кайра каралып чыкты: башка бутка ок атуудан кантип сактануу керек;
Өлгөндөн кийин NRE лабораториясынын үзгүлтүккө учурашы (ал ошондой эле livenessProbe жөнүндө айтат).

Жаңылоо № 1, 2019

Маалыматтар базасын көчүрүү үчүн init контейнерлери жөнүндө: Шилтеме кошулду.

EJ эсиме салды PDB жөнүндө: жандуулукту текшерүүдөгү көйгөйлөрдүн бири - бул кабыкчалардын ортосундагы координациянын жоктугу. Kubernetes бар Pod үзгүлтүккө учуратуу бюджеттери (PDB) Колдонмого туш болушу мүмкүн болгон бир эле учурда каталардын санын чектөө үчүн, бирок текшерүүлөр PDBди эске албайт. Идеалында, биз K8ге "эгер сынагынан майнап чыкпаса, аны өчүрүп күйгүзүңүз, бирок ишти ого бетер начарлатпоо үчүн баарын өчүрүп күйгүзбөңүз" деп айтсак болот.

Брайан аны эң сонун айткан: "Эмне болгонун так билгенден кийин жандуу изилдөөнү колдонуңуз эң жакшы нерсе - бул колдонмону өлтүрүү"(Дагы бир жолу, алданып калбаңыз).

Жаңылоо № 2, 2019

Колдонуудан мурун документтерди окууга байланыштуу: Мен тиешелүү өтүнүчтү түздүм (өзгөчөлүк сурамы) жандуу зонддор жөнүндө документтерди кошуу.

Котормочудан PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Кубернетестеги жандуу зонддор кооптуу болушу мүмкүн