Kubernetes-ում կենդանության զոնդերը կարող են վտանգավոր լինել

Նշում. թարգմ.Զալանդոյից առաջատար ինժեներ Հեննինգ Ջեյքոբսը բազմիցս նկատել է խնդիրներ Kubernetes-ի օգտատերերի շրջանում՝ հասկանալու կենդանիության (և պատրաստվածության) զոնդերի նպատակը և դրանց ճիշտ օգտագործումը: Ուստի նա իր մտքերը հավաքեց այս տարողունակ գրության մեջ, որն ի վերջո կդառնա K8-ի փաստաթղթերի մի մասը։

Առողջության ստուգումներ, որոնք հայտնի են Կուբերնետեսում որպես աշխուժության զոնդեր (այսինքն, բառացիորեն, «կենսունակության թեստեր» - մոտավորապես թարգմ.), կարող է բավականին վտանգավոր լինել։ Խորհուրդ եմ տալիս հնարավորության դեպքում խուսափել դրանցից. բացառություններ են միայն այն դեպքերը, երբ դրանք իսկապես անհրաժեշտ են, և դուք լիովին տեղյակ եք դրանց օգտագործման առանձնահատկություններին և հետևանքներին: Այս հրապարակումը կխոսի աշխուժության և պատրաստվածության ստուգումների մասին, ինչպես նաև կպատմի, թե որ դեպքերում է և դուք չպետք է օգտագործեք դրանք:

Իմ գործընկեր Շանդորը վերջերս Twitter-ում կիսվել է իր հանդիպած ամենատարածված սխալներով, այդ թվում՝ պատրաստակամության/աշխուժության զոնդերի օգտագործման հետ կապված.

Սխալ կազմաձևված է livenessProbe կարող է խորացնել բարձր բեռնվածության իրավիճակները (ձնագնդի անջատում + պոտենցիալ երկար կոնտեյների/հավելվածի գործարկման ժամանակ) և հանգեցնել այլ բացասական հետևանքների, ինչպիսիք են կախվածության անկումը (տես նաեւ իմ վերջին հոդվածը K3s+ACME համակցությամբ հարցումների քանակի սահմանափակման մասին). Նույնիսկ ավելի վատ է, երբ կենդանի զոնդը զուգակցվում է առողջության ստուգման հետ, որը արտաքին տվյալների բազա է. մեկ DB ձախողումը կվերագործարկի ձեր բոլոր բեռնարկղերը!

Ընդհանուր հաղորդագրություն «Մի օգտագործեք աշխուժության զոնդերը» այս դեպքում դա այնքան էլ չի օգնում, ուստի եկեք տեսնենք, թե ինչի համար են պատրաստվածության և աշխուժության ստուգումները:

Նշում. Ստորև բերված թեստի մեծ մասն ի սկզբանե ներառված էր Զալանդոյի ներքին մշակողների փաստաթղթերում:

Պատրաստության և աշխուժության ստուգումներ

Kubernetes-ը տրամադրում է երկու կարևոր մեխանիզմ, որոնք կոչվում են աշխուժության զոնդեր և պատրաստության զոնդեր. Նրանք պարբերաբար կատարում են որոշ գործողություններ, ինչպիսիք են՝ ուղարկելով HTTP հարցում, բացելով TCP կապ կամ հրամանի կատարում կոնտեյներով՝ հաստատելու համար, որ հավելվածն աշխատում է այնպես, ինչպես սպասվում էր:

Kubernetes-ը օգտագործում է պատրաստականության զոնդերհասկանալու համար, թե երբ է բեռնարկղը պատրաստ ընդունելու երթևեկությունը: Պատիճը համարվում է պատրաստ օգտագործման համար, եթե դրա բոլոր տարաները պատրաստ են: Այս մեխանիզմի օգտագործումից մեկն այն է, որ վերահսկել, թե որ պատնեշներն են օգտագործվում որպես Kubernetes ծառայությունների (և հատկապես Ingress-ի) հետադարձ կապ:

Կենդանության զոնդերը օգնել Kubernetes-ին հասկանալ, թե երբ է կոնտեյները վերագործարկելու ժամանակը: Օրինակ, նման ստուգումը թույլ է տալիս արգելափակել փակուղին, երբ հավելվածը խրվում է մեկ տեղում: Կոնտեյների վերագործարկումն այս վիճակում օգնում է հավելվածը հանել գետնից՝ չնայած սխալներին, բայց դա կարող է նաև հանգեցնել կասկադային խափանումների (տես ստորև):

Եթե ​​փորձեք տեղակայել հավելվածի թարմացում, որը ձախողում է ակտիվության/պատրաստության ստուգումները, դրա թողարկումը կդադարեցվի, քանի որ Kubernetes-ը սպասում է կարգավիճակին: Ready բոլոր պատյաններից:

Օրինակ

Ահա ուղին ստուգող պատրաստականության զոնդի օրինակ /health HTTP-ի միջոցով լռելյայն կարգավորումներով (ընդմիջում: 10 վայրկյան, timeout: 1 վայրկյան, հաջողության շեմը: 1, ձախողման շեմը: 3):

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

Առաջարկություններ

1. HTTP վերջնակետ ունեցող միկրոծառայությունների համար (REST և այլն) միշտ սահմանել պատրաստության հետաքննություն, որը ստուգում է, թե արդյոք հավելվածը (pod) պատրաստ է ընդունելու տրաֆիկը։
2. Համոզվեք, որ պատրաստվածության ստուգումը ծածկում է փաստացի վեբ սերվերի պորտի առկայությունը:
   • օգտագործելով նավահանգիստները վարչական նպատակներով, որոնք կոչվում են «admin» կամ «management» (օրինակ՝ 9090), readinessProbe, համոզվեք, որ վերջնակետը OK է վերադառնում միայն այն դեպքում, եթե հիմնական HTTP պորտը (ինչպես 8080) պատրաստ է ընդունելու տրաֆիկը*;

     *Ես տեղյակ եմ առնվազն մեկ դեպքի մասին Zalando-ում, որտեղ դա տեղի չի ունեցել, այսինքն. readinessProbe Ես ստուգեցի «կառավարման» պորտը, բայց սերվերն ինքնին չսկսեց աշխատել քեշը բեռնելու հետ կապված խնդիրների պատճառով:

   • Առանձին նավահանգստին պատրաստականության զոնդ կցելը կարող է հանգեցնել այն բանի, որ հիմնական պորտի գերբեռնվածությունը չի արտացոլվի առողջության ստուգման մեջ (այսինքն, սերվերի թեման լողավազանը լցված է, բայց առողջության ստուգումը դեռ ցույց է տալիս, որ ամեն ինչ կարգին է: )
3. Համոզվեք, որ պատրաստակամության զոնդը հնարավորություն է տալիս տվյալների բազայի սկզբնավորում/միգրացիա;
   • Դրան հասնելու ամենադյուրին ճանապարհը HTTP սերվերի հետ կապվելն է միայն սկզբնավորման ավարտից հետո (օրինակ՝ տվյալների բազայի տեղափոխումը թռիչքուղի և այլն); այսինքն՝ առողջական ստուգման կարգավիճակը փոխելու փոխարեն, պարզապես մի գործարկեք վեբ սերվերը մինչև տվյալների բազայի միգրացիան ավարտված լինի*։

     * Դուք կարող եք նաև գործարկել տվյալների բազայի միգրացիաներ սկզբնական բեռնարկղերից՝ պատիճից դուրս: Ես դեռ երկրպագում եմ ինքնամփոփ հավելվածներին, այսինքն՝ նրանց, որոնցում հավելվածի կոնտեյները գիտի, թե ինչպես պետք է տվյալների բազան բերել ցանկալի վիճակի՝ առանց արտաքին կոորդինացման։

4. Օգտագործեք httpGet պատրաստակամության ստուգումների համար՝ տիպիկ առողջության ստուգման վերջնական կետերի միջոցով (օրինակ. /health).
5. Հասկացեք կանխադրված ստուգման պարամետրերը (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • լռելյայն ընտրանքները նշանակում են, որ պատիճը կդառնա պատրաստ չէ մոտ 30 վայրկյան հետո (3 անհաջող առողջական ստուգում):
6. Օգտագործեք առանձին պորտ «ադմինիստրատորի» կամ «մենեջմենթի» համար, եթե տեխնոլոգիայի փաթեթը (օրինակ՝ Java/Spring) դա թույլ է տալիս՝ առողջությունը և չափումների կառավարումը սովորական տրաֆիկից առանձնացնելու համար.
   • բայց մի մոռացեք 2-րդ կետի մասին.
7. Անհրաժեշտության դեպքում պատրաստականության զոնդը կարող է օգտագործվել քեշը տաքացնելու/բեռնելու և 503 կարգավիճակի կոդը վերադարձնելու համար, մինչև բեռնարկղը տաքանա.
   • Ես նաև խորհուրդ եմ տալիս կարդալ նոր ստուգումը startupProbe, հայտնվել է 1.16 տարբերակում (այդ մասին գրել ենք ռուսերեն այստեղ - մոտ. թարգմ.).

Caveats

1. Մի ապավինեք արտաքին կախվածություններին (օրինակ՝ տվյալների պահեստները) պատրաստության/աշխատանքի թեստերի ժամանակ, դա կարող է հանգեցնել կասկադային ձախողումների.
   • Որպես օրինակ, եկեք վերցնենք պետական ​​REST ծառայությունը 10 pods-ով, կախված Postgres-ի մեկ տվյալների բազայից. երբ ստուգումը կախված է DB-ի հետ աշխատող միացումից, բոլոր 10 pod-ները կարող են ձախողվել, եթե ցանցի/DB-ի կողմում ուշացում կա, սովորաբար դա: ամեն ինչ ավարտվում է ավելի վատ, քան կարող էր;
   • Խնդրում ենք նկատի ունենալ, որ Spring Data-ն ստուգում է տվյալների բազայի կապը լռելյայն*;

     * Սա Spring Data Redis-ի լռելյայն վարքագիծն է (համենայնդեպս դա վերջին անգամն էր, երբ ես ստուգեցի), ինչը հանգեցրեց «աղետալի» ձախողման. երբ Redis-ը կարճ ժամանակով անհասանելի էր, բոլոր պատիճները «վթարի ենթարկվեցին»:

   • «Արտաքին» այս իմաստով կարող է նշանակել նաև նույն հավելվածի այլ պատյաններ, այսինքն՝ իդեալականորեն ստուգումը չպետք է կախված լինի նույն կլաստերի այլ պատյանների վիճակից՝ կասկադային վթարները կանխելու համար.
     • արդյունքները կարող են տարբեր լինել բաշխված վիճակ ունեցող հավելվածների համար (օրինակ՝ հիշողության մեջ պահվող պահոցներ պատյաններում):
2. Մի օգտագործեք աշխուժության զոնդ պատիճների համար (բացառություն են այն դեպքերը, երբ դրանք իսկապես անհրաժեշտ են, և դուք լիովին տեղյակ եք դրանց օգտագործման առանձնահատկություններին և հետևանքներին).
   • Կենսունակության զոնդը կարող է օգնել վերականգնել կախված բեռնարկղերը, բայց քանի որ դուք լիովին վերահսկում եք ձեր հավելվածը, այնպիսի բաներ, ինչպիսիք են կախովի գործընթացները և փակուղիները, իդեալականորեն չպետք է տեղի ունենան.
   • անհաջող աշխուժության հետաքննությունը կհանգեցնի կոնտեյների վերագործարկմանը՝ դրանով իսկ պոտենցիալ սրելով բեռնման հետ կապված սխալների հետևանքները. մեծացնելով այլ բեռնարկղերի բեռը և մեծացնելով դրանց ձախողման հավանականությունը և այլն.
   • Կենսունակության ստուգումները՝ զուգորդված արտաքին կախվածության հետ, ամենավատ հնարավոր համակցությունն է, որը սպառնում է կասկադային ձախողումների. տվյալների բազայի մի փոքր ուշացումը կհանգեցնի ձեր բոլոր բեռնարկղերի վերագործարկմանը:
3. Կենսունակության և պատրաստվածության ստուգման պարամետրեր պետք է տարբեր լինի:
   • Դուք կարող եք օգտագործել կենդանի զոնդ նույն առողջության ստուգմամբ, բայց ավելի բարձր արձագանքման շեմով (failureThreshold), օրինակ, նշանակեք կարգավիճակը պատրաստ չէ 3 փորձից հետո և համարեք, որ աշխուժության զոնդը ձախողվել է 10 փորձից հետո.
4. Մի օգտագործեք exec ստուգումներ, քանի որ դրանք կապված են հայտնի խնդիրների հետ, որոնք հանգեցնում են զոմբիական գործընթացների առաջացմանը.
   • մանրամասները՝ տես ներկայացում Datadog-ի մասնագետների կողմից.

Ամփոփում

• Օգտագործեք պատրաստության զոնդերը՝ որոշելու, թե երբ է պատիճը պատրաստ տրաֆիկ ընդունելու:
• Օգտագործեք կենդանի զոնդերը միայն այն ժամանակ, երբ դրանք իսկապես անհրաժեշտ են:
• Պատրաստության/աշխուժության զոնդերի ոչ պատշաճ օգտագործումը կարող է հանգեցնել մատչելիության նվազման և կասկադային ձախողումների:

Թեմայի վերաբերյալ լրացուցիչ նյութեր

• Kubernetes-ի փաստաթղթեր. Կարգավորել Liveness և Readiness զոնդերը;
• Kubernetes-ի կենդանության և պատրաստակամության զոնդերը վերանայվել են. ինչպես խուսափել մյուս ոտքի վրա կրակելուց;
• NRE Labs-ի անջատումը հետմահու (նա նաև խոսում է livenessProbe-ի մասին):

Թարմացում թիվ 1 2019-09-29 թթ

Տվյալների բազայի միգրացիայի համար init կոնտեյներների մասինԱվելացված է ծանոթագրություն։

EJ-ն ինձ հիշեցրեց PDB-ի մասին. աշխուժության ստուգման խնդիրներից մեկը կոորդինացման բացակայությունն է պատյանների միջև: Կուբերնետեսն ունի Պոդի խանգարման բյուջեներ (PDB) սահմանափակելու միաժամանակյա խափանումների քանակը, որոնք կարող են հանդիպել հավելվածը, սակայն ստուգումները հաշվի չեն առնում PDB-ն: Իդեալում, մենք կարող ենք K8-ին ասել «Վերագործարկեք մեկ pod, եթե դրա փորձարկումը ձախողվի, բայց մի վերագործարկեք դրանք բոլորին, որպեսզի չվատթարացնեք իրավիճակը»:

Բրայանը հիանալի ձևակերպեց«Օգտագործեք աշխույժ զոնդավորում, երբ հստակ գիտեք, թե ինչ ամենալավ բանը, որ կարելի է անել, հավելվածը սպանելն է«(կրկին մի տարվեք):

Թարմացում թիվ 2 2019-09-29 թթ

Օգտագործելուց առաջ փաստաթղթերը կարդալու վերաբերյալԵս ստեղծել եմ համապատասխան հարցումը (հատկությունների հարցում) կենսունակության զոնդերի վերաբերյալ փաստաթղթեր ավելացնելու համար:

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

• «Kubernetes: Pod Life";
• «Google-ի 7 բեռնարկղերի լավագույն փորձը";
• «7 սկզբունք կոնտեյներների վրա հիմնված հավելվածների նախագծման համար.

Source: www.habr.com