కుబెర్నెట్‌లను ఉపయోగిస్తున్నప్పుడు 10 సాధారణ తప్పులు

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

కుబెర్నెట్‌లను ఉపయోగించిన సంవత్సరాల్లో, మేము పెద్ద సంఖ్యలో క్లస్టర్‌లతో (నిర్వహించబడేవి మరియు నిర్వహించబడనివి - GCP, AWS మరియు అజూర్‌లో) పని చేసాము. కాలక్రమేణా, కొన్ని తప్పులు నిరంతరం పునరావృతమవుతాయని మేము గమనించడం ప్రారంభించాము. అయితే, ఇందులో అవమానం లేదు: వాటిలో చాలా వరకు మనమే చేసాము!

వ్యాసం అత్యంత సాధారణ లోపాలను కలిగి ఉంది మరియు వాటిని ఎలా సరిదిద్దాలో కూడా పేర్కొంది.

1. వనరులు: అభ్యర్థనలు మరియు పరిమితులు

ఈ అంశం ఖచ్చితంగా దగ్గరి శ్రద్ధ మరియు జాబితాలో మొదటి స్థానానికి అర్హమైనది.

సాధారణంగా CPU అభ్యర్థన పూర్తిగా పేర్కొనబడలేదు లేదా చాలా తక్కువ విలువను కలిగి ఉంటుంది (ప్రతి నోడ్‌లో వీలైనన్ని ఎక్కువ పాడ్‌లను ఉంచడానికి). అందువలన, నోడ్స్ ఓవర్లోడ్ అవుతాయి. అధిక లోడ్ సమయంలో, నోడ్ యొక్క ప్రాసెసింగ్ పవర్ పూర్తిగా ఉపయోగించబడుతుంది మరియు నిర్దిష్ట పనిభారం అది "అభ్యర్థించిన" దానిని మాత్రమే పొందుతుంది CPU థ్రోట్లింగ్. ఇది పెరిగిన అప్లికేషన్ జాప్యం, గడువు ముగియడం మరియు ఇతర అసహ్యకరమైన పరిణామాలకు దారితీస్తుంది. (మా ఇతర ఇటీవలి అనువాదంలో దీని గురించి మరింత చదవండి: "కుబెర్నెట్స్‌లో CPU పరిమితులు మరియు దూకుడు థ్రోట్లింగ్"- సుమారు. అనువాదం.)

ఉత్తమ కృషి (అత్యంత కాదు సిఫార్సు చేయబడింది):

resources: {}

చాలా తక్కువ CPU అభ్యర్థన (అత్యంత కాదు సిఫార్సు చేయబడింది):

   resources:
      Requests:
        cpu: "1m"

మరోవైపు, నోడ్ ప్రాసెసర్ పూర్తిగా లోడ్ కానప్పటికీ, CPU పరిమితి ఉండటం వలన పాడ్‌ల ద్వారా క్లాక్ సైకిల్‌లను అసమంజసంగా దాటవేయవచ్చు. మళ్ళీ, ఇది పెరిగిన జాప్యానికి దారి తీస్తుంది. పారామీటర్ చుట్టూ వివాదం కొనసాగుతోంది CPU CFS కోటా Linux కెర్నల్ మరియు CPUలో సెట్ పరిమితులపై ఆధారపడి థ్రోట్లింగ్, అలాగే CFS కోటాను నిలిపివేయడం... అయ్యో, CPU పరిమితులు పరిష్కరించగలిగే దానికంటే ఎక్కువ సమస్యలను కలిగిస్తాయి. దీని గురించి మరింత సమాచారం క్రింది లింక్‌లో చూడవచ్చు.

అధిక ఎంపిక (అధిక నిబద్ధత) జ్ఞాపకశక్తి సమస్యలు పెద్ద సమస్యలకు దారితీస్తాయి. CPU పరిమితిని చేరుకోవడం గడియార చక్రాలను దాటవేయవలసి ఉంటుంది, అయితే మెమరీ పరిమితిని చేరుకోవడం పాడ్‌ను చంపేస్తుంది. మీరు ఎప్పుడైనా గమనించారా OOMkill? అవును, మేము దాని గురించి మాట్లాడుతున్నాము.

మీరు ఇలా జరిగే సంభావ్యతను తగ్గించాలనుకుంటున్నారా? మెమరీ రిక్వెస్ట్‌ను పరిమితికి సెట్ చేయడం ద్వారా మెమరీని ఎక్కువగా కేటాయించవద్దు మరియు గ్యారెంటీడ్ QoS (క్వాలిటీ ఆఫ్ సర్వీస్)ని ఉపయోగించవద్దు (దిగువ ఉదాహరణలో వలె). లో దీని గురించి మరింత చదవండి హెన్నింగ్ జాకబ్స్ ప్రదర్శనలు (జలాండోలో లీడ్ ఇంజనీర్).

పగిలిపోయే (OOMkilled పొందడానికి అధిక అవకాశం):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

హామీ:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

వనరులను సెటప్ చేసేటప్పుడు సమర్థవంతంగా ఏది సహాయపడుతుంది?

సహాయంతో కొలమానాలు-సర్వర్ మీరు పాడ్‌ల ద్వారా ప్రస్తుత CPU వనరుల వినియోగం మరియు మెమరీ వినియోగాన్ని చూడవచ్చు (మరియు వాటిలోని కంటైనర్‌లు). చాలా మటుకు, మీరు దీన్ని ఇప్పటికే ఉపయోగిస్తున్నారు. కింది ఆదేశాలను అమలు చేయండి:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

అయితే, అవి ప్రస్తుత వినియోగాన్ని మాత్రమే చూపుతాయి. ఇది పరిమాణం యొక్క క్రమం గురించి మీకు స్థూలమైన ఆలోచనను ఇస్తుంది, కానీ చివరికి మీకు ఇది అవసరం కాలక్రమేణా కొలమానాలలో మార్పుల చరిత్ర (ఇలాంటి ప్రశ్నలకు సమాధానమివ్వడానికి: "పీక్ CPU లోడ్ ఏమిటి?", "నిన్న ఉదయం లోడ్ ఏమిటి?", మొదలైనవి). దీని కోసం మీరు ఉపయోగించవచ్చు ప్రోమేతియస్, డేటాడాగ్ మరియు ఇతర సాధనాలు. వారు కొలమానాలు-సర్వర్ నుండి కొలమానాలను పొందుతారు మరియు వాటిని నిల్వ చేస్తారు మరియు వినియోగదారు వాటిని ప్రశ్నించవచ్చు మరియు తదనుగుణంగా వాటిని ప్లాట్ చేయవచ్చు.

లంబ పోడ్ ఆటోస్కేలర్ ఇది అనుమతిస్తుంది ఆటోమేట్ ఈ ప్రక్రియ. ఇది CPU మరియు మెమరీ వినియోగ చరిత్రను ట్రాక్ చేస్తుంది మరియు ఈ సమాచారం ఆధారంగా కొత్త అభ్యర్థనలు మరియు పరిమితులను సెటప్ చేస్తుంది.

కంప్యూటింగ్ శక్తిని సమర్ధవంతంగా ఉపయోగించడం అంత తేలికైన పని కాదు. ఇది ఎల్లప్పుడూ Tetris ఆడటం వంటిది. మీరు తక్కువ సగటు వినియోగంతో (~10% చెప్పండి) కంప్యూట్ పవర్ కోసం చాలా ఎక్కువ చెల్లిస్తున్నట్లయితే, AWS Fargate లేదా Virtual Kubelet ఆధారంగా ఉత్పత్తులను చూడాలని మేము సిఫార్సు చేస్తున్నాము. అవి సర్వర్‌లెస్/పే-పర్-యూసేజ్ బిల్లింగ్ మోడల్‌లో నిర్మించబడ్డాయి, అటువంటి పరిస్థితుల్లో ఇది చౌకగా మారవచ్చు.

2. సజీవత మరియు సంసిద్ధత ప్రోబ్స్

డిఫాల్ట్‌గా, కుబెర్నెట్స్‌లో లైవ్‌నెస్ మరియు రెడీనెస్ చెక్‌లు ప్రారంభించబడవు. మరియు కొన్నిసార్లు వాటిని ఆన్ చేయడం మర్చిపోతారు...

కానీ ప్రాణాంతకమైన లోపం సంభవించినప్పుడు మీరు సేవ పునఃప్రారంభాన్ని ఎలా ప్రారంభించగలరు? మరియు ట్రాఫిక్‌ని అంగీకరించడానికి పాడ్ సిద్ధంగా ఉందని లోడ్ బ్యాలెన్సర్‌కి ఎలా తెలుసు? లేదా అది మరింత ట్రాఫిక్‌ను నిర్వహించగలదా?

ఈ పరీక్షలు తరచుగా ఒకదానితో ఒకటి గందరగోళం చెందుతాయి:

• జీవనం - "మనుగడ" తనిఖీ, ఇది విఫలమైతే పాడ్‌ను పునఃప్రారంభిస్తుంది;
• సంసిద్ధతను - సంసిద్ధతను తనిఖీ చేయండి, అది విఫలమైతే, అది కుబెర్నెట్స్ సేవ నుండి పాడ్‌ను డిస్‌కనెక్ట్ చేస్తుంది (దీనిని ఉపయోగించి తనిఖీ చేయవచ్చు kubectl get endpoints) మరియు తదుపరి తనిఖీ విజయవంతంగా పూర్తయ్యే వరకు ట్రాఫిక్ దానికి చేరుకోదు.

ఈ రెండు తనిఖీలు పాడ్ యొక్క మొత్తం జీవిత చక్రంలో ప్రదర్శించబడింది. ఇది చాలా ముఖ్యమైనది.

ఒక సాధారణ దురభిప్రాయం ఏమిటంటే, సంసిద్ధత ప్రోబ్స్ స్టార్టప్‌లో మాత్రమే అమలు చేయబడతాయి, తద్వారా పాడ్ సిద్ధంగా ఉందని బ్యాలెన్సర్‌కు తెలుసు (Ready) మరియు ట్రాఫిక్‌ను ప్రాసెస్ చేయడం ప్రారంభించవచ్చు. అయితే, ఇది వారి ఉపయోగం కోసం ఎంపికలలో ఒకటి మాత్రమే.

మరొకటి పాడ్‌లో ట్రాఫిక్ అధికంగా ఉందని కనుగొనే అవకాశం మరియు దానిని ఓవర్‌లోడ్ చేస్తుంది (లేదా పాడ్ రిసోర్స్-ఇంటెన్సివ్ లెక్కలను నిర్వహిస్తుంది). ఈ సందర్భంలో, సంసిద్ధత తనిఖీ సహాయపడుతుంది పాడ్‌పై భారాన్ని తగ్గించి "చల్లగా" చేయండి. భవిష్యత్తులో సంసిద్ధత తనిఖీని విజయవంతంగా పూర్తి చేయడం అనుమతిస్తుంది మళ్లీ పాడ్‌పై భారాన్ని పెంచండి. ఈ సందర్భంలో (సన్నద్ధత పరీక్ష విఫలమైతే), లైవ్‌నెస్ పరీక్ష వైఫల్యం చాలా ప్రతికూలంగా ఉంటుంది. ఆరోగ్యకరమైన మరియు కష్టపడి పనిచేసే పాడ్‌ను ఎందుకు పునఃప్రారంభించాలి?

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

సాధారణ డిపెండెన్సీలు విఫలమైనప్పుడు రెండు రకాల తనిఖీలు విఫలం కాకూడదు, లేకుంటే ఇది అన్ని పాడ్‌ల క్యాస్కేడింగ్ (హిమపాతం లాంటి) వైఫల్యానికి దారి తీస్తుంది. వేరే పదాల్లో, మిమ్మల్ని మీరు హాని చేసుకోకండి.

3. ప్రతి HTTP సేవ కోసం లోడ్ బ్యాలన్సర్

చాలా మటుకు, మీరు బయటి ప్రపంచానికి ఫార్వార్డ్ చేయాలనుకుంటున్న HTTP సేవలను మీ క్లస్టర్‌లో కలిగి ఉంటారు.

మీరు సేవను ఇలా తెరిస్తే type: LoadBalancer, దాని కంట్రోలర్ (సర్వీస్ ప్రొవైడర్‌పై ఆధారపడి) బాహ్య లోడ్‌బ్యాలెన్సర్‌ను అందిస్తుంది మరియు చర్చలు జరుపుతుంది (తప్పనిసరిగా L7లో అమలు చేయబడదు, కానీ L4లో కూడా), మరియు ఇది ఖర్చును ప్రభావితం చేయవచ్చు (బాహ్య స్టాటిక్ IPv4 చిరునామా, కంప్యూటింగ్ పవర్, ప్రతి సెకండ్ బిల్లింగ్ ) అటువంటి వనరులను పెద్ద సంఖ్యలో సృష్టించాల్సిన అవసరం కారణంగా.

ఈ సందర్భంలో, ఒక బాహ్య లోడ్ బ్యాలెన్సర్‌ను ఉపయోగించడం చాలా తార్కికం, సేవలను తెరవడం type: NodePort. లేదా ఇంకా మంచిది, ఇలాంటివి విస్తరించండి nginx-ఇంగ్రెస్-కంట్రోలర్ (లేదా ట్రాఫిక్), ఎవరు మాత్రమే ఉంటారు నోడ్పోర్ట్ ఎండ్‌పాయింట్ బాహ్య లోడ్ బ్యాలెన్సర్‌తో అనుబంధించబడి, క్లస్టర్‌లో ట్రాఫిక్‌ని మార్గనిర్దేశం చేస్తుంది ప్రవేశం-కుబెర్నెట్స్ వనరులు.

ఒకదానితో ఒకటి పరస్పర చర్య చేసే ఇతర ఇంట్రా-క్లస్టర్ (సూక్ష్మ) సేవలు వంటి సేవలను ఉపయోగించి “కమ్యూనికేట్” చేయవచ్చు ClusterIP మరియు DNS ద్వారా అంతర్నిర్మిత సర్వీస్ డిస్కవరీ మెకానిజం. వారి పబ్లిక్ DNS/IPని ఉపయోగించవద్దు, ఇది జాప్యాన్ని ప్రభావితం చేస్తుంది మరియు క్లౌడ్ సేవల ధరను పెంచుతుంది.

4. దాని లక్షణాలను పరిగణనలోకి తీసుకోకుండా క్లస్టర్‌ను ఆటోస్కేలింగ్ చేయడం

క్లస్టర్‌కి నోడ్‌లను జోడించేటప్పుడు మరియు వాటిని తీసివేయేటప్పుడు, మీరు ఆ నోడ్‌లలో CPU వినియోగం వంటి కొన్ని ప్రాథమిక కొలమానాలపై ఆధారపడకూడదు. పాడ్ ప్లానింగ్ తప్పనిసరిగా చాలా మందిని పరిగణనలోకి తీసుకోవాలి పరిమితులు, పాడ్/నోడ్ అనుబంధం, మచ్చలు మరియు సహనం, వనరుల అభ్యర్థనలు, QoS మొదలైనవి. ఈ సూక్ష్మ నైపుణ్యాలను పరిగణనలోకి తీసుకోని బాహ్య ఆటోస్కేలర్‌ను ఉపయోగించడం సమస్యలకు దారి తీస్తుంది.

ఒక నిర్దిష్ట పాడ్ షెడ్యూల్ చేయబడాలని ఊహించండి, అయితే అందుబాటులో ఉన్న మొత్తం CPU పవర్ అభ్యర్థించబడింది/విడదీయబడింది మరియు పాడ్ ఒక స్థితిలో చిక్కుకుపోతాడు Pending. బాహ్య ఆటోస్కేలర్ సగటు ప్రస్తుత CPU లోడ్‌ను చూస్తుంది (అభ్యర్థించినది కాదు) మరియు విస్తరణను ప్రారంభించదు (స్కేల్-అవుట్) - మరొక నోడ్‌ని జోడించదు. ఫలితంగా, ఈ పాడ్ షెడ్యూల్ చేయబడదు.

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

కుబెర్నెట్స్ కమ్యూనిటీలో బాగా ప్రాచుర్యం పొందింది క్లస్టర్-ఆటోస్కేలర్. ఇది క్లస్టర్‌పై నడుస్తుంది, ప్రధాన క్లౌడ్ ప్రొవైడర్ల నుండి APIలకు మద్దతు ఇస్తుంది, అన్ని పరిమితులను పరిగణనలోకి తీసుకుంటుంది మరియు పై సందర్భాలలో స్కేల్ చేయవచ్చు. ఇది అన్ని సెట్ పరిమితులను కొనసాగిస్తూ స్కేల్-ఇన్ చేయగలదు, తద్వారా డబ్బు ఆదా అవుతుంది (లేకపోతే ఇది ఉపయోగించని సామర్థ్యంపై ఖర్చు చేయబడుతుంది).

5. IAM/RBAC సామర్థ్యాలను నిర్లక్ష్యం చేయడం

నిరంతర రహస్యాలతో IAM వినియోగదారులను ఉపయోగించకుండా జాగ్రత్త వహించండి యంత్రాలు మరియు అప్లికేషన్లు. పాత్రలు మరియు సేవా ఖాతాలను ఉపయోగించి తాత్కాలిక ప్రాప్యతను నిర్వహించండి (సేవా ఖాతాలు).

అప్లికేషన్ కాన్ఫిగరేషన్‌లో యాక్సెస్ కీలు (మరియు రహస్యాలు) హార్డ్‌కోడ్ చేయబడి ఉంటాయి, అలాగే క్లౌడ్ IAMకి యాక్సెస్ ఉన్నప్పటికీ రహస్యాల భ్రమణాన్ని విస్మరించడాన్ని మేము తరచుగా ఎదుర్కొంటాము. తగిన చోట వినియోగదారులకు బదులుగా IAM పాత్రలు మరియు సేవా ఖాతాలను ఉపయోగించండి.

kube2iam గురించి మరచిపోయి, సేవా ఖాతాల కోసం నేరుగా IAM పాత్రలకు వెళ్లండి (లో వివరించిన విధంగా అదే పేరు యొక్క గమనిక స్టేపాన్ వ్రానీ):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ఒక ఉల్లేఖనం. అంత కష్టం కాదు, సరియైనదా?

అలాగే, సేవా ఖాతాలు మరియు ఉదాహరణ ప్రొఫైల్‌ల అధికారాలను మంజూరు చేయవద్దు admin и cluster-adminవారికి అది అవసరం లేకపోతే. ఇది అమలు చేయడం కొంచెం కష్టం, ముఖ్యంగా RBAC K8 లలో, కానీ ఖచ్చితంగా కృషికి విలువైనది.

6. పాడ్‌ల కోసం ఆటోమేటిక్ యాంటీ-అఫినిటీపై ఆధారపడవద్దు

మీరు నోడ్‌లో కొంత విస్తరణ యొక్క మూడు ప్రతిరూపాలను కలిగి ఉన్నారని ఊహించండి. నోడ్ వస్తుంది, మరియు దానితో పాటు అన్ని ప్రతిరూపాలు. అసహ్యకరమైన పరిస్థితి, సరియైనదా? అయితే అన్ని ప్రతిరూపాలు ఒకే నోడ్‌పై ఎందుకు ఉన్నాయి? కుబెర్నెట్స్ అధిక లభ్యతను (HA) అందించాలి కదా?!

దురదృష్టవశాత్తు, Kubernetes షెడ్యూలర్, దాని స్వంత చొరవతో, ప్రత్యేక ఉనికి యొక్క నియమాలకు అనుగుణంగా లేదు (వ్యతిరేక అనుబంధం) పాడ్‌ల కోసం. వారు స్పష్టంగా పేర్కొనబడాలి:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

అంతే. ఇప్పుడు పాడ్‌లు వేర్వేరు నోడ్‌లలో షెడ్యూల్ చేయబడతాయి (ఈ పరిస్థితి షెడ్యూలింగ్ సమయంలో మాత్రమే తనిఖీ చేయబడుతుంది, కానీ వాటి ఆపరేషన్ సమయంలో కాదు - అందుకే requiredDuringSchedulingIgnoredDuringExecution).

ఇక్కడ మనం మాట్లాడుతున్నాం podAntiAffinity వివిధ నోడ్లపై: topologyKey: "kubernetes.io/hostname", - మరియు వివిధ లభ్యత జోన్ల గురించి కాదు. పూర్తి స్థాయి HAని అమలు చేయడానికి, మీరు ఈ అంశాన్ని లోతుగా త్రవ్వాలి.

7. PodDisruptionBdgetsను విస్మరించడం

మీరు కుబెర్నెటెస్ క్లస్టర్‌లో ఉత్పత్తి భారాన్ని కలిగి ఉన్నారని ఊహించండి. క్రమానుగతంగా, నోడ్‌లు మరియు క్లస్టర్‌ను కూడా అప్‌డేట్ చేయాలి (లేదా ఉపసంహరించుకోవాలి). PodDisruptionBudget (PDB) అనేది క్లస్టర్ అడ్మినిస్ట్రేటర్‌లు మరియు వినియోగదారుల మధ్య సేవా హామీ ఒప్పందం లాంటిది.

PDB నోడ్‌ల కొరత కారణంగా సర్వీస్ అంతరాయాలను నివారించడానికి మిమ్మల్ని అనుమతిస్తుంది:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

ఈ ఉదాహరణలో, మీరు క్లస్టర్ యొక్క వినియోగదారుగా, నిర్వాహకులకు ఇలా చెప్పండి: "హే, నా దగ్గర జూకీపర్ సేవ ఉంది, మీరు ఏమి చేసినా సరే, ఈ సేవ యొక్క కనీసం 2 ప్రతిరూపాలు ఎల్లప్పుడూ అందుబాటులో ఉండాలని నేను కోరుకుంటున్నాను."

మీరు దీని గురించి మరింత చదువుకోవచ్చు ఇక్కడ.

8. ఒక సాధారణ క్లస్టర్‌లో బహుళ వినియోగదారులు లేదా పరిసరాలు

కుబెర్నెటెస్ నేమ్‌స్పేస్‌లు (నేమ్‌స్పేస్‌లు) బలమైన ఇన్సులేషన్ అందించవద్దు.

ఒక సాధారణ దురభిప్రాయం ఏమిటంటే, మీరు నాన్-ప్రోడ్ లోడ్‌ను ఒక నేమ్‌స్పేస్‌లోకి మరియు ప్రోడ్ లోడ్‌ను మరొక నేమ్‌స్పేస్‌లోకి అమలు చేస్తే, అప్పుడు అవి ఒకరినొకరు ఏ విధంగానూ ప్రభావితం చేయరు... అయినప్పటికీ, వనరుల అభ్యర్థనలు/పరిమితులు, కోటాలను సెట్ చేయడం మరియు ప్రాధాన్యతా తరగతులను సెట్ చేయడం ద్వారా నిర్దిష్ట స్థాయి ఐసోలేషన్‌ను సాధించవచ్చు. డేటా ప్లేన్‌లో కొంత “భౌతిక” ఐసోలేషన్ అనుబంధాలు, సహనాలను, మచ్చలు (లేదా నోడ్‌సెలెక్టర్లు) ద్వారా అందించబడుతుంది, అయితే అలాంటి విభజన చాలా ఎక్కువ కష్టం అమలు.

ఒకే క్లస్టర్‌లో రెండు రకాల వర్క్‌లోడ్‌లను కలపాల్సిన అవసరం ఉన్నవారు సంక్లిష్టతను ఎదుర్కోవలసి ఉంటుంది. అటువంటి అవసరం లేనట్లయితే, మరియు మీరు ఒకదాన్ని కలిగి ఉండగలరు మరో క్లస్టర్ (పబ్లిక్ క్లౌడ్‌లో చెప్పండి), అలా చేయడం మంచిది. ఇది చాలా ఎక్కువ స్థాయి ఇన్సులేషన్‌ను సాధిస్తుంది.

9. బాహ్య ట్రాఫిక్ విధానం: క్లస్టర్

క్లస్టర్ లోపల ట్రాఫిక్ అంతా NodePort వంటి సేవ ద్వారా వస్తుందని మేము చాలా తరచుగా చూస్తాము, దీని కోసం డిఫాల్ట్ విధానం సెట్ చేయబడింది externalTrafficPolicy: Cluster... దాని అర్థం ఏమిటంటే నోడ్పోర్ట్ క్లస్టర్‌లోని ప్రతి నోడ్‌లో తెరిచి ఉంటుంది మరియు మీరు కోరుకున్న సేవ (పాడ్‌ల సెట్)తో పరస్పర చర్య చేయడానికి వాటిలో దేనినైనా ఉపయోగించవచ్చు.

అదే సమయంలో, పైన పేర్కొన్న NodePort సేవతో అనుబంధించబడిన నిజమైన పాడ్‌లు సాధారణంగా నిర్దిష్టంగా మాత్రమే అందుబాటులో ఉంటాయి ఈ నోడ్‌ల ఉపసమితి. మరో మాటలో చెప్పాలంటే, అవసరమైన పాడ్ లేని నోడ్‌కి నేను కనెక్ట్ చేస్తే, అది ట్రాఫిక్‌ను మరొక నోడ్‌కి ఫార్వార్డ్ చేస్తుంది, ఒక హాప్ జోడించడం మరియు పెరుగుతున్న జాప్యం (నోడ్‌లు వేర్వేరు లభ్యత జోన్‌లు/డేటా సెంటర్‌లలో ఉన్నట్లయితే, జాప్యం చాలా ఎక్కువగా ఉంటుంది; అదనంగా, ఎగ్రెస్ ట్రాఫిక్ ఖర్చులు పెరుగుతాయి).

మరోవైపు, నిర్దిష్ట కుబెర్నెట్స్ సేవకు పాలసీ సెట్ ఉంటే externalTrafficPolicy: Local, అప్పుడు అవసరమైన పాడ్‌లు నిజంగా అమలవుతున్న నోడ్‌లలో మాత్రమే NodePort తెరవబడుతుంది. స్థితిని తనిఖీ చేసే బాహ్య లోడ్ బ్యాలెన్సర్‌ను ఉపయోగిస్తున్నప్పుడు (ఆరోగ్య తనిఖీ) ముగింపు పాయింట్లు (ఇది ఎలా చేస్తుంది AWS ELB), అతను అవసరమైన నోడ్‌లకు మాత్రమే ట్రాఫిక్‌ను పంపుతుంది, ఇది జాప్యాలు, కంప్యూటింగ్ అవసరాలు, ఎగ్రెస్ బిల్లులపై ప్రయోజనకరమైన ప్రభావాన్ని చూపుతుంది (మరియు ఇంగితజ్ఞానం అదే నిర్దేశిస్తుంది).

మీరు ఇప్పటికే ఇలాంటివి వాడే అవకాశం ఎక్కువగా ఉంది ట్రాఫిక్ లేదా nginx-ఇంగ్రెస్-కంట్రోలర్ HTTP ఇన్‌గ్రెస్ ట్రాఫిక్‌ను రూట్ చేయడానికి నోడ్‌పోర్ట్ ఎండ్‌పాయింట్ (లేదా లోడ్‌బ్యాలెన్సర్, ఇది నోడ్‌పోర్ట్‌ను కూడా ఉపయోగిస్తుంది) మరియు ఈ ఎంపికను సెట్ చేయడం వలన అటువంటి అభ్యర్థనల కోసం జాప్యాన్ని గణనీయంగా తగ్గించవచ్చు.

В ఈ ప్రచురణ మీరు బాహ్య ట్రాఫిక్ విధానం, దాని ప్రయోజనాలు మరియు అప్రయోజనాలు గురించి మరింత తెలుసుకోవచ్చు.

10. క్లస్టర్‌లతో ముడిపడి ఉండకండి మరియు కంట్రోల్ ప్లేన్‌ను దుర్వినియోగం చేయవద్దు

ఇంతకుముందు, సర్వర్‌లను సరైన పేర్లతో పిలవడం ఆచారం: అంటోన్, HAL9000 మరియు Colossus... నేడు అవి యాదృచ్ఛికంగా రూపొందించబడిన ఐడెంటిఫైయర్‌ల ద్వారా భర్తీ చేయబడ్డాయి. అయినప్పటికీ, అలవాటు అలాగే ఉంది, మరియు ఇప్పుడు సరైన పేర్లు సమూహాలకు వెళ్తాయి.

ఒక సాధారణ కథనం (వాస్తవ సంఘటనల ఆధారంగా): ఇదంతా కాన్సెప్ట్ రుజువుతో ప్రారంభమైంది, కాబట్టి క్లస్టర్‌కు గర్వకారణమైన పేరు ఉంది పరీక్ష… సంవత్సరాలు గడిచాయి మరియు ఇది ఇప్పటికీ ఉత్పత్తిలో ఉపయోగించబడుతుంది మరియు ప్రతి ఒక్కరూ దానిని తాకడానికి భయపడతారు.

క్లస్టర్‌లు పెంపుడు జంతువులుగా మారడం గురించి సరదా ఏమీ లేదు, కాబట్టి ప్రాక్టీస్ చేస్తున్నప్పుడు వాటిని క్రమానుగతంగా తీసివేయమని మేము సిఫార్సు చేస్తున్నాము విపత్తు పునరుద్ధరణ (ఇది సహాయం చేస్తుంది గందరగోళ ఇంజనీరింగ్ - సుమారు అనువాదం.). అదనంగా, నియంత్రణ పొరపై పని చేయడం బాధించదు (నియంత్రణ విమానం). అతన్ని తాకడానికి భయపడటం మంచి సంకేతం కాదు. మొదలైనవి చనిపోయాడా? అబ్బాయిలు, మీరు నిజంగా ఇబ్బందుల్లో ఉన్నారు!

మరోవైపు, మీరు దానిని తారుమారు చేయడంతో దూరంగా ఉండకూడదు. సమయముతోపాటు నియంత్రణ పొర నెమ్మదిగా మారవచ్చు. చాలా మటుకు, పెద్ద సంఖ్యలో వస్తువులను తిప్పకుండానే సృష్టించబడటం దీనికి కారణం (డిఫాల్ట్ సెట్టింగ్‌లతో హెల్మ్‌ను ఉపయోగిస్తున్నప్పుడు సాధారణ పరిస్థితి, అందుకే కాన్ఫిగమ్‌లు/సీక్రెట్స్‌లో దాని స్థితి నవీకరించబడదు - ఫలితంగా, వేలాది వస్తువులు పేరుకుపోతాయి. నియంత్రణ లేయర్) లేదా kube-api ఆబ్జెక్ట్‌ల స్థిరమైన సవరణతో (ఆటోమేటిక్ స్కేలింగ్ కోసం, CI/CD కోసం, పర్యవేక్షణ కోసం, ఈవెంట్ లాగ్‌లు, కంట్రోలర్‌లు మొదలైనవి).

అదనంగా, నిర్వహించబడే కుబెర్నెట్స్ ప్రొవైడర్‌తో SLA/SLO ఒప్పందాలను తనిఖీ చేయాలని మరియు హామీలపై శ్రద్ధ వహించాలని మేము సిఫార్సు చేస్తున్నాము. విక్రేత హామీ ఇవ్వగలడు నియంత్రణ పొర లభ్యత (లేదా దాని ఉపభాగాలు), కానీ మీరు దానికి పంపే అభ్యర్థనల p99 ఆలస్యం కాదు. మరో మాటలో చెప్పాలంటే, మీరు ప్రవేశించవచ్చు kubectl get nodes, మరియు 10 నిమిషాల తర్వాత మాత్రమే సమాధానాన్ని స్వీకరించండి మరియు ఇది సేవా ఒప్పందం యొక్క నిబంధనలను ఉల్లంఘించదు.

11. బోనస్: తాజా ట్యాగ్‌ని ఉపయోగించడం

కానీ ఇది ఇప్పటికే క్లాసిక్. చాలా మంది చేదు అనుభవం నుండి నేర్చుకుని, ట్యాగ్‌ని ఉపయోగించడం మానేసినందున, ఇటీవల మేము ఈ టెక్నిక్‌ను చాలా తక్కువ తరచుగా చూశాము. :latest మరియు సంస్కరణలను పిన్ చేయడం ప్రారంభించింది. హుర్రే!

ECR ఇమేజ్ ట్యాగ్‌ల మార్పులేని స్థితిని నిర్వహిస్తుంది; ఈ విశేషమైన ఫీచర్‌తో మిమ్మల్ని మీరు పరిచయం చేసుకోవాలని మేము సిఫార్సు చేస్తున్నాము.

సారాంశం

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

మీరు వివిధ జట్ల యొక్క విజయవంతం కాని అనుభవాలతో పరిచయం పొందవచ్చు ఈ కథల సంపుటి హెన్నింగ్ జాకబ్స్ ద్వారా.

ఈ కథనంలో ఇవ్వబడిన లోపాల జాబితాకు జోడించాలనుకునే వారు Twitterలో మమ్మల్ని సంప్రదించవచ్చు (@MarekBartik, @MstrsObserver).

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

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

• «కుబెర్నెటెస్ క్లస్టర్‌ల రూపకల్పన: ఎన్ని ఉండాలి?";
• «ది ABC ఆఫ్ సెక్యూరిటీ ఇన్ కుబెర్నెట్స్: ప్రామాణీకరణ, ఆథరైజేషన్, ఆడిటింగ్";
• «కుబెర్నెట్స్‌లో ఆటోస్కేలింగ్ మరియు వనరుల నిర్వహణ"(సమీక్ష మరియు వీడియో నివేదిక);
• «కుబెర్నెట్స్‌లోని కాన్ఫిగమ్‌మ్యాప్స్: తెలుసుకోవలసిన విలువైన సూక్ష్మ నైపుణ్యాలు".

మూలం: www.habr.com