కుబెర్నెటెస్‌లోని లైవ్‌నెస్ ప్రోబ్స్ ప్రమాదకరం

గమనిక. అనువాదం.: జలాండో నుండి లీడ్ ఇంజనీర్, హెన్నింగ్ జాకబ్స్, లైవ్‌నెస్ (మరియు సంసిద్ధత) ప్రోబ్స్ మరియు వాటి సరైన ఉపయోగం యొక్క ఉద్దేశ్యాన్ని అర్థం చేసుకోవడంలో కుబెర్నెట్స్ వినియోగదారుల మధ్య సమస్యలను పదేపదే గమనించారు. అందువల్ల, అతను ఈ కెపాసియస్ నోట్‌లో తన ఆలోచనలను సేకరించాడు, ఇది చివరికి K8s డాక్యుమెంటేషన్‌లో భాగం అవుతుంది.

ఆరోగ్య తనిఖీలు, కుబెర్నెట్స్‌లో అంటారు సజీవ ప్రోబ్స్ (అనగా, అక్షరాలా, “సాధ్యత పరీక్షలు” - సుమారుగా. అనువాదం.), చాలా ప్రమాదకరమైనది కావచ్చు. వీలైతే వాటిని నివారించాలని నేను సిఫార్సు చేస్తున్నాను: అవి నిజంగా అవసరమైనప్పుడు మాత్రమే మినహాయింపులు మరియు వాటి ఉపయోగం యొక్క ప్రత్యేకతలు మరియు పరిణామాల గురించి మీకు పూర్తిగా తెలుసు. ఈ ప్రచురణ లైవ్‌నెస్ మరియు సంసిద్ధత తనిఖీల గురించి మాట్లాడుతుంది మరియు ఏ సందర్భాలలో కూడా మీకు తెలియజేస్తుంది అది విలువ మరియు మీరు వాటిని ఉపయోగించకూడదు.

నా సహోద్యోగి సాండోర్ ఇటీవల ట్విట్టర్‌లో సంసిద్ధత/జీవన ప్రోబ్స్ వినియోగానికి సంబంధించిన వాటితో సహా అతను ఎదుర్కొనే అత్యంత సాధారణ లోపాలను పంచుకున్నాడు:

తప్పుగా కాన్ఫిగర్ చేయబడింది livenessProbe అధిక-లోడ్ పరిస్థితులను (స్నోబాల్ షట్‌డౌన్ + సంభావ్యంగా పొడవైన కంటైనర్/అప్లికేషన్ స్టార్టప్ సమయం) తీవ్రతరం చేస్తుంది మరియు డిపెండెన్సీ డ్రాప్స్ వంటి ఇతర ప్రతికూల పరిణామాలకు దారితీస్తుంది (ఇది కూడ చూడు నా ఇటీవలి వ్యాసం K3s+ACME కలయికలో అభ్యర్థనల సంఖ్యను పరిమితం చేయడం గురించి). లైవ్‌నెస్ ప్రోబ్‌ను ఆరోగ్య తనిఖీతో కలిపి ఉన్నప్పుడు ఇది మరింత ఘోరంగా ఉంటుంది, ఇది బాహ్య డేటాబేస్: ఒక్క DB వైఫల్యం మీ అన్ని కంటైనర్‌లను పునఃప్రారంభిస్తుంది!

సాధారణ సందేశం "లైవ్‌నెస్ ప్రోబ్స్‌ని ఉపయోగించవద్దు" ఈ సందర్భంలో అది పెద్దగా సహాయం చేయదు, కాబట్టి సంసిద్ధత మరియు లైవ్‌నెస్ చెక్‌లు దేనికి సంబంధించినవో చూద్దాం.

గమనిక: దిగువన ఉన్న చాలా పరీక్ష వాస్తవానికి Zalando యొక్క అంతర్గత డెవలపర్ డాక్యుమెంటేషన్‌లో చేర్చబడింది.

సంసిద్ధత మరియు సజీవత తనిఖీలు

కుబెర్నెటెస్ అనే రెండు ముఖ్యమైన విధానాలను అందిస్తుంది సజీవ ప్రోబ్స్ మరియు సంసిద్ధత ప్రోబ్స్. వారు క్రమానుగతంగా కొన్ని చర్యలను నిర్వహిస్తారు-HTTP అభ్యర్థనను పంపడం, TCP కనెక్షన్‌ని తెరవడం లేదా కంటైనర్‌లో ఆదేశాన్ని అమలు చేయడం వంటివి—అప్లికేషన్ ఆశించిన విధంగా పని చేస్తుందని నిర్ధారించడానికి.

Kubernetes ఉపయోగిస్తుంది సంసిద్ధత ప్రోబ్స్ట్రాఫిక్‌ని అంగీకరించడానికి కంటైనర్ ఎప్పుడు సిద్ధంగా ఉందో అర్థం చేసుకోవడానికి. ఒక పాడ్ దాని అన్ని కంటైనర్లు సిద్ధంగా ఉంటే ఉపయోగం కోసం సిద్ధంగా పరిగణించబడుతుంది. ఈ మెకానిజం యొక్క ఒక ఉపయోగం ఏమిటంటే, కుబెర్నెటెస్ సేవలకు (మరియు ముఖ్యంగా ప్రవేశం) బ్యాకెండ్‌లుగా ఏ పాడ్‌లను ఉపయోగించాలో నియంత్రించడం.

లైవ్‌నెస్ ప్రోబ్స్ కంటైనర్‌ను పునఃప్రారంభించాల్సిన సమయం ఆసన్నమైందో అర్థం చేసుకోవడానికి కుబెర్నెట్‌లకు సహాయపడండి. ఉదాహరణకు, ఒక అప్లికేషన్ ఒకే చోట చిక్కుకున్నప్పుడు ప్రతిష్టంభనను అడ్డగించడానికి అటువంటి చెక్ మిమ్మల్ని అనుమతిస్తుంది. ఈ స్థితిలో కంటైనర్‌ను పునఃప్రారంభించడం ఎర్రర్‌లు ఉన్నప్పటికీ అప్లికేషన్‌ను గ్రౌండ్‌లో ఉంచడంలో సహాయపడుతుంది, అయితే ఇది క్యాస్కేడింగ్ వైఫల్యాలకు కూడా దారితీయవచ్చు (క్రింద చూడండి).

మీరు లైవ్‌నెస్/సన్నద్ధత తనిఖీలలో విఫలమయ్యే అప్లికేషన్ అప్‌డేట్‌ను అమలు చేయడానికి ప్రయత్నిస్తే, కుబెర్నెట్స్ స్థితి కోసం వేచి ఉన్నందున దాని రోల్ అవుట్ నిలిచిపోతుంది Ready అన్ని పాడ్‌ల నుండి.

ఉదాహరణకు

మార్గాన్ని తనిఖీ చేసే సంసిద్ధత ప్రోబ్ యొక్క ఉదాహరణ ఇక్కడ ఉంది /health డిఫాల్ట్ సెట్టింగ్‌లతో HTTP ద్వారా (విరామం: 10 సెకన్లు, సమయం ముగిసినది: 1 సెకను, విజయం థ్రెషోల్డ్: 1, వైఫల్యం థ్రెషోల్డ్: 3):

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

సిఫార్సులు

1. HTTP ఎండ్‌పాయింట్‌తో మైక్రోసర్వీస్‌ల కోసం (REST, మొదలైనవి) ఎల్లప్పుడూ సంసిద్ధత ప్రోబ్‌ను నిర్వచించండి, అప్లికేషన్ (పాడ్) ట్రాఫిక్‌ని అంగీకరించడానికి సిద్ధంగా ఉందో లేదో తనిఖీ చేస్తుంది.
2. సంసిద్ధత ప్రోబ్‌ని నిర్ధారించుకోండి వాస్తవ వెబ్ సర్వర్ పోర్ట్ లభ్యతను కవర్ చేస్తుంది:
   • "అడ్మిన్" లేదా "మేనేజ్‌మెంట్" (ఉదాహరణకు, 9090) అని పిలువబడే పరిపాలనా ప్రయోజనాల కోసం పోర్ట్‌లను ఉపయోగించడం readinessProbe, ప్రాథమిక HTTP పోర్ట్ (8080 వంటిది) ట్రాఫిక్‌ని అంగీకరించడానికి సిద్ధంగా ఉంటే మాత్రమే ఎండ్‌పాయింట్ OK తిరిగి వస్తుందని నిర్ధారించుకోండి*;

     *జలండోలో ఇది జరగని ఒక కేసు గురించి నాకు తెలుసు, అనగా. readinessProbe నేను "నిర్వహణ" పోర్ట్‌ను తనిఖీ చేసాను, కానీ కాష్‌ను లోడ్ చేయడంలో సమస్యల కారణంగా సర్వర్ పనిచేయడం ప్రారంభించలేదు.

   • ప్రత్యేక పోర్ట్‌కి సంసిద్ధత ప్రోబ్‌ను జోడించడం వలన ప్రధాన పోర్ట్‌పై ఓవర్‌లోడ్ ఆరోగ్య తనిఖీలో ప్రతిబింబించబడదు (అంటే సర్వర్‌లోని థ్రెడ్ పూల్ నిండి ఉంది, కానీ ఆరోగ్య తనిఖీ ఇప్పటికీ ప్రతిదీ సరిగ్గా ఉందని చూపిస్తుంది. )
3. అని నిర్ధారించుకోండి సంసిద్ధత ప్రోబ్ డేటాబేస్ ప్రారంభీకరణ/మైగ్రేషన్‌ని అనుమతిస్తుంది;
   • దీన్ని సాధించడానికి సులభమైన మార్గం, ప్రారంభించడం పూర్తయిన తర్వాత మాత్రమే HTTP సర్వర్‌ని సంప్రదించడం (ఉదాహరణకు, దీని నుండి డేటాబేస్‌ను తరలించడం ఫ్లైవే మరియు మొదలైనవి); అంటే, ఆరోగ్య తనిఖీ స్థితిని మార్చడానికి బదులుగా, డేటాబేస్ మైగ్రేషన్ పూర్తయ్యే వరకు వెబ్ సర్వర్‌ను ప్రారంభించవద్దు*.

     * మీరు పాడ్ వెలుపల init కంటైనర్‌ల నుండి డేటాబేస్ మైగ్రేషన్‌లను కూడా అమలు చేయవచ్చు. నేను ఇప్పటికీ స్వీయ-నియంత్రణ అనువర్తనాలకు అభిమానిని, అంటే, బాహ్య సమన్వయం లేకుండా డేటాబేస్‌ను కావలసిన స్థితికి ఎలా తీసుకురావాలో అప్లికేషన్ కంటైనర్‌కు తెలుసు.

4. ఉపయోగం httpGet సాధారణ ఆరోగ్య తనిఖీ ముగింపు పాయింట్ల ద్వారా సంసిద్ధత తనిఖీల కోసం (ఉదాహరణకు, /health).
5. డిఫాల్ట్ చెక్ పారామితులను అర్థం చేసుకోండి (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • డిఫాల్ట్ ఎంపికలు అంటే పాడ్ అవుతుంది సిద్ధంగా లేదు సుమారు 30 సెకన్ల తర్వాత (3 విఫలమైన తెలివి తనిఖీలు).
6. సాధారణ ట్రాఫిక్ నుండి ఆరోగ్యం మరియు కొలమానాల నిర్వహణను వేరు చేయడానికి సాంకేతిక స్టాక్ (ఉదా. జావా/స్ప్రింగ్) అనుమతించినట్లయితే "అడ్మిన్" లేదా "నిర్వహణ" కోసం ప్రత్యేక పోర్ట్‌ను ఉపయోగించండి:
   • కానీ పాయింట్ 2 గురించి మర్చిపోవద్దు.
7. అవసరమైతే, కాష్‌ను వేడెక్కడానికి/లోడ్ చేయడానికి మరియు కంటైనర్ వేడెక్కే వరకు 503 స్థితి కోడ్‌ను అందించడానికి సంసిద్ధత ప్రోబ్‌ను ఉపయోగించవచ్చు:
   • మీరు కొత్త చెక్‌ని చదవమని కూడా నేను సిఫార్సు చేస్తున్నాను startupProbe, వెర్షన్ 1.16లో కనిపించింది (మేము దాని గురించి రష్యన్ భాషలో వ్రాసాము ఇక్కడ - సుమారు అనువాదం.).

జాగ్రత్తలు

1. బాహ్య డిపెండెన్సీలపై ఆధారపడవద్దు (డేటా గిడ్డంగులు వంటివి) సంసిద్ధత/జీవిత పరీక్షలను అమలు చేస్తున్నప్పుడు - ఇది క్యాస్కేడింగ్ వైఫల్యాలకు దారి తీస్తుంది:
   • ఉదాహరణగా, ఒక పోస్ట్‌గ్రెస్ డేటాబేస్ ఆధారంగా 10 పాడ్‌లతో స్టేట్‌ఫుల్ REST సేవను తీసుకుందాం: చెక్ DBకి పని చేసే కనెక్షన్‌పై ఆధారపడి ఉన్నప్పుడు, నెట్‌వర్క్/DB వైపు జాప్యం జరిగితే మొత్తం 10 పాడ్‌లు విఫలం కావచ్చు - సాధారణంగా ఇది అన్ని ముగుస్తుంది దాని కంటే దారుణంగా;
   • స్ప్రింగ్ డేటా డిఫాల్ట్‌గా డేటాబేస్ కనెక్షన్‌ని తనిఖీ చేస్తుందని దయచేసి గమనించండి*;

     * ఇది స్ప్రింగ్ డేటా రెడిస్ యొక్క డిఫాల్ట్ ప్రవర్తన (కనీసం ఇది నేను చివరిసారి తనిఖీ చేసాను), ఇది "విపత్తు" వైఫల్యానికి దారితీసింది: రెడిస్ కొద్దికాలం పాటు అందుబాటులో లేనప్పుడు, అన్ని పాడ్‌లు "క్రాష్" అయ్యాయి.

   • ఈ కోణంలో "బాహ్య" అనేది అదే అప్లికేషన్‌లోని ఇతర పాడ్‌లను కూడా సూచిస్తుంది, అంటే, క్యాస్కేడింగ్ క్రాష్‌లను నివారించడానికి చెక్ అదే క్లస్టర్‌లోని ఇతర పాడ్‌ల స్థితిపై ఆధారపడి ఉండకూడదు:
     • డిస్ట్రిబ్యూటెడ్ స్టేట్‌తో అప్లికేషన్‌లకు ఫలితాలు మారవచ్చు (ఉదాహరణకు, పాడ్‌లలో ఇన్-మెమరీ కాషింగ్).
2. లైవ్‌నెస్ ప్రోబ్‌ని ఉపయోగించవద్దు పాడ్‌ల కోసం (మినహాయింపులు అవి నిజంగా అవసరమైనప్పుడు మరియు వాటి ఉపయోగం యొక్క ప్రత్యేకతలు మరియు పరిణామాల గురించి మీకు పూర్తిగా తెలుసు):
   • లైవ్‌నెస్ ప్రోబ్ హ్యాంగ్ చేయబడిన కంటైనర్‌లను పునరుద్ధరించడంలో సహాయపడుతుంది, కానీ మీ అప్లికేషన్‌పై మీకు పూర్తి నియంత్రణ ఉన్నందున, హ్యాంగ్ ప్రాసెస్‌లు మరియు డెడ్‌లాక్‌లు వంటివి ఆదర్శంగా జరగకూడదు: అప్లికేషన్‌ను ఉద్దేశపూర్వకంగా క్రాష్ చేసి, మునుపటి స్థిరమైన స్థితికి తీసుకురావడం ఉత్తమ ప్రత్యామ్నాయం;
   • విఫలమైన లైవ్‌నెస్ ప్రోబ్ కంటైనర్‌ను పునఃప్రారంభించేలా చేస్తుంది, తద్వారా లోడింగ్-సంబంధిత లోపాల యొక్క పరిణామాలను మరింత తీవ్రతరం చేస్తుంది: కంటైనర్‌ను పునఃప్రారంభించడం వలన పనికిరాని సమయం ఏర్పడుతుంది (కనీసం అప్లికేషన్ స్టార్టప్ వ్యవధి వరకు, 30-బేసి సెకన్లు) కొత్త ఎర్రర్‌లకు కారణమవుతుంది , ఇతర కంటైనర్లపై లోడ్ పెంచడం మరియు వారి వైఫల్యం యొక్క సంభావ్యతను పెంచడం మొదలైనవి;
   • లైవ్‌నెస్ చెక్‌లు బాహ్య డిపెండెన్సీతో కలిపి అత్యంత చెత్త కలయిక, క్యాస్కేడింగ్ వైఫల్యాలను బెదిరించడం: డేటాబేస్ వైపు కొంచెం ఆలస్యం చేస్తే మీ అన్ని కంటైనర్‌లు పునఃప్రారంభించబడతాయి!
3. సజీవత మరియు సంసిద్ధత తనిఖీల పారామితులు భిన్నంగా ఉండాలి:
   • మీరు అదే ఆరోగ్య తనిఖీతో లైవ్‌నెస్ ప్రోబ్‌ను ఉపయోగించవచ్చు, కానీ అధిక ప్రతిస్పందన థ్రెషోల్డ్ (failureThreshold), ఉదాహరణకు, స్థితిని కేటాయించండి సిద్ధంగా లేదు 3 ప్రయత్నాల తర్వాత మరియు 10 ప్రయత్నాల తర్వాత లైవ్‌నెస్ ప్రోబ్ విఫలమైందని పరిగణించండి;
4. కార్యనిర్వాహక తనిఖీలను ఉపయోగించవద్దు, అవి జోంబీ ప్రక్రియల రూపానికి దారితీసే తెలిసిన సమస్యలతో సంబంధం కలిగి ఉన్నందున:
   • వివరాలు: చూడండి డేటాడాగ్ నిపుణులచే ప్రదర్శన.

సారాంశం

• ట్రాఫిక్‌ని స్వీకరించడానికి పాడ్ ఎప్పుడు సిద్ధంగా ఉందో తెలుసుకోవడానికి సంసిద్ధత ప్రోబ్‌లను ఉపయోగించండి.
• లైవ్‌నెస్ ప్రోబ్స్ నిజంగా అవసరమైనప్పుడు మాత్రమే వాటిని ఉపయోగించండి.
• సంసిద్ధత/లైవ్‌నెస్ ప్రోబ్స్ యొక్క సరికాని ఉపయోగం తగ్గిన లభ్యత మరియు క్యాస్కేడింగ్ వైఫల్యాలకు దారి తీస్తుంది.

అంశంపై అదనపు పదార్థాలు

• కుబెర్నెటెస్ డాక్స్: లైవ్‌నెస్ మరియు రెడీనెస్ ప్రోబ్స్‌ని కాన్ఫిగర్ చేయండి;
• కుబెర్నెటెస్ లైవ్‌నెస్ మరియు రెడీనెస్ ప్రోబ్స్ రీవిజిటెడ్: మరొక పాదంలో మిమ్మల్ని మీరు కాల్చుకోవడం ఎలా నివారించాలి;
• NRE ల్యాబ్స్ ఔటేజ్ పోస్ట్-మార్టం (అతను కూడా livenessProbe గురించి మాట్లాడతాడు).

1-2019-09 నుండి నవీకరణ నంబర్ 29

డేటాబేస్ మైగ్రేషన్ కోసం init కంటైనర్‌ల గురించి: ఫుట్‌నోట్ జోడించబడింది.

EJ నాకు గుర్తు చేసింది PDB గురించి: లైవ్‌నెస్ చెక్‌ల సమస్యల్లో ఒకటి పాడ్‌ల మధ్య సమన్వయం లేకపోవడం. కుబెర్నెటెస్ కలిగి ఉంది పాడ్ డిస్ట్రప్షన్ బడ్జెట్‌లు (PDB) అప్లికేషన్ అనుభవించగల ఏకకాల వైఫల్యాల సంఖ్యను పరిమితం చేయడానికి, అయితే తనిఖీలు PDBని పరిగణనలోకి తీసుకోవు. ఆదర్శవంతంగా, మేము K8 లకు "ఒక పాడ్ పరీక్ష విఫలమైతే దాన్ని రీస్టార్ట్ చేయమని చెప్పవచ్చు, కానీ విషయాలు మరింత దిగజారకుండా ఉండేందుకు వాటన్నింటినీ రీస్టార్ట్ చేయవద్దు."

బ్రయాన్ దానిని ఖచ్చితంగా ఉంచాడు: “మీకు సరిగ్గా తెలిసినప్పుడు లైవ్‌నెస్ ప్రోబింగ్‌ని ఉపయోగించండి అప్లికేషన్‌ను చంపడం ఉత్తమమైన పని"(మళ్ళీ, దూరంగా ఉండకండి).

2-2019-09 నుండి నవీకరణ నంబర్ 29

ఉపయోగం ముందు డాక్యుమెంటేషన్ చదవడం గురించి: నేను సంబంధిత అభ్యర్థనను సృష్టించాను (ఫీచర్ అభ్యర్థన) లైవ్‌నెస్ ప్రోబ్స్ గురించి డాక్యుమెంటేషన్ జోడించడానికి.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• «కుబెర్నెటెస్: పాడ్ లైఫ్";
• «Google ప్రకారం కంటైనర్‌లను ఉపయోగించడం కోసం 7 ఉత్తమ పద్ధతులు";
• «కంటైనర్-ఆధారిత అప్లికేషన్‌లను రూపొందించడానికి 7 సూత్రాలు".

మూలం: www.habr.com