తొమ్మిది కుబెర్నెట్స్ పనితీరు చిట్కాలు

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

Kubernetes కంటైనర్ ఆర్కెస్ట్రేషన్ కోసం స్కేలబుల్ ఓపెన్ సోర్స్ సిస్టమ్ అని మీ అందరికీ బాగా తెలుసు; అలాగే, లేదా సర్వర్ వాతావరణంలో మీ మైక్రోసర్వీస్‌ల జీవిత చక్రాన్ని నిర్వహించడం ద్వారా మ్యాజిక్ చేసే 5 బైనరీలు. అదనంగా, ఇది వివిధ పనుల కోసం గరిష్ట అనుకూలీకరణ కోసం లెగో కన్స్ట్రక్టర్ వలె సమీకరించగల చాలా సరళమైన సాధనం.

మరియు ప్రతిదీ బాగానే ఉన్నట్లు అనిపిస్తుంది: సర్వర్‌లను క్లస్టర్‌లోకి విసిరేయండి, కట్టెలను ఫైర్‌బాక్స్‌లోకి లాగండి మరియు దుఃఖం తెలియదు. కానీ మీరు పర్యావరణం కోసం ఉంటే, అప్పుడు మీరు ఇలా ఆలోచిస్తారు: "నేను పొయ్యిలో అగ్నిని ఎలా ఉంచగలను మరియు అడవికి చింతిస్తున్నాను?". మరో మాటలో చెప్పాలంటే, మౌలిక సదుపాయాలను మెరుగుపరచడానికి మరియు ఖర్చులను తగ్గించడానికి మార్గాలను ఎలా కనుగొనాలి.

1. బృందం మరియు అప్లికేషన్ వనరులను ట్రాక్ చేయండి

అభ్యర్థనలు/పరిమితుల పరిచయం అత్యంత సామాన్యమైన కానీ ప్రభావవంతమైన పద్ధతుల్లో ఒకటి. నేమ్‌స్పేస్‌ల ద్వారా అప్లికేషన్‌లను మరియు డెవలప్‌మెంట్ టీమ్‌ల ద్వారా నేమ్‌స్పేస్‌లను వేరు చేయండి. ప్రాసెసర్ సమయం, మెమరీ, అశాశ్వత నిల్వ వినియోగం కోసం విలువలను అమలు చేయడానికి ముందు అప్లికేషన్‌ను సెట్ చేయండి.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

అనుభవం ద్వారా, మేము ముగింపుకు వచ్చాము: పరిమితుల నుండి అభ్యర్థనలను రెండు సార్లు కంటే ఎక్కువ పెంచడం విలువైనది కాదు. క్లస్టర్ యొక్క వాల్యూమ్ అభ్యర్థనల ఆధారంగా లెక్కించబడుతుంది మరియు మీరు అనువర్తనాలకు వనరులలో వ్యత్యాసాన్ని 5-10 సార్లు సెట్ చేస్తే, ఉదాహరణకు, పాడ్‌లతో నిండినప్పుడు మరియు అకస్మాత్తుగా లోడ్‌ను స్వీకరించినప్పుడు మీ నోడ్‌కు ఏమి జరుగుతుందో ఊహించండి. . ఏమీ బాగోలేదు. కనిష్టంగా, థ్రోట్లింగ్ మరియు గరిష్టంగా, కార్మికుడికి వీడ్కోలు చెప్పండి మరియు పాడ్‌లు కదలడం ప్రారంభించిన తర్వాత మిగిలిన నోడ్‌లపై చక్రీయ లోడ్‌ను పొందండి.

అదనంగా, సహాయంతో limitranges మీరు ప్రారంభంలో కంటైనర్ కోసం వనరుల విలువలను సెట్ చేయవచ్చు - కనిష్ట, గరిష్ట మరియు డిఫాల్ట్:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

నేమ్‌స్పేస్ వనరులను పరిమితం చేయాలని గుర్తుంచుకోండి, తద్వారా ఒక కమాండ్ క్లస్టర్ యొక్క అన్ని వనరులను తీసుకోదు:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

మీరు వివరణ నుండి చూడగలరు resourcequotas, ops కమాండ్ మరో 10 cpuని వినియోగించే పాడ్‌లను అమలు చేయాలనుకుంటే, షెడ్యూలర్ దీన్ని చేయడానికి అనుమతించదు మరియు ఎర్రర్‌ను జారీ చేస్తుంది:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

ఇదే సమస్యను పరిష్కరించడానికి, మీరు ఒక సాధనాన్ని వ్రాయవచ్చు, ఉదాహరణకు, వంటి ఈ, ఇది కమాండ్ వనరుల స్థితిని నిల్వ చేయగలదు మరియు కట్టుబడి ఉంటుంది.

2. ఉత్తమ ఫైల్ నిల్వను ఎంచుకోండి

ఇక్కడ నేను పెర్సిస్టెంట్ వాల్యూమ్‌లు మరియు కుబెర్నెట్స్ వర్కర్ నోడ్‌ల డిస్క్ సబ్‌సిస్టమ్‌పై టచ్ చేయాలనుకుంటున్నాను. ఉత్పత్తిలో HDDలో "క్యూబ్" ఎవరూ ఉపయోగించరని నేను ఆశిస్తున్నాను, కానీ కొన్నిసార్లు సాధారణ SSD కూడా ఇప్పటికే సరిపోదు. I / O ఆపరేషన్ల ద్వారా లాగ్‌లు డిస్క్‌ను నాశనం చేస్తున్నాయని మేము అటువంటి సమస్యను ఎదుర్కొన్నాము మరియు ఇక్కడ చాలా పరిష్కారాలు లేవు:

• అధిక-పనితీరు గల SSDలను ఉపయోగించండి లేదా NVMeకి మారండి (మీరు మీ స్వంత హార్డ్‌వేర్‌ను నిర్వహించినట్లయితే).

• లాగింగ్ స్థాయిని తగ్గించండి.

• డిస్క్‌ను రేప్ చేసే పాడ్‌లను "స్మార్ట్" బ్యాలెన్సింగ్ చేయండి (podAntiAffinity).

యాక్సెస్_లాగ్స్ లాగింగ్ ప్రారంభించబడినప్పుడు డిస్క్‌తో nginx-ingress-controller క్రింద ఏమి జరుగుతుందో పై స్క్రీన్‌షాట్ చూపిస్తుంది (~12k లాగ్‌లు/సెకను). అటువంటి స్థితి, వాస్తవానికి, ఈ నోడ్‌లోని అన్ని అప్లికేషన్‌ల క్షీణతకు దారి తీస్తుంది.

PV విషయానికొస్తే, అయ్యో, నేను ప్రతిదీ ప్రయత్నించలేదు. రకాల నిరంతర వాల్యూమ్‌లు. మీకు సరిపోయే ఉత్తమ ఎంపికను ఉపయోగించండి. ఇది చారిత్రాత్మకంగా మా దేశంలో జరిగింది, సేవల్లో ఒక చిన్న భాగం RWX వాల్యూమ్‌లు అవసరం, మరియు చాలా కాలం క్రితం వారు ఈ పని కోసం NFS నిల్వను ఉపయోగించడం ప్రారంభించారు. చౌక మరియు ... తగినంత. అయితే, మేము అతనితో ఒంటిని తిన్నాము - ఆరోగ్యంగా ఉండండి, కానీ మేము అతనిని ఎలా ట్యూన్ చేయాలో నేర్చుకున్నాము మరియు అతని తల ఇకపై బాధించదు. మరియు వీలైతే, S3 ఆబ్జెక్ట్ స్టోరేజ్‌కి మారండి.

3. ఆప్టిమైజ్ చేసిన చిత్రాలను రూపొందించండి

కంటైనర్-ఆప్టిమైజ్ చేసిన చిత్రాలను ఉపయోగించడం ఉత్తమం, తద్వారా కుబెర్నెట్‌లు వాటిని వేగంగా పొందగలరు మరియు వాటిని మరింత సమర్థవంతంగా అమలు చేయగలరు. 

ఆప్టిమైజేషన్ అంటే చిత్రాలు:

• ఒకే ఒక అప్లికేషన్‌ను కలిగి ఉంటుంది లేదా ఒక ఫంక్షన్‌ను మాత్రమే నిర్వహించండి;

• చిన్న పరిమాణం, ఎందుకంటే పెద్ద చిత్రాలు నెట్‌వర్క్ ద్వారా అధ్వాన్నంగా ప్రసారం చేయబడతాయి;

• పనికిరాని సమయంలో చర్య తీసుకోవడానికి కుబెర్నెట్స్ ఉపయోగించగల ఆరోగ్యం మరియు సంసిద్ధత ముగింపు పాయింట్లను కలిగి ఉండండి;

• కాన్ఫిగరేషన్ లోపాలకు ఎక్కువ నిరోధకత కలిగిన కంటైనర్-ఫ్రెండ్లీ ఆపరేటింగ్ సిస్టమ్‌లను (ఆల్పైన్ లేదా కోర్యోఎస్ వంటివి) ఉపయోగించండి;

• బహుళ-దశల బిల్డ్‌లను ఉపయోగించండి, తద్వారా మీరు కంపైల్ చేసిన అప్లికేషన్‌లను మాత్రమే అమలు చేయగలరు మరియు దానితో కూడిన మూలాలను కాదు.

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

1. మొత్తం క్లస్టర్‌పై నెట్‌వర్క్ లోడ్ తగ్గింది.

2. కంటైనర్ ప్రారంభ సమయం తగ్గింది.

3. మీ మొత్తం డాకర్ రిజిస్ట్రీ యొక్క చిన్న పరిమాణం.

4. DNS కాష్‌ని ఉపయోగించండి

మేము అధిక లోడ్ల గురించి మాట్లాడినట్లయితే, క్లస్టర్ యొక్క DNS వ్యవస్థను ట్యూన్ చేయకుండా, జీవితం చాలా అసహ్యంగా ఉంటుంది. ఒకప్పుడు, Kubernetes డెవలపర్లు వారి kube-dns పరిష్కారానికి మద్దతు ఇచ్చారు. ఇది మన దేశంలో కూడా అమలు చేయబడింది, అయితే ఈ సాఫ్ట్‌వేర్ ప్రత్యేకంగా ట్యూన్ చేయలేదు మరియు అవసరమైన పనితీరును ఇవ్వలేదు, అయినప్పటికీ, పని చాలా సులభం. అప్పుడు coredns కనిపించాయి, దానికి మేము మారాము మరియు దుఃఖం తెలియదు, తర్వాత అది K8 లలో డిఫాల్ట్ DNS సేవగా మారింది. ఏదో ఒక సమయంలో, మేము DNS సిస్టమ్‌కు 40 వేల rps వరకు పెరిగాము మరియు ఈ పరిష్కారం కూడా సరిపోదు. కానీ, అదృష్టవశాత్తూ, నోడెలోకాల్డ్న్స్ బయటకు వచ్చింది, నోడ్ లోకల్ కాష్, అకా NodeLocal DNSCache.

ఎందుకు వాడుతున్నాం? Linux కెర్నల్‌లో ఒక బగ్ ఉంది, UDP ద్వారా కాంట్‌ట్రాక్ NAT ద్వారా బహుళ యాక్సెస్‌లు ఉన్నప్పుడు, కాంట్‌ట్రాక్ టేబుల్‌లకు వ్రాయడానికి రేస్ స్థితికి దారి తీస్తుంది మరియు NAT ద్వారా ట్రాఫిక్‌లో కొంత భాగం పోతుంది (సేవ ద్వారా ప్రతి ప్రయాణం NAT). NATని వదిలించుకోవడం మరియు TCP కనెక్టివిటీని అప్‌స్ట్రీమ్ DNSకి అప్‌గ్రేడ్ చేయడం, అలాగే అప్‌స్ట్రీమ్ DNS ప్రశ్నలను స్థానికంగా క్యాష్ చేయడం ద్వారా Nodelocaldns ఈ సమస్యను పరిష్కరిస్తుంది (చిన్న 5 సెకన్ల ప్రతికూల కాష్‌తో సహా).

5. పాడ్‌లను అడ్డంగా మరియు నిలువుగా స్వయంచాలకంగా స్కేల్ చేయండి

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

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

చిత్రం https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 నుండి తీసుకోబడింది

కుబెర్నెట్స్‌లోని షెడ్యూలర్ ఎల్లప్పుడూ అభ్యర్థనలపై ఆధారపడి ఉంటుంది. మీరు అక్కడ ఏ విలువను ఉంచినా, షెడ్యూలర్ దాని ఆధారంగా తగిన నోడ్ కోసం చూస్తారు. పాడ్‌ను ఎప్పుడు త్రోటెల్ చేయాలో లేదా చంపాలో తెలుసుకోవడానికి కుబ్లెట్‌కి పరిమితుల విలువ అవసరం. మరియు అభ్యర్థనల విలువ మాత్రమే ముఖ్యమైన పరామితి కాబట్టి, VPA దానితో పని చేస్తుంది. మీరు మీ అప్లికేషన్‌ను నిలువుగా స్కేల్ చేసినప్పుడు, అభ్యర్థనలు ఎలా ఉండాలో మీరు నిర్వచిస్తారు. మరియు అప్పుడు పరిమితులకు ఏమి జరుగుతుంది? ఈ పరామితి కూడా దామాషా ప్రకారం స్కేల్ చేయబడుతుంది.

ఉదాహరణకు, ఇక్కడ సాధారణ పాడ్ సెట్టింగ్‌లు ఉన్నాయి:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

మీ అప్లికేషన్ సరిగ్గా అమలు కావడానికి 300m CPU మరియు 500Mi అవసరమని సిఫార్సు ఇంజిన్ నిర్ధారిస్తుంది. మీరు ఈ సెట్టింగ్‌లను పొందుతారు:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

పైన పేర్కొన్నట్లుగా, ఇది మానిఫెస్ట్‌లోని అభ్యర్థనలు/పరిమితుల నిష్పత్తి ఆధారంగా అనుపాత స్కేలింగ్:

• CPU: 200m → 300m: నిష్పత్తి 1:1.75;

• మెమరీ: 250Mi → 500Mi: 1:2 నిష్పత్తి.

సంబంధించి తక్కువ hPa, అప్పుడు ఆపరేషన్ యొక్క యంత్రాంగం మరింత పారదర్శకంగా ఉంటుంది. ప్రాసెసర్ మరియు మెమరీ వంటి కొలమానాల కోసం థ్రెషోల్డ్‌లు సెట్ చేయబడతాయి మరియు అన్ని ప్రతిరూపాల సగటు థ్రెషోల్డ్‌ని మించి ఉంటే, విలువ థ్రెషోల్డ్ కంటే దిగువకు వచ్చే వరకు లేదా గరిష్ట సంఖ్యలో ప్రతిరూపాలను చేరుకునే వరకు అప్లికేషన్ +1 పాడ్‌తో స్కేల్ అవుతుంది.

చిత్రం https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 నుండి తీసుకోబడింది

CPU మరియు మెమరీ వంటి సాధారణ కొలమానాలతో పాటు, మీరు మీ అనుకూల ప్రోమేతియస్ కొలమానాలపై థ్రెషోల్డ్‌లను సెట్ చేయవచ్చు మరియు మీ అప్లికేషన్‌ను ఎప్పుడు స్కేల్ చేయాలో నిర్ణయించడానికి ఇదే అత్యంత ఖచ్చితమైన మార్గం అని మీరు భావిస్తే వారితో పని చేయవచ్చు. పేర్కొన్న మెట్రిక్ థ్రెషోల్డ్‌కు దిగువన అప్లికేషన్ స్థిరీకరించబడిన తర్వాత, HPA పాడ్‌లను కనిష్ట ప్రతిరూపాల సంఖ్యకు తగ్గించడం లేదా లోడ్ పేర్కొన్న థ్రెషోల్డ్‌ను చేరుకునే వరకు స్కేలింగ్ చేయడం ప్రారంభిస్తుంది.

6. నోడ్ అఫినిటీ మరియు పాడ్ అఫినిటీ గురించి మర్చిపోవద్దు

అన్ని నోడ్‌లు ఒకే హార్డ్‌వేర్‌పై పని చేయవు మరియు అన్ని పాడ్‌లు కంప్యూట్-ఇంటెన్సివ్ అప్లికేషన్‌లను అమలు చేయవలసిన అవసరం లేదు. Kubernetes ఉపయోగించి నోడ్స్ మరియు పాడ్‌ల స్పెషలైజేషన్‌ను పేర్కొనడానికి మిమ్మల్ని అనుమతిస్తుంది నోడ్ అనుబంధం и పాడ్ అనుబంధం.

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

మీకు రెండు నోడ్‌లు ఉన్నాయని అనుకుందాం: ఒకటి CPUType=HIGHFREQ మరియు పెద్ద సంఖ్యలో ఫాస్ట్ కోర్లు, మరొకటి MemoryType=HIGHMEMORY మరింత మెమరీ మరియు వేగవంతమైన పనితీరు. నోడ్‌కి పాడ్ విస్తరణను కేటాయించడం సులభమయిన మార్గం HIGHFREQవిభాగానికి జోడించడం ద్వారా spec ఇలాంటి సెలెక్టర్:

…
nodeSelector:
	CPUType: HIGHFREQ

దీన్ని చేయడానికి మరింత ఖరీదైన మరియు నిర్దిష్ట మార్గం ఉపయోగించడం nodeAffinity రంగంలో affinity ఐ spec. రెండు ఎంపికలు ఉన్నాయి:

• requiredDuringSchedulingIgnoredDuringExecution: హార్డ్ సెట్టింగ్ (షెడ్యూలర్ నిర్దిష్ట నోడ్‌లలో మాత్రమే పాడ్‌లను అమలు చేస్తుంది (మరియు మరెక్కడా లేదు));

• preferredDuringSchedulingIgnoredDuringExecution: సాఫ్ట్ సెట్టింగ్ (షెడ్యూలర్ నిర్దిష్ట నోడ్‌లకు అమర్చడానికి ప్రయత్నిస్తుంది మరియు అది విఫలమైతే, అది అందుబాటులో ఉన్న తదుపరి నోడ్‌కి అమర్చడానికి ప్రయత్నిస్తుంది).

నోడ్ లేబుల్‌లను నిర్వహించడానికి మీరు నిర్దిష్ట సింటాక్స్‌ను పేర్కొనవచ్చు, ఉదాహరణకు, In, NotIn, Exists, DoesNotExist, Gt లేదా Lt. అయినప్పటికీ, లేబుల్‌ల యొక్క పొడవైన జాబితాలలోని సంక్లిష్ట పద్ధతులు క్లిష్టమైన పరిస్థితుల్లో నిర్ణయం తీసుకోవడంలో నెమ్మదిస్తాయని గుర్తుంచుకోండి. మరో మాటలో చెప్పాలంటే, క్లిష్టతరం చేయవద్దు.

పైన చెప్పినట్లుగా, ప్రస్తుత పాడ్‌ల బైండింగ్‌ను సెట్ చేయడానికి కుబెర్నెటెస్ మిమ్మల్ని అనుమతిస్తుంది. అంటే, మీరు అదే లభ్యత జోన్ (మేఘాలకు సంబంధించినది) లేదా నోడ్‌లలోని ఇతర పాడ్‌లతో కలిసి కొన్ని పాడ్‌లు కలిసి పనిచేసేలా చేయవచ్చు.

В podAffinity ఖాళీలను affinity ఐ spec విషయంలో వలె అదే ఫీల్డ్‌లు అందుబాటులో ఉన్నాయి nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. ఒక్కటే తేడా matchExpressions ఆ లేబుల్‌తో ఇప్పటికే పాడ్‌ని నడుపుతున్న నోడ్‌కి పాడ్‌లను బంధిస్తుంది.

మరిన్ని కుబెర్నెటెస్ ఫీల్డ్‌ను అందిస్తుంది podAntiAffinity, దీనికి విరుద్ధంగా, నిర్దిష్ట పాడ్‌లతో నోడ్‌కు పాడ్‌ని బంధించదు.

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

7. మచ్చలు & సహనం

షెడ్యూలర్‌ను నిర్వహించడానికి మరొక మార్గం ఉంది. మీరు వందలకొద్దీ నోడ్‌లు మరియు వేలకొద్దీ మైక్రోసర్వీస్‌లతో కూడిన పెద్ద క్లస్టర్‌ని కలిగి ఉంటే, నిర్దిష్ట నోడ్‌ల ద్వారా కొన్ని పాడ్‌లను హోస్ట్ చేయకుండా నిరోధించడం చాలా కష్టం.

taints యొక్క యంత్రాంగం - నిషేధించే నియమాలు - దీనికి సహాయపడుతుంది. ఉదాహరణకు, మీరు నిర్దిష్ట దృశ్యాలలో పాడ్‌లను అమలు చేయకుండా కొన్ని నోడ్‌లను నిరోధించవచ్చు. నిర్దిష్ట నోడ్‌కు టేంట్‌ను వర్తింపజేయడానికి, ఎంపికను ఉపయోగించండి taint kubectl లో. కీ మరియు విలువను పేర్కొనండి, ఆపై లైక్ చేయండి NoSchedule లేదా NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

టేన్ట్ మెకానిజం మూడు ప్రధాన ప్రభావాలకు మద్దతు ఇస్తుందని కూడా గమనించాలి: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule అంటే పాడ్ స్పెసిఫికేషన్‌లో సంబంధిత ఎంట్రీ ఉండే వరకు tolerations, ఇది నోడ్‌కు అమలు చేయబడదు (ఈ ఉదాహరణలో node10).

• PreferNoSchedule - సరళీకృత వెర్షన్ NoSchedule. ఈ సందర్భంలో, షెడ్యూలర్ సరిపోలే ఎంట్రీ లేని పాడ్‌లను కేటాయించకుండా ప్రయత్నిస్తుంది. tolerations ప్రతి నోడ్, కానీ ఇది కఠినమైన పరిమితి కాదు. క్లస్టర్‌లో వనరులు లేనట్లయితే, పాడ్‌లు ఈ నోడ్‌లో అమర్చడం ప్రారంభిస్తాయి.

• NoExecute - ఈ ప్రభావం సరిపోలే ఎంట్రీని కలిగి లేని పాడ్‌ల తక్షణ తరలింపును ప్రేరేపిస్తుంది tolerations.

ఆసక్తికరంగా, టాలరేషన్ మెకానిజం ఉపయోగించి ఈ ప్రవర్తనను రద్దు చేయవచ్చు. "నిషిద్ధ" నోడ్ ఉన్నప్పుడు ఇది సౌకర్యవంతంగా ఉంటుంది మరియు మీరు దానిపై మౌలిక సదుపాయాల సేవలను మాత్రమే ఉంచాలి. ఇది ఎలా చెయ్యాలి? తగిన సహనం ఉన్న పాడ్‌లను మాత్రమే అనుమతించండి.

పాడ్ స్పెక్ ఎలా ఉంటుందో ఇక్కడ ఉంది:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

దీని అర్థం తదుపరి రీడిప్లాయ్ సమయంలో, పాడ్ సరిగ్గా ఈ నోడ్‌ను తాకుతుందని కాదు, ఇది నోడ్ అఫినిటీ మెకానిజం కాదు మరియు nodeSelector. కానీ అనేక లక్షణాలను కలపడం ద్వారా, మీరు చాలా సౌకర్యవంతమైన షెడ్యూలర్ సెటప్‌ను సాధించవచ్చు.

8. పాడ్ విస్తరణ ప్రాధాన్యతను సెట్ చేయండి

మీరు పాడ్-టు-నోడ్ బైండింగ్‌లను కాన్ఫిగర్ చేసినందున అన్ని పాడ్‌లను ఒకే ప్రాధాన్యతతో పరిగణించాలని కాదు. ఉదాహరణకు, మీరు కొన్ని పాడ్‌లను ఇతరుల కంటే ముందుగా అమర్చాలనుకోవచ్చు.

కుబెర్నెటెస్ పాడ్ ప్రాధాన్యత మరియు ప్రీఎంప్షన్‌ని సెట్ చేయడానికి వివిధ మార్గాలను అందిస్తుంది. సెట్టింగ్ అనేక భాగాలను కలిగి ఉంటుంది: వస్తువు PriorityClass మరియు ఫీల్డ్ వివరణలు priorityClassName పాడ్ స్పెసిఫికేషన్‌లో. ఒక ఉదాహరణను పరిగణించండి:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

మేము సృష్టిస్తాము PriorityClass, దీనికి పేరు, వివరణ మరియు విలువ ఇవ్వండి. ఉన్నతమైనది value, అధిక ప్రాధాన్యత. విలువ ఏదైనా 32-బిట్ పూర్ణాంకం 1 కంటే తక్కువ లేదా సమానంగా ఉండవచ్చు. అధిక విలువలు మిషన్-క్రిటికల్ సిస్టమ్ పాడ్‌ల కోసం ప్రత్యేకించబడ్డాయి, వీటిని సాధారణంగా ముందస్తుగా మార్చలేరు. అధిక-ప్రాధాన్యత కలిగిన పాడ్‌కు ఎక్కడా తిరగని పక్షంలో మాత్రమే తొలగింపు జరుగుతుంది, అప్పుడు నిర్దిష్ట నోడ్ నుండి కొన్ని పాడ్‌లు ఖాళీ చేయబడతాయి. ఈ మెకానిజం మీకు చాలా దృఢంగా ఉంటే, మీరు ఎంపికను జోడించవచ్చు preemptionPolicy: Never, ఆపై ప్రీఎంప్షన్ ఉండదు, పాడ్ క్యూలో మొదటిది మరియు షెడ్యూలర్ దాని కోసం ఉచిత వనరులను కనుగొనే వరకు వేచి ఉండండి.

తరువాత, మేము ఒక పాడ్‌ను సృష్టిస్తాము, దీనిలో మేము పేరును నిర్దేశిస్తాము priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

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

అందువల్ల, అవసరమైతే, మీరు nginx-ingress-controller, coredns మొదలైన క్లిష్టమైన సేవలను అమలు చేసే సామర్థ్యాన్ని పెంచుకోవచ్చు.

9. మీ ETCD క్లస్టర్‌ని ఆప్టిమైజ్ చేయండి

ETCDని మొత్తం క్లస్టర్ యొక్క మెదడు అని పిలుస్తారు. ఈ డేటాబేస్ యొక్క ఆపరేషన్ను అధిక స్థాయిలో నిర్వహించడం చాలా ముఖ్యం, ఎందుకంటే "క్యూబ్" లో కార్యకలాపాల వేగం దానిపై ఆధారపడి ఉంటుంది. చాలా ప్రామాణికమైనది మరియు అదే సమయంలో, kube-apiserverకి కనీస ఆలస్యాన్ని కలిగి ఉండటానికి మాస్టర్ నోడ్‌లలో ETCD క్లస్టర్‌ను ఉంచడం మంచి పరిష్కారం. ఇది సాధ్యం కాకపోతే, పాల్గొనేవారి మధ్య మంచి బ్యాండ్‌విడ్త్‌తో ETCDని వీలైనంత దగ్గరగా ఉంచండి. క్లస్టర్‌కు హాని లేకుండా ETCD నుండి ఎన్ని నోడ్‌లు బయటకు వస్తాయి అనే దానిపై కూడా శ్రద్ధ వహించండి.

క్లస్టర్లో పాల్గొనేవారి సంఖ్యలో అధిక పెరుగుదల పనితీరు యొక్క వ్యయంతో తప్పు సహనాన్ని పెంచుతుందని గుర్తుంచుకోండి, ప్రతిదీ మితంగా ఉండాలి.

మేము సేవను సెటప్ చేయడం గురించి మాట్లాడినట్లయితే, కొన్ని సిఫార్సులు ఉన్నాయి:

1. క్లస్టర్ పరిమాణం ఆధారంగా మంచి హార్డ్‌వేర్‌ను కలిగి ఉండండి (మీరు చదవగలరు ఇక్కడ).

2. మీరు ఒక జత DCలు లేదా మీ నెట్‌వర్క్ మరియు డిస్క్‌ల మధ్య క్లస్టర్‌ను విస్తరించినట్లయితే కొన్ని పారామితులను సర్దుబాటు చేయండి (మీరు చదవగలరు ఇక్కడ).

తీర్మానం

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

మూలం: www.habr.com