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

నేడు, బుధవారం, జరుగుతుంది కుబెర్నెటెస్ తదుపరి విడుదల - 1.16. మా బ్లాగ్ కోసం అభివృద్ధి చేసిన సంప్రదాయం ప్రకారం, ఇది కొత్త సంస్కరణలో అత్యంత ముఖ్యమైన మార్పుల గురించి మేము మాట్లాడుతున్న పదవ వార్షికోత్సవ సమయం.

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

నోడ్స్

K8s క్లస్టర్ నోడ్స్ (కుబెలెట్) వైపు నిజంగా పెద్ద సంఖ్యలో గుర్తించదగిన ఆవిష్కరణలు (ఆల్ఫా వెర్షన్ హోదాలో) ప్రదర్శించబడ్డాయి.

మొదట, అని పిలవబడేది «అశాశ్వత కంటైనర్లు» (ఎఫెమెరల్ కంటైనర్లు), పాడ్‌లలో డీబగ్గింగ్ ప్రక్రియలను సులభతరం చేయడానికి రూపొందించబడింది. కొత్త మెకానిజం ఇప్పటికే ఉన్న పాడ్‌ల నేమ్‌స్పేస్‌లో ప్రారంభమయ్యే ప్రత్యేక కంటైనర్‌లను లాంచ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు తక్కువ సమయం వరకు ఉంటుంది. ఏదైనా సమస్యలను పరిష్కరించేందుకు మరియు డీబగ్ చేయడానికి ఇతర పాడ్‌లు మరియు కంటైనర్‌లతో పరస్పర చర్య చేయడం వారి ఉద్దేశ్యం. ఈ ఫీచర్ కోసం కొత్త కమాండ్ అమలు చేయబడింది kubectl debug, సారాంశంలో పోలి ఉంటుంది kubectl exec: కంటైనర్‌లో ప్రాసెస్‌ను అమలు చేయడానికి బదులుగా (లో వలె exec) ఇది పాడ్‌లో ఒక కంటైనర్‌ను లాంచ్ చేస్తుంది. ఉదాహరణకు, ఈ ఆదేశం కొత్త కంటైనర్‌ను పాడ్‌కి కనెక్ట్ చేస్తుంది:

kubectl debug -c debug-shell --image=debian target-pod -- bash

అశాశ్వత కంటైనర్లు (మరియు వాటి ఉపయోగం యొక్క ఉదాహరణలు) గురించిన వివరాలను చూడవచ్చు సంబంధిత KEP. ప్రస్తుత అమలు (K8s 1.16లో) ఆల్ఫా వెర్షన్, మరియు బీటా వెర్షన్‌కి బదిలీ చేయడానికి ప్రమాణాలలో ఒకటి “కనీసం 2 [కుబెర్నెట్స్] విడుదలల కోసం ఎఫెమెరల్ కంటైనర్‌ల APIని పరీక్షించడం.”

NB: దాని సారాంశం మరియు దాని పేరులో కూడా, ఫీచర్ ఇప్పటికే ఉన్న ప్లగిన్‌ని పోలి ఉంటుంది kubectl-డీబగ్దాని గురించి మేము ఇప్పటికే రాశారు. అశాశ్వత కంటైనర్ల ఆగమనంతో, ప్రత్యేక బాహ్య ప్లగ్ఇన్ అభివృద్ధి నిలిచిపోతుందని భావిస్తున్నారు.

మరో ఆవిష్కరణ - PodOverhead - అందించడానికి రూపొందించబడింది పాడ్‌ల కోసం ఓవర్‌హెడ్ ఖర్చులను లెక్కించే విధానం, ఇది ఉపయోగించిన రన్‌టైమ్‌పై ఆధారపడి చాలా తేడా ఉంటుంది. ఉదాహరణగా, రచయితలు ఈ KEP గెస్ట్ కెర్నల్, కాటా ఏజెంట్, ఇనిట్ సిస్టమ్ మొదలైనవాటిని అమలు చేయాల్సిన అవసరం ఉన్న కాటా కంటైనర్‌లలో ఫలితం ఉంటుంది. ఓవర్ హెడ్ చాలా పెద్దదిగా మారినప్పుడు, దానిని విస్మరించలేము, అంటే తదుపరి కోటాలు, ప్రణాళిక మొదలైన వాటి కోసం దానిని పరిగణనలోకి తీసుకోవడానికి ఒక మార్గం ఉండాలి. దీన్ని అమలు చేయడానికి PodSpec ఫీల్డ్ జోడించబడింది Overhead *ResourceList (లో డేటాతో పోలుస్తుంది RuntimeClass, ఒకటి ఉపయోగించినట్లయితే).

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

టోపాలజీ మేనేజర్ కాంపోనెంట్ రేఖాచిత్రం

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

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

నెట్వర్క్

కుబెర్నెటెస్ 1.16లో మొదటిసారి (ఆల్ఫా వెర్షన్‌లో) కనిపించిన రెండు ముఖ్యమైన నెట్‌వర్కింగ్ లక్షణాలు:

• Поддержка డ్యూయల్ నెట్‌వర్క్ స్టాక్ - IPv4/IPv6 - మరియు పాడ్‌లు, నోడ్‌లు, సేవల స్థాయిలో దాని సంబంధిత “అవగాహన”. ఇందులో IPv4-to-IPv4 మరియు IPv6-to-IPv6 పాడ్‌ల మధ్య ఇంటర్‌ఆపరేబిలిటీ, పాడ్‌ల నుండి బాహ్య సేవలు, సూచన అమలులు (బ్రిడ్జ్ CNI, PTP CNI మరియు హోస్ట్-లోకల్ IPAM ప్లగిన్‌లలో) అలాగే నడుస్తున్న కుబెర్నెటెస్ క్లస్టర్‌లతో రివర్స్ అనుకూలత ఉన్నాయి. IPv4 లేదా IPv6 మాత్రమే. అమలు వివరాలు ఇందులో ఉన్నాయి CAP.

  పాడ్‌ల జాబితాలో రెండు రకాల (IPv4 మరియు IPv6) IP చిరునామాలను ప్రదర్శించడానికి ఉదాహరణ:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• ఎండ్‌పాయింట్ కోసం కొత్త API - ఎండ్‌పాయింట్‌స్లైస్ API. ఇది కంట్రోల్-ప్లేన్‌లోని వివిధ భాగాలను ప్రభావితం చేసే ప్రస్తుత ఎండ్‌పాయింట్ API యొక్క పనితీరు/స్కేలబిలిటీ సమస్యలను పరిష్కరిస్తుంది (apiserver, etcd, endpoints-controller, kube-proxy). కొత్త API డిస్కవరీ API సమూహానికి జోడించబడుతుంది మరియు వేలాది నోడ్‌లతో కూడిన క్లస్టర్‌లో ప్రతి సేవలో పదివేల బ్యాకెండ్ ఎండ్ పాయింట్‌లను అందించగలదు. దీన్ని చేయడానికి, ప్రతి సేవ N ఆబ్జెక్ట్‌లకు మ్యాప్ చేయబడుతుంది EndpointSlice, వీటిలో ప్రతి ఒక్కటి డిఫాల్ట్‌గా 100 కంటే ఎక్కువ ఎండ్ పాయింట్‌లను కలిగి ఉండవు (విలువ కాన్ఫిగర్ చేయబడుతుంది). EndpointSlice API దాని భవిష్యత్తు అభివృద్ధికి అవకాశాలను కూడా అందిస్తుంది: ప్రతి పాడ్‌కు బహుళ IP చిరునామాలకు మద్దతు, ఎండ్‌పాయింట్‌ల కోసం కొత్త రాష్ట్రాలు (కేవలం కాదు Ready и NotReady), ఎండ్ పాయింట్స్ కోసం డైనమిక్ సబ్‌సెట్టింగ్.

చివరి విడుదలలో అందించినది బీటా వెర్షన్‌కు చేరుకుంది ఫైనలైజర్, అనే service.kubernetes.io/load-balancer-cleanup మరియు రకంతో ప్రతి సేవకు జోడించబడింది LoadBalancer. అటువంటి సేవను తొలగించే సమయంలో, అన్ని సంబంధిత బ్యాలెన్సర్ వనరుల "క్లీనప్" పూర్తయ్యే వరకు వనరు యొక్క అసలు తొలగింపును ఇది నిరోధిస్తుంది.

API మెషినరీ

నిజమైన “స్థిరీకరణ మైలురాయి” కుబెర్నెట్స్ API సర్వర్ మరియు దానితో పరస్పర చర్యలో ఉంది. ఇది చాలావరకు కృతజ్ఞతతో జరిగింది ప్రత్యేక పరిచయం అవసరం లేని వారిని స్థిర స్థితికి బదిలీ చేయడం CustomResourceDefinitions (CRD), ఇది కుబెర్నెటెస్ 1.7 సుదూర రోజుల నుండి బీటా స్థితిని కలిగి ఉంది (మరియు ఇది జూన్ 2017!). అదే స్థిరీకరణ సంబంధిత లక్షణాలకు వచ్చింది:

• "ఉపవనరులు" తో /status и /scale కస్టమ్ రిసోర్సెస్ కోసం;
• పరివర్తన CRD కోసం సంస్కరణలు, బాహ్య వెబ్‌హుక్ ఆధారంగా;
• ఇటీవల అందించబడింది (K8s 1.15లో) డిఫాల్ట్ విలువలు (డిఫాల్ట్) మరియు ఆటోమేటిక్ ఫీల్డ్ రిమూవల్ (కత్తిరింపు) కస్టమ్ రిసోర్సెస్ కోసం;
• అవకాశం OpenAPI v3 స్కీమాను ఉపయోగించి OpenAPI డాక్యుమెంటేషన్‌ను సృష్టించి ప్రచురించడం సర్వర్ వైపు CRD వనరులను ధృవీకరించడానికి ఉపయోగించబడుతుంది.

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

రెండు ఇతర లక్షణాలు బీటాకు చేరుకున్నాయి: సర్వర్ వైపు వర్తిస్తాయి и బుక్‌మార్క్‌లను చూడండి.

మరియు ఆల్ఫా వెర్షన్‌లో మాత్రమే ముఖ్యమైన ఆవిష్కరణ వైఫల్యం от SelfLink - పేర్కొన్న వస్తువును సూచించే మరియు దానిలో భాగమైన ప్రత్యేక URI ObjectMeta и ListMeta (అనగా కుబెర్నెటీస్‌లోని ఏదైనా వస్తువులో భాగం). వారు దానిని ఎందుకు వదులుకుంటున్నారు? సరళమైన మార్గంలో ప్రేరణ శబ్దాలు ఈ ఫీల్డ్ ఇప్పటికీ ఉనికిలో ఉండటానికి నిజమైన (అధిక) కారణాలు లేకపోవడం. పనితీరును ఆప్టిమైజ్ చేయడం (అనవసరమైన ఫీల్డ్‌ను తొలగించడం ద్వారా) మరియు జెనరిక్-ఎపిసర్వర్ యొక్క పనిని సరళీకృతం చేయడం మరిన్ని అధికారిక కారణాలు, అటువంటి ఫీల్డ్‌ను ప్రత్యేక పద్ధతిలో నిర్వహించవలసి వస్తుంది (ఇది ఆబ్జెక్ట్‌కు ముందు సెట్ చేయబడిన ఏకైక ఫీల్డ్. సీరియల్ చేయబడింది). నిజమైన వాడుకలో లేదు (బీటా లోపల) SelfLink కుబెర్నెటీస్ వెర్షన్ 1.20 మరియు చివరిది - 1.21 ద్వారా జరుగుతుంది.

డేటా నిల్వ

మునుపటి విడుదలల మాదిరిగానే నిల్వ ప్రాంతంలోని ప్రధాన పని ఈ ప్రాంతంలో గమనించబడింది CSI మద్దతు. ఇక్కడ ప్రధాన మార్పులు:

• మొదటి సారి (ఆల్ఫా వెర్షన్‌లో) కనిపించాడు Windows వర్కర్ నోడ్‌ల కోసం CSI ప్లగిన్ మద్దతు: స్టోరేజ్‌తో పని చేసే ప్రస్తుత విధానం Kubernetes కోర్‌లోని ఇన్-ట్రీ ప్లగిన్‌లను మరియు Powershell ఆధారంగా Microsoft నుండి FlexVolume ప్లగిన్‌లను కూడా భర్తీ చేస్తుంది;

  
  Windows కోసం Kubernetesలో CSI ప్లగిన్‌లను అమలు చేసే పథకం

• అవకాశం CSI వాల్యూమ్‌ల పరిమాణాన్ని మార్చడం, K8s 1.12లో తిరిగి ప్రవేశపెట్టబడింది, ఇది బీటా వెర్షన్‌కి పెరిగింది;
• స్థానిక అశాశ్వత వాల్యూమ్‌లను రూపొందించడానికి CSIని ఉపయోగించగల సామర్థ్యం ద్వారా ఇదే విధమైన "ప్రమోషన్" (ఆల్ఫా నుండి బీటా వరకు) సాధించబడింది (CSI ఇన్‌లైన్ వాల్యూమ్ సపోర్ట్).

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

షెడ్యూలర్

షెడ్యూలింగ్‌లో రెండు ముఖ్యమైన మార్పులు (రెండూ ఆల్ఫాలో):

• EvenPodsSpreading - అవకాశం లోడ్‌ల "ఫెయిర్ డిస్ట్రిబ్యూషన్" కోసం లాజికల్ అప్లికేషన్ యూనిట్‌లకు బదులుగా పాడ్‌లను ఉపయోగించండి (డిప్లాయ్‌మెంట్ మరియు రెప్లికాసెట్ వంటివి) మరియు ఈ పంపిణీని సర్దుబాటు చేయడం (కఠినమైన అవసరం లేదా సాఫ్ట్ కండిషన్‌గా, అంటే ప్రాధాన్యత). ఈ ఫీచర్ ప్లాన్ చేసిన పాడ్‌ల యొక్క ప్రస్తుత పంపిణీ సామర్థ్యాలను విస్తరిస్తుంది, ప్రస్తుతం ఎంపికల ద్వారా పరిమితం చేయబడింది PodAffinity и PodAntiAffinity, ఈ విషయంలో నిర్వాహకులకు చక్కటి నియంత్రణను ఇవ్వడం, అంటే మెరుగైన అధిక లభ్యత మరియు అనుకూలమైన వనరుల వినియోగం. వివరాలు - లో CAP.
• ఉపయోగం బెస్ట్ ఫిట్ పాలసీ в కెపాసిటీ రేషియో ప్రాధాన్య ఫంక్షన్ కోసం అభ్యర్థించబడింది పాడ్ ప్లానింగ్ సమయంలో, ఇది అనుమతిస్తుంది దరఖాస్తు డబ్బా ప్యాకింగ్ ("కంటైనర్లలో ప్యాకింగ్") ప్రాథమిక వనరులు (ప్రాసెసర్, మెమరీ) మరియు పొడిగించిన వాటి కోసం (GPU వంటివి). మరిన్ని వివరాల కోసం, చూడండి CAP.

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

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

ఇతర మార్పులు

కుబెర్నెట్స్ 1.16 విడుదలలో కూడా మీరు గమనించవచ్చు కోసం చొరవ తీసుకురావడం పూర్తి క్రమంలో అందుబాటులో ఉన్న కొలమానాలు, లేదా మరింత ఖచ్చితంగా, అనుగుణంగా అధికారిక నిబంధనలు K8s ఇన్‌స్ట్రుమెంటేషన్‌కి. వారు ఎక్కువగా సంబంధిత వాటిపై ఆధారపడతారు ప్రోమేతియస్ డాక్యుమెంటేషన్. వివిధ కారణాల వల్ల అసమానతలు తలెత్తాయి (ఉదాహరణకు, ప్రస్తుత సూచనలు కనిపించే ముందు కొన్ని కొలమానాలు సృష్టించబడ్డాయి), మరియు డెవలపర్లు "మిగిలిన ప్రోమేతియస్ పర్యావరణ వ్యవస్థకు అనుగుణంగా" ప్రతిదీ ఒకే ప్రమాణానికి తీసుకురావడానికి ఇది సమయం అని నిర్ణయించుకున్నారు. ఈ చొరవ యొక్క ప్రస్తుత అమలు ఆల్ఫా స్టేటస్‌లో ఉంది, ఇది కుబెర్నెటెస్ యొక్క తదుపరి వెర్షన్‌లలో బీటా (1.17) మరియు స్టేబుల్ (1.18)కి క్రమంగా ప్రచారం చేయబడుతుంది.

అదనంగా, ఈ క్రింది మార్పులను గమనించవచ్చు:

• విండోస్ అభివృద్ధికి మద్దతు ఇస్తుంది с ప్రదర్శన ఈ OS కోసం Kubeadm యుటిలిటీస్ (ఆల్ఫా వెర్షన్), అవకాశం RunAsUserName విండోస్ కంటైనర్‌ల కోసం (ఆల్ఫా వెర్షన్), అభివృద్ధి గ్రూప్ మేనేజ్డ్ సర్వీస్ ఖాతా (gMSA) బీటా వెర్షన్ వరకు మద్దతు, మద్దతు vSphere వాల్యూమ్‌ల కోసం మౌంట్/అటాచ్ చేయండి.
• రీసైకిల్ చేయబడింది API ప్రతిస్పందనలలో డేటా కంప్రెషన్ మెకానిజం. గతంలో, ఈ ప్రయోజనాల కోసం HTTP ఫిల్టర్ ఉపయోగించబడింది, ఇది డిఫాల్ట్‌గా ప్రారంభించబడకుండా నిరోధించే అనేక పరిమితులను విధించింది. "పారదర్శక అభ్యర్థన కుదింపు" ఇప్పుడు పని చేస్తుంది: క్లయింట్లు పంపుతున్నారు Accept-Encoding: gzip హెడర్‌లో, దాని పరిమాణం 128 KB కంటే ఎక్కువగా ఉంటే వారు GZIP-కంప్రెస్డ్ ప్రతిస్పందనను అందుకుంటారు. గో క్లయింట్‌లు స్వయంచాలకంగా కంప్రెషన్‌కు మద్దతు ఇస్తాయి (అవసరమైన హెడర్‌ని పంపడం), కాబట్టి వారు వెంటనే ట్రాఫిక్‌లో తగ్గింపును గమనిస్తారు. (ఇతర భాషలకు స్వల్ప మార్పులు అవసరం కావచ్చు.)
• సాధ్యమైంది బాహ్య కొలమానాల ఆధారంగా స్కేలింగ్ HPA నుండి/సున్నా పాడ్‌ల వరకు. మీరు ఆబ్జెక్ట్‌లు/బాహ్య కొలమానాల ఆధారంగా స్కేల్ చేస్తే, పనిభారం నిష్క్రియంగా ఉన్నప్పుడు మీరు వనరులను సేవ్ చేయడానికి స్వయంచాలకంగా 0 ప్రతిరూపాలకు స్కేల్ చేయవచ్చు. కార్మికులు GPU వనరులను అభ్యర్థించడం మరియు వివిధ రకాల నిష్క్రియ కార్మికుల సంఖ్య అందుబాటులో ఉన్న GPUల సంఖ్య కంటే ఎక్కువగా ఉన్న సందర్భాల్లో ఈ ఫీచర్ ప్రత్యేకంగా ఉపయోగపడుతుంది.
• కొత్త క్లయింట్ - k8s.io/client-go/metadata.Client - వస్తువులకు "సాధారణీకరించిన" యాక్సెస్ కోసం. ఇది మెటాడేటాను సులభంగా తిరిగి పొందేందుకు రూపొందించబడింది (అనగా ఉపవిభాగం metadata) క్లస్టర్ వనరుల నుండి మరియు వారితో చెత్త సేకరణ మరియు కోటా కార్యకలాపాలను నిర్వహించండి.
• కుబెర్నెట్‌లను నిర్మించండి ఇప్పుడు మీరు చేయవచ్చు లెగసీ లేకుండా (“బిల్ట్-ఇన్” ఇన్-ట్రీ) క్లౌడ్ ప్రొవైడర్లు (ఆల్ఫా వెర్షన్).
• కుబేడ్మ్ యుటిలిటీకి జోడించారు ప్రయోగాత్మక (ఆల్ఫా వెర్షన్) కార్యకలాపాల సమయంలో అనుకూలీకరించిన ప్యాచ్‌లను వర్తింపజేయగల సామర్థ్యం init, join и upgrade. జెండాను ఎలా ఉపయోగించాలో మరింత తెలుసుకోండి --experimental-kustomize, లో చూడండి CAP.
• apiserver కోసం కొత్త ముగింపు స్థానం - readyz, - దాని సంసిద్ధత గురించి సమాచారాన్ని ఎగుమతి చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. API సర్వర్ కూడా ఇప్పుడు ఫ్లాగ్‌ని కలిగి ఉంది --maximum-startup-sequence-duration, దాని పునఃప్రారంభాలను నియంత్రించడానికి మిమ్మల్ని అనుమతిస్తుంది.
• రెండు Azure కోసం లక్షణాలు స్థిరంగా ప్రకటించబడింది: మద్దతు లభ్యత మండలాలు (లభ్యత మండలాలు) మరియు క్రాస్ రిసోర్స్ గ్రూప్ (RG). అదనంగా, అజూర్ జోడించారు:
  • ప్రమాణీకరణ మద్దతు AAD మరియు ADFS;
  • నైరూప్య service.beta.kubernetes.io/azure-pip-name లోడ్ బాలన్సర్ యొక్క పబ్లిక్ IPని పేర్కొనడానికి;
  • అవకాశం సెట్టింగులను LoadBalancerName и LoadBalancerResourceGroup.
• AWS ఇప్పుడు ఉంది మద్దతు Windowsలో EBS కోసం మరియు ఆప్టిమైజ్ చేయబడింది EC2 API కాల్‌లు DescribeInstances.
• కుబేద్మ్ ఇప్పుడు స్వతంత్రంగా ఉంది వలసపోతాడు CoreDNS సంస్కరణను అప్‌గ్రేడ్ చేస్తున్నప్పుడు CoreDNS కాన్ఫిగరేషన్.
• బైనరీస్ మొదలైనవి సంబంధిత డాకర్ చిత్రంలో పూర్తి ప్రపంచ-ఎక్జిక్యూటబుల్, ఇది రూట్ హక్కుల అవసరం లేకుండా ఈ చిత్రాన్ని అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. అలాగే, etcd మైగ్రేషన్ ఇమేజ్ ఆగిపోయింది etcd2 వెర్షన్ మద్దతు.
• В క్లస్టర్ ఆటోస్కేలర్ 1.16.0 డిస్ట్రోలెస్‌ని బేస్ ఇమేజ్‌గా ఉపయోగించడం, మెరుగైన పనితీరు, కొత్త క్లౌడ్ ప్రొవైడర్‌లను జోడించడం (డిజిటల్ ఓషన్, మాగ్నమ్, ప్యాకెట్)కి మార్చబడింది.
• ఉపయోగించిన/ఆధారిత సాఫ్ట్‌వేర్‌లో నవీకరణలు: గో 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

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

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

మూలం: www.habr.com