కుబెర్నెటెస్ 1.14: ప్రధాన ఆవిష్కరణల అవలోకనం

ఈ రాత్రి జరుగుతుంది కుబెర్నెటెస్ తదుపరి విడుదల - 1.14. మా బ్లాగ్ కోసం అభివృద్ధి చేసిన సంప్రదాయం ప్రకారం, మేము ఈ అద్భుతమైన ఓపెన్ సోర్స్ ఉత్పత్తి యొక్క కొత్త వెర్షన్‌లోని కీలక మార్పుల గురించి మాట్లాడుతున్నాము.

ఈ పదార్థాన్ని సిద్ధం చేయడానికి ఉపయోగించే సమాచారం నుండి తీసుకోబడింది Kubernetes మెరుగుదలలు ట్రాకింగ్ పట్టికలు, మార్పు-1.14 మరియు సంబంధిత సమస్యలు, పుల్ అభ్యర్థనలు, కుబెర్నెట్స్ మెరుగుదల ప్రతిపాదనలు (KEP).

SIG క్లస్టర్-లైఫ్ సైకిల్ నుండి ఒక ముఖ్యమైన పరిచయంతో ప్రారంభిద్దాం: డైనమిక్ ఫెయిల్‌ఓవర్ క్లస్టర్‌లు Kubernetes (లేదా మరింత ఖచ్చితంగా చెప్పాలంటే, స్వీయ-హోస్ట్ చేసిన HA విస్తరణలు) ఇప్పుడు సృష్టించవచ్చు సుపరిచితమైన (సింగిల్-నోడ్ క్లస్టర్ల సందర్భంలో) ఆదేశాలను ఉపయోగించడం kubeadm (init и join) సంక్షిప్తంగా, దీని కోసం:

• క్లస్టర్ ఉపయోగించే ధృవపత్రాలు రహస్యాలకు బదిలీ చేయబడతాయి;
• K8s క్లస్టర్ లోపల etcd క్లస్టర్‌ని ఉపయోగించే అవకాశం కోసం (అనగా గతంలో ఉన్న బాహ్య డిపెండెన్సీని వదిలించుకోవడం) etcd-ఆపరేటర్;
• ఫాల్ట్-టాలరెంట్ కాన్ఫిగరేషన్‌ను అందించే బాహ్య లోడ్ బ్యాలెన్సర్ కోసం సిఫార్సు చేయబడిన సెట్టింగ్‌లను డాక్యుమెంట్ చేస్తుంది (భవిష్యత్తులో ఈ డిపెండెన్సీని తొలగించడానికి ప్రణాళిక చేయబడింది, కానీ ఈ దశలో కాదు).

Kubeadmతో సృష్టించబడిన కుబెర్నెటెస్ HA క్లస్టర్ యొక్క ఆర్కిటెక్చర్

అమలు వివరాలను చూడవచ్చు డిజైన్ ప్రతిపాదన. ఈ ఫీచర్ నిజంగా చాలా కాలంగా ఎదురుచూస్తున్నది: ఆల్ఫా వెర్షన్ K8s 1.9లో తిరిగి ఊహించబడింది, కానీ ఇప్పుడు మాత్రమే కనిపించింది.

API

జట్టు apply మరియు సాధారణంగా చెప్పాలంటే డిక్లరేటివ్ ఆబ్జెక్ట్ మేనేజ్‌మెంట్ పాసయ్యాడు నుండి kubectl apiserver లో. అని చెప్పడం ద్వారా డెవలపర్లు తమ నిర్ణయాన్ని క్లుప్తంగా వివరిస్తారు kubectl apply - కుబెర్నెటెస్‌లో కాన్ఫిగరేషన్‌లతో పనిచేయడంలో ప్రాథమిక భాగం, అయితే, “ఇది బగ్‌లతో నిండి ఉంది మరియు పరిష్కరించడం కష్టం,” కాబట్టి ఈ కార్యాచరణను సాధారణ స్థితికి తీసుకురావాలి మరియు కంట్రోల్ ప్లేన్‌కు బదిలీ చేయాలి. నేడు ఉన్న సమస్యలకు సరళమైన మరియు స్పష్టమైన ఉదాహరణలు:

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

ఆల్ఫా వెర్షన్‌లో అందుబాటులోకి వచ్చింది అవకాశం కోసం OpenAPI v3 స్కీమ్‌ని ఉపయోగిస్తోంది CustomResources కోసం OpenAPI డాక్యుమెంటేషన్‌ని సృష్టించడం మరియు ప్రచురించడం (CR)ని ధృవీకరించడానికి (సర్వర్ వైపు) K8s వినియోగదారు నిర్వచించిన వనరులను (CustomResourceDefinition, CRD) ఉపయోగిస్తారు. CRD కోసం OpenAPIని ప్రచురించడం క్లయింట్‌లను అనుమతిస్తుంది (ఉదా. kubectl) మీ వైపు (లోపల kubectl create и kubectl apply) మరియు పథకం ప్రకారం డాక్యుమెంటేషన్ జారీ చేయండి (kubectl explain) వివరాలు - లో CAP.

ముందుగా ఉన్న లాగ్‌లు ఇప్పుడు తెరవబడుతున్నాయి జెండాతో O_APPEND (కాని కాదు O_TRUNC) కొన్ని పరిస్థితులలో లాగ్‌ల నష్టాన్ని నివారించడానికి మరియు భ్రమణం కోసం బాహ్య వినియోగాలతో లాగ్‌లను కత్తిరించే సౌలభ్యం కోసం.

కుబెర్నెటెస్ API సందర్భంలో కూడా దీనిని గమనించవచ్చు PodSandbox и PodSandboxStatus జోడించారు ఫీల్డ్ runtime_handler గురించి సమాచారాన్ని రికార్డ్ చేయడానికి RuntimeClass పాడ్‌లో (దాని గురించి టెక్స్ట్‌లో మరింత చదవండి కుబెర్నెటెస్ 1.12 విడుదల, ఈ తరగతి ఆల్ఫా వెర్షన్‌గా కనిపించింది), మరియు అడ్మిషన్ వెబ్‌హూక్స్‌లో అమలు చేశారు ఏ సంస్కరణలను నిర్ణయించగల సామర్థ్యం AdmissionReview వారు మద్దతు ఇస్తారు. చివరగా, అడ్మిషన్ వెబ్‌హోక్స్ నియమాలు ఇప్పుడు పరిమితం చేయవచ్చు నేమ్‌స్పేస్‌లు మరియు క్లస్టర్ ఫ్రేమ్‌వర్క్‌ల ద్వారా వాటి ఉపయోగం యొక్క పరిధి.

నిల్వ

PersistentLocalVolumes, ఇది విడుదలైనప్పటి నుండి బీటా స్థితిని కలిగి ఉంది K8s 1.10, ప్రకటించారు స్థిరమైన (GA): ఈ ఫీచర్ గేట్ ఇకపై నిలిపివేయబడదు మరియు కుబెర్నెట్స్ 1.17లో తీసివేయబడుతుంది.

అవకాశం అనే ఎన్విరాన్మెంట్ వేరియబుల్స్ ఉపయోగించి క్రిందికి API (ఉదాహరణకు, పాడ్ పేరు) ఇలా మౌంట్ చేయబడిన డైరెక్టరీల పేర్లకు subPath, అభివృద్ధి చేయబడింది - కొత్త ఫీల్డ్ రూపంలో subPathExpr, ఇది ఇప్పుడు కావలసిన డైరెక్టరీ పేరును నిర్ణయించడానికి ఉపయోగించబడుతుంది. ఈ ఫీచర్ మొదట్లో కుబెర్నెటెస్ 1.11లో కనిపించింది, అయితే 1.14కి అది ఆల్ఫా వెర్షన్ స్టేటస్‌లో ఉంది.

మునుపటి కుబెర్నెట్స్ విడుదల మాదిరిగానే, చురుకుగా అభివృద్ధి చెందుతున్న CSI (కంటైనర్ స్టోరేజ్ ఇంటర్‌ఫేస్) కోసం అనేక ముఖ్యమైన మార్పులు ప్రవేశపెట్టబడ్డాయి:

CSI

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

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

అంతిమ వినియోగదారులకు (సిస్టమ్ నిర్వాహకులు) అంతగా కనిపించని CSIకి సంబంధించిన Kubernetes యొక్క “ఇంటర్నల్స్”లో కూడా పురోగతి ఉంది... ప్రస్తుతం, డెవలపర్లు ప్రతి స్టోరేజ్ ప్లగిన్ యొక్క రెండు వెర్షన్‌లకు మద్దతు ఇవ్వవలసి వచ్చింది: ఒకటి - “లో పాత మార్గం”, K8s కోడ్‌బేస్ లోపల (ఇన్-ట్రీ), మరియు రెండవది - కొత్త CSIలో భాగంగా (దాని గురించి మరింత చదవండి, ఉదాహరణకు, in ఇక్కడ). ఇది అర్థం చేసుకోదగిన అసౌకర్యాలను కలిగిస్తుంది, CSI కూడా స్థిరీకరించబడినందున పరిష్కరించాల్సిన అవసరం ఉంది. దీని కారణంగా అంతర్గత (ఇన్-ట్రీ) ప్లగిన్‌ల APIని తీసివేయడం సాధ్యం కాదు సంబంధిత Kubernetes విధానం.

ఇదంతా ఆల్ఫా వెర్షన్ చేరుకుందనే వాస్తవం దారితీసింది వలస ప్రక్రియ అంతర్గత ప్లగిన్ కోడ్, ఇన్-ట్రీగా, CSI ప్లగిన్‌లలో అమలు చేయబడింది, దీని వలన డెవలపర్‌ల ఆందోళనలు వారి ప్లగిన్‌ల యొక్క ఒక సంస్కరణకు మద్దతు ఇవ్వడానికి తగ్గించబడతాయి మరియు పాత APIలతో అనుకూలత అలాగే ఉంటుంది మరియు అవి సాధారణ దృష్టాంతంలో వాడుకలో లేనివిగా ప్రకటించబడతాయి. కుబెర్నెటెస్ (1.15) యొక్క తదుపరి విడుదల నాటికి అన్ని క్లౌడ్ ప్రొవైడర్ ప్లగిన్‌లు మైగ్రేట్ చేయబడతాయని, అమలు బీటా స్థితిని అందుకుంటుంది మరియు డిఫాల్ట్‌గా K8s ఇన్‌స్టాలేషన్‌లలో యాక్టివేట్ చేయబడుతుంది. వివరాల కోసం, చూడండి డిజైన్ ప్రతిపాదన. ఈ వలస కూడా దారితీసింది వైఫల్యం నిర్దిష్ట క్లౌడ్ ప్రొవైడర్లు (AWS, Azure, GCE, Cinder) నిర్వచించిన వాల్యూమ్ పరిమితుల నుండి.

అదనంగా, CSIతో బ్లాక్ పరికరాలకు మద్దతు (CSIBlockVolume) బదిలీ చేయబడింది బీటా వెర్షన్‌కి.

నోడ్స్/కుబెలెట్

ఆల్ఫా వెర్షన్ అందించబడింది కొత్త ముగింపు స్థానం కోసం రూపొందించబడింది Kubelet లో కీలక వనరులపై కొలమానాలను తిరిగి ఇవ్వండి. సాధారణంగా చెప్పాలంటే, గతంలో కుబెలెట్ cAdvisor నుండి కంటైనర్ వినియోగంపై గణాంకాలను పొందినట్లయితే, ఇప్పుడు ఈ డేటా CRI (కంటైనర్ రన్‌టైమ్ ఇంటర్‌ఫేస్) ద్వారా కంటైనర్ రన్‌టైమ్ వాతావరణం నుండి వస్తుంది, అయితే డాకర్ యొక్క పాత వెర్షన్‌లతో పని చేయడానికి అనుకూలత కూడా భద్రపరచబడింది. మునుపు, కుబెలెట్‌లో సేకరించిన గణాంకాలు REST API ద్వారా పంపబడ్డాయి, కానీ ఇప్పుడు ముగింపు స్థానం ఇక్కడ ఉంది /metrics/resource/v1alpha1. డెవలపర్ల దీర్ఘకాలిక వ్యూహం ఉంది కుబెలెట్ అందించిన కొలమానాల సెట్‌ను తగ్గించడం. మార్గం ద్వారా, ఈ కొలమానాలు స్వయంగా ఇప్పుడు వారు పిలుస్తారు "కోర్ మెట్రిక్స్" కాదు, "రిసోర్స్ మెట్రిక్స్", మరియు "cpu మరియు మెమరీ వంటి మొదటి-తరగతి వనరులు"గా వర్ణించబడ్డాయి.

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

"gRPC ప్రధాన పర్యవేక్షణ పైప్‌లైన్‌లకు అనుకూలంగా లేదు. మెట్రిక్స్ సర్వర్‌కు కొలమానాలను బట్వాడా చేయడానికి లేదా దానితో నేరుగా ఏకీకృతం చేసే భాగాలను పర్యవేక్షించడానికి మాత్రమే ఎండ్‌పాయింట్ ఉపయోగపడుతుంది. మెట్రిక్స్ సర్వర్‌లో కాషింగ్‌ని ఉపయోగిస్తున్నప్పుడు ప్రోమేతియస్ టెక్స్ట్ ఫార్మాట్ పనితీరు తగినంత మంచిది కమ్యూనిటీలో ప్రోమేతియస్‌ను విస్తృతంగా స్వీకరించినందున, మేము gRPC కంటే ప్రోమేతియస్‌ను ఇష్టపడతాము. OpenMetrics ఫార్మాట్ మరింత స్థిరంగా మారిన తర్వాత, మేము ప్రోటో-ఆధారిత ఆకృతితో gRPC పనితీరును చేరుకోగలుగుతాము.

కొలమానాల కోసం కొత్త కుబెలెట్ ఎండ్‌పాయింట్‌లో gRPC మరియు Prometheus ఫార్మాట్‌లను ఉపయోగించడం యొక్క తులనాత్మక పనితీరు పరీక్షల్లో ఒకటి. మరిన్ని గ్రాఫ్‌లు మరియు ఇతర వివరాలను చూడవచ్చు CAP.

ఇతర మార్పులలో:

• ఇప్పుడు కుబేలెట్ (ఒకసారి) ఆపడానికి ప్రయత్నిస్తున్నారు ఆపరేషన్‌లను పునఃప్రారంభించడానికి మరియు తొలగించడానికి ముందు తెలియని స్థితిలో కంటైనర్‌లు.
• ఉపయోగించి PodPresets ఇప్పుడు init కంటైనర్‌కి జోడించబడింది సాధారణ కంటైనర్ కోసం అదే సమాచారం.
• కుబేలెట్ ఉపయోగించడం ప్రారంభించారు usageNanoCores CRI గణాంకాల ప్రదాత నుండి మరియు Windowsలో నోడ్‌లు మరియు కంటైనర్‌ల కోసం జోడించారు నెట్‌వర్క్ గణాంకాలు.
• ఆపరేటింగ్ సిస్టమ్ మరియు ఆర్కిటెక్చర్ సమాచారం ఇప్పుడు లేబుల్‌లలో రికార్డ్ చేయబడింది kubernetes.io/os и kubernetes.io/arch నోడ్ వస్తువులు (బీటా నుండి GAకి బదిలీ చేయబడ్డాయి).
• పాడ్‌లోని కంటైనర్‌ల కోసం నిర్దిష్ట సిస్టమ్ వినియోగదారు సమూహాన్ని పేర్కొనే సామర్థ్యం (RunAsGroup, లో కనిపించింది K8s 1.11) ఆధునిక బీటాకు ముందు (డిఫాల్ట్‌గా ప్రారంభించబడింది).
• డు మరియు cAdvisorలో ఉపయోగించినట్లు కనుగొనండి, భర్తీ చేయబడింది గో అమలుపై.

CLI

క్లై-రన్‌టైమ్ మరియు kubectlలో జోడించబడింది -k ఫ్లాగ్‌తో ఏకీకరణ కోసం అనుకూలీకరించండి (మార్గం ద్వారా, దాని అభివృద్ధి ఇప్పుడు ప్రత్యేక రిపోజిటరీలో నిర్వహించబడుతుంది), అనగా. ప్రత్యేక కస్టమైజేషన్ డైరెక్టరీల నుండి అదనపు YAML ఫైల్‌లను ప్రాసెస్ చేయడానికి (వాటిని ఉపయోగించడం గురించి వివరాల కోసం, చూడండి CAP):

సాధారణ ఫైల్ వినియోగానికి ఉదాహరణ అనుకూలీకరణ (కస్టమైజ్ యొక్క మరింత సంక్లిష్టమైన అప్లికేషన్ లోపల సాధ్యమవుతుంది విస్తరణలు)

అదనంగా:

• చేర్చబడింది కొత్త జట్టు kubectl create cronjob, దీని పేరు స్వయంగా మాట్లాడుతుంది.
• В kubectl logs ఇప్పుడు మీరు చేయవచ్చు మిళితం జెండాలు -f (--follow స్ట్రీమింగ్ లాగ్‌ల కోసం) మరియు -l (--selector లేబుల్ ప్రశ్న కోసం).
• kubectl బోధించాడు వైల్డ్ కార్డ్ ద్వారా ఎంచుకున్న ఫైల్‌లను కాపీ చేయండి.
• జట్టుకు kubectl wait జోడించారు జెండా --all పేర్కొన్న వనరు రకం యొక్క నేమ్‌స్పేస్‌లోని అన్ని వనరులను ఎంచుకోవడానికి.

ఇతర

కింది సామర్థ్యాలు స్థిరమైన (GA) స్థితిని పొందాయి:

• ReadinessGate, పాడ్ యొక్క సంసిద్ధతలో పరిగణనలోకి తీసుకున్న అదనపు షరతులను నిర్వచించడానికి పాడ్ స్పెసిఫికేషన్‌లో ఉపయోగించబడుతుంది;
• పెద్ద పేజీలకు మద్దతు (ఫీచర్ గేట్ అంటారు HugePages);
• CustomPodDNS;
• ప్రయారిటీ క్లాస్ API పాడ్ ప్రాధాన్యత & ముందస్తు.

కుబెర్నెట్స్ 1.14లో ప్రవేశపెట్టిన ఇతర మార్పులు:

• డిఫాల్ట్ RBAC విధానం ఇకపై API యాక్సెస్‌ని అనుమతించదు discovery и access-review ప్రమాణీకరణ లేని వినియోగదారులు (ప్రామాణీకరించబడలేదు).
• అధికారిక CoreDNS మద్దతు నిర్ధారించారు Linux మాత్రమే, కాబట్టి kubeadmని క్లస్టర్‌లో అమర్చడానికి (CoreDNS) ఉపయోగిస్తున్నప్పుడు, నోడ్‌లు తప్పనిసరిగా Linuxలో మాత్రమే రన్ చేయబడాలి (ఈ పరిమితి కోసం nodeSelectors ఉపయోగించబడతాయి).
• డిఫాల్ట్ CoreDNS కాన్ఫిగరేషన్ ఇప్పుడు ఉపయోగాలు ముందుకు ప్లగిన్ బదులుగా ప్రాక్సీ. అలాగే, CoreDNSలో జోడించారు రెడీనెస్‌ప్రోబ్, ఇది తగిన (సేవకు సిద్ధంగా లేదు) పాడ్‌లపై లోడ్ బ్యాలెన్సింగ్‌ను నిరోధిస్తుంది.
• కుబేద్మ్‌లో, దశల్లో init లేదా upload-certs, సాధ్యమైంది కొత్త కంట్రోల్-ప్లేన్‌ను kubeadm-certs రహస్యానికి కనెక్ట్ చేయడానికి అవసరమైన సర్టిఫికేట్‌లను లోడ్ చేయండి (ఫ్లాగ్‌ని ఉపయోగించండి --experimental-upload-certs).
• విండోస్ ఇన్‌స్టాలేషన్‌ల కోసం ఆల్ఫా వెర్షన్ కనిపించింది మద్దతు gMSA (గ్రూప్ మేనేజ్డ్ సర్వీస్ ఖాతా) - యాక్టివ్ డైరెక్టరీలోని ప్రత్యేక ఖాతాలు, వీటిని కంటైనర్‌లు కూడా ఉపయోగించవచ్చు.
• జి.సి.ఇ. యాక్టివేట్ చేయబడింది etcd మరియు kube-apiserver మధ్య mTLS ఎన్‌క్రిప్షన్.
• ఉపయోగించిన/ఆధారిత సాఫ్ట్‌వేర్‌లో అప్‌డేట్‌లు: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadmలో డాకర్ 18.09 మద్దతు మరియు కనీస మద్దతు ఉన్న డాకర్ API వెర్షన్ ఇప్పుడు 1.26.

PS

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

• «కుబెర్నెటెస్ 1.13: ప్రధాన ఆవిష్కరణల అవలోకనం";
• «కుబెర్నెటెస్ 1.12: ప్రధాన ఆవిష్కరణల అవలోకనం";
• «కుబెర్నెటెస్ 1.11: ప్రధాన ఆవిష్కరణల అవలోకనం";
• «కుబెర్నెటెస్ 1.10: ప్రధాన ఆవిష్కరణల అవలోకనం".

మూలం: www.habr.com