Kubernetes 1.16. հիմնական նորամուծությունների ակնարկ

Այսօր՝ չորեքշաբթի, տեղի է ունեցել Kubernetes-ի հաջորդ թողարկումը՝ 1.16. Մեր բլոգի համար ձևավորված ավանդույթի համաձայն՝ արդեն տասներորդ տարեդարձն է, ինչ խոսում ենք նոր տարբերակի ամենաէական փոփոխությունների մասին։

Այս նյութը պատրաստելու համար օգտագործված տեղեկատվությունը վերցված է Kubernetes բարելավումների հետագծման աղյուսակներ, ՓՈՓՈԽՈՒԹՅՈՒՆ-1.16 և հարակից հարցեր, ձգողականության հարցումներ և Kubernetes-ի ընդլայնման առաջարկներ (KEP): Այսպիսով, եկեք գնանք..

Հանգույցներ

Իսկապես մեծ թվով նշանակալի նորամուծություններ (ալֆա տարբերակի կարգավիճակում) ներկայացված են K8s կլաստերային հանգույցների կողքին (Kubelet):

Նախ, այսպես կոչված «վաղանցիկ տարաներ» (Վերջնական տարաներ), նախագծված է հեշտացնելու վրիպազերծման գործընթացները pods-ում. Նոր մեխանիզմը թույլ է տալիս գործարկել հատուկ բեռնարկղեր, որոնք սկսվում են գոյություն ունեցող պատիճների անվանատարածքից և ապրում են կարճ ժամանակով։ Նրանց նպատակն է փոխազդել այլ պատյանների և տարաների հետ՝ ցանկացած խնդիր լուծելու և վրիպազերծելու համար: Այս ֆունկցիայի համար ներդրվել է նոր հրաման kubectl debug, ըստ էության նման kubectl execՄիայն կոնտեյներով գործընթացն իրականացնելու փոխարեն (ինչպես exec) այն գործարկում է կոնտեյներ պատիճով: Օրինակ, այս հրամանը նոր կոնտեյներ կմիացնի պատիճին.

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

Ժամանակավոր տարաների մասին մանրամասները (և դրանց օգտագործման օրինակները) կարելի է գտնել այստեղ համապատասխան KEP. Ներկայիս ներդրումը (K8s 1.16-ում) ալֆա տարբերակ է, և դրա բետա տարբերակ տեղափոխելու չափանիշներից է «Ephemeral Containers API-ի փորձարկումը [Kubernetes]-ի առնվազն 2 թողարկումների համար»:

NBԻր էությամբ և նույնիսկ իր անունով, հատկանիշը նման է արդեն գոյություն ունեցող փլագինին kubectl-debugորի մասին մենք արդեն գրված. Ակնկալվում է, որ ժամանակավոր բեռնարկղերի հայտնվելով առանձին արտաքին պլագինի մշակումը կդադարի։

Մեկ այլ նորամուծություն. PodOverhead - նախատեսված է ապահովելու համար պատիճների համար ընդհանուր ծախսերի հաշվարկման մեխանիզմ, որը կարող է շատ տարբեր լինել՝ կախված օգտագործվող գործարկման ժամանակից: Որպես օրինակ՝ հեղինակները այս KEP արդյունքում կատա կոնտեյներներ, որոնք պահանջում են գործարկել հյուրի միջուկը, կատա գործակալը, init համակարգը և այլն: Երբ վերադիր ծախսերը դառնում են այդքան մեծ, այն չի կարելի անտեսել, ինչը նշանակում է, որ պետք է լինի միջոց՝ հաշվի առնելու հետագա քվոտաները, պլանավորումը և այլն: Այն իրականացնելու համար PodSpec դաշտն ավելացվել է Overhead *ResourceList (համեմատվում է տվյալների հետ RuntimeClass, եթե մեկը օգտագործվում է):

Մեկ այլ ուշագրավ նորամուծություն հանգույցի տոպոլոգիայի կառավարիչ (Հանգույցի տոպոլոգիայի մենեջեր), որը նախատեսված է Kubernetes-ում տարբեր բաղադրիչների համար ապարատային ռեսուրսների բաշխման ճշգրտման մոտեցումը միավորելու համար: Այս նախաձեռնությունը պայմանավորված է տարբեր ժամանակակից համակարգերի աճող անհրաժեշտությամբ (հեռահաղորդակցության, մեքենայական ուսուցման, ֆինանսական ծառայությունների և այլն) բարձր արդյունավետության զուգահեռ հաշվարկների և գործառնությունների կատարման հետաձգումները նվազագույնի հասցնելու համար, որոնց համար նրանք օգտագործում են առաջադեմ CPU և ապարատային արագացման հնարավորություններ. Kubernetes-ում նման օպտիմալացումները մինչ այժմ ձեռք են բերվել տարբեր բաղադրիչների շնորհիվ (CPU մենեջեր, Սարքի կառավարիչ, CNI), և այժմ դրանց կավելացվի մեկ ներքին ինտերֆեյս, որը միավորում է մոտեցումը և հեշտացնում է նոր նմանատիպ, այսպես կոչված, տոպոլոգիա- կապը: տեղյակ - բաղադրիչներ Kubelet կողմում: Մանրամասները - մեջ համապատասխան KEP.

Տոպոլոգիայի մենեջերի բաղադրիչի դիագրամ

Հաջորդ հատկանիշը - ստուգել բեռնարկղերը, երբ դրանք աշխատում են (մեկնարկային զոնդ). Ինչպես գիտեք, բեռնարկղերի համար, որոնց գործարկումը երկար ժամանակ է պահանջվում, դժվար է ստանալ արդի կարգավիճակ. դրանք կա՛մ «սպանվում են» մինչև իրականում սկսելը գործել, կա՛մ երկար ժամանակ հայտնվում են փակուղում: Նոր ստուգում (միացված է գործառույթի դարպասի միջոցով StartupProbeEnabled) չեղարկում է, ավելի ճիշտ՝ հետաձգում է ցանկացած այլ ստուգումների ազդեցությունը մինչև այն պահը, երբ պատիճը կավարտի աշխատանքը: Այդ իսկ պատճառով ֆունկցիան ի սկզբանե կոչվել է pod-startup liveness-probe holdoff. Այն պատիճների համար, որոնց մեկնարկը երկար ժամանակ է պահանջվում, դուք կարող եք հարցումներ կատարել նահանգի մասին համեմատաբար կարճ ժամանակային ընդմիջումներով:

Բացի այդ, RuntimeClass-ի բարելավումը անմիջապես հասանելի է բետա կարգավիճակում՝ ավելացնելով աջակցություն «տարասեռ կլաստերների համար»: Գ RuntimeClass Scheduling Այժմ ամենևին էլ պարտադիր չէ, որ յուրաքանչյուր հանգույց աջակցություն ունենա յուրաքանչյուր RuntimeClass-ի համար. pods-ի համար կարող եք ընտրել RuntimeClass՝ առանց մտածելու կլաստերային տոպոլոգիայի մասին: Նախկինում, դրան հասնելու համար, որպեսզի պատիճները հայտնվեն հանգույցների վրա, որոնք աջակցում են այն ամենին, ինչ անհրաժեշտ է, անհրաժեշտ էր համապատասխան կանոններ նշանակել NodeSelector-ին և tolerations-ին: IN KEP Այն խոսում է օգտագործման օրինակների և, իհարկե, իրականացման մանրամասների մասին։

Сеть

Կուբերնետես 1.16-ում առաջին անգամ (ալֆա տարբերակով) հայտնված ցանցային երկու կարևոր առանձնահատկություններն են.

• Աջակցություն երկակի ցանցի կույտ - IPv4/IPv6 - և դրա համապատասխան «ըմբռնումը» պատիճների, հանգույցների, ծառայությունների մակարդակում: Այն ներառում է IPv4-ից-IPv4 և IPv6-ից-IPv6-ի փոխգործունակությունը պատիճների միջև՝ պատյաններից մինչև արտաքին ծառայություններ, տեղեկանքների իրականացում (Bridge CNI, PTP CNI և Host-Local IPAM պլագինների շրջանակներում), ինչպես նաև հակադարձ Համատեղելի է Kubernetes կլաստերների հետ: Միայն IPv4 կամ IPv6: Իրականացման մանրամասները ներկայացված են KEP.

  Փոդների ցանկում երկու տեսակի (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 վերջնական կետի համար - EndpointSlice API. Այն լուծում է գոյություն ունեցող Endpoint API-ի կատարողականի/ճշտականության խնդիրները, որոնք ազդում են կառավարման հարթության տարբեր բաղադրիչների վրա (apiserver, etcd, endpoints-controller, kube-proxy): Նոր API-ն կավելացվի Discovery API խմբին և կկարողանա սպասարկել տասնյակ հազարավոր հետին վերջնակետեր յուրաքանչյուր ծառայության վրա հազարավոր հանգույցներից բաղկացած կլաստերի մեջ։ Դա անելու համար յուրաքանչյուր ծառայություն քարտեզագրվում է N օբյեկտների վրա EndpointSlice, որոնցից յուրաքանչյուրը լռելյայն ունի ոչ ավելի, քան 100 վերջնակետ (արժեքը կարգավորելի է): EndpointSlice API-ն նաև հնարավորություններ կստեղծի իր ապագա զարգացման համար. յուրաքանչյուր pod-ի համար բազմաթիվ IP հասցեների աջակցություն, վերջնակետերի նոր վիճակներ (ոչ միայն Ready и NotReady), վերջնակետերի դինամիկ ենթախմբավորում:

Վերջին թողարկումում ներկայացվածը հասել է բետա տարբերակի վերջնականացուցիչանունով service.kubernetes.io/load-balancer-cleanup և յուրաքանչյուր ծառայությանը կցվում է տեսակով LoadBalancer. Նման ծառայությունը ջնջելու պահին այն կանխում է ռեսուրսի իրական ջնջումը, քանի դեռ չի ավարտվել բոլոր համապատասխան հավասարակշռող ռեսուրսների «մաքրումը»:

API մեքենաներ

Իրական «կայունացման հանգրվանը» գտնվում է Kubernetes API սերվերի և դրա հետ փոխգործակցության տարածքում: Դա տեղի ունեցավ հիմնականում շնորհիվ կայուն կարգավիճակի տեղափոխում նրանց, ովքեր հատուկ ծանոթության կարիք չունեն Պատվերով ռեսուրսների սահմանումներ (CRD), որոնք բետա կարգավիճակ ունեն Kubernetes 1.7-ի հեռավոր օրերից (և սա 2017թ. հունիսն է): Նույն կայունացումը եկավ հարակից հատկանիշներին.

• «ենթաղբյուրներ» հետ /status и /scale CustomResources-ի համար;
• փոխակերպումը տարբերակներ CRD-ի համար՝ հիմնված արտաքին վեբ-կեռիկի վրա;
• վերջերս ներկայացված (K8s 1.15-ում) լռելյայն արժեքներ (կանխադրված) և դաշտի ավտոմատ հեռացում (էտում) CustomResources-ի համար;
• առիթ օգտագործելով OpenAPI v3 սխեման՝ OpenAPI փաստաթղթեր ստեղծելու և հրապարակելու համար, որոնք օգտագործվում են սերվերի կողմից CRD ռեսուրսները վավերացնելու համար:

Մեկ այլ մեխանիզմ, որը վաղուց արդեն ծանոթ է Kubernetes-ի ադմինիստրատորներին. ընդունելության կայք - նույնպես երկար ժամանակ մնաց բետա կարգավիճակում (K8s 1.9-ից սկսած) և այժմ հայտարարված է կայուն:

Երկու այլ առանձնահատկություններ հասել են բետա. կիրառվում է սերվերի կողմից и դիտել էջանիշները.

Իսկ ալֆա տարբերակում միակ նշանակալի նորամուծությունը եղել է մերժումը - ից SelfLink — հատուկ URI, որը ներկայացնում է նշված օբյեկտը և մաս է կազմում ObjectMeta и ListMeta (այսինքն՝ Կուբերնետեսի ցանկացած օբյեկտի մի մասը): Ինչու են նրանք հրաժարվում դրանից: Մոտիվացիա պարզ ձևով հնչյուններ քանի որ այս դաշտի դեռ գոյություն ունենալու իրական (ճնշող) պատճառների բացակայությունը։ Ավելի պաշտոնական պատճառներն են՝ օպտիմիզացնել կատարումը (հեռացնելով ավելորդ դաշտը) և պարզեցնել ընդհանուր ապիսերվերի աշխատանքը, որը ստիպված է հատուկ կերպով վարել այդպիսի դաշտը (սա միակ դաշտն է, որը դրված է անմիջապես օբյեկտի առջև։ սերիականացված է): Իրական հնացում (բետա-ի սահմաններում) SelfLink տեղի կունենա Kubernetes տարբերակով 1.20, իսկ վերջնականը` 1.21:

Տվյալների պահպանում

Հիմնական աշխատանքը պահեստավորման տարածքում, ինչպես նախորդ թողարկումներում, նկատվում է տարածքում CSI աջակցություն. Այստեղ հիմնական փոփոխություններն էին.

• առաջին անգամ (ալֆա տարբերակով) հայտնվեց CSI plugin-ի աջակցություն Windows աշխատանքային հանգույցների համարՊահեստավորման հետ աշխատելու ներկայիս ձևը կփոխարինի նաև «Kubernetes» հիմնական և «Microsoft»-ի FlexVolume պլագիններին՝ հիմնված Powershell-ի վրա.

  
  Windows-ի համար Kubernetes-ում CSI պլագինների ներդրման սխեմա

• առիթ CSI ծավալների չափափոխում, որը ներկայացվել է դեռևս K8s 1.12-ում, դարձել է բետա տարբերակ;
• Նմանատիպ «առաջխաղացում» (ալֆայից բետա) ձեռք է բերվել CSI-ի օգտագործման ունակությամբ՝ տեղական ժամանակավոր ծավալներ ստեղծելու համար (CSI Inline Volume Support).

Ներկայացված է Kubernetes-ի նախորդ տարբերակում ծավալի կլոնավորման գործառույթ (օգտագործելով գոյություն ունեցող PVC որպես DataSource ստեղծել նոր PVC) նույնպես այժմ ստացել է բետա կարգավիճակ:

Ժամանակացույց

Պլանավորման երկու ուշագրավ փոփոխություն (երկուսն էլ ալֆայում).

• EvenPodsSpreading - հնարավորություն բեռների «արդար բաշխման» համար օգտագործեք պատյաններ տրամաբանական կիրառական միավորների փոխարեն (ինչպես Deployment-ը և ReplicaSet-ը) և կարգավորելով այս բաշխումը (որպես ծանր պահանջ կամ որպես փափուկ պայման, այսինքն՝ առաջնահերթություն): Հատկանիշը կընդլայնի ծրագրված պատիճների բաշխման առկա հնարավորությունները, որոնք ներկայումս սահմանափակված են տարբերակներով PodAffinity и PodAntiAffinity, տալով ադմինիստրատորներին այս հարցում ավելի նուրբ վերահսկողություն, ինչը նշանակում է ավելի լավ բարձր հասանելիություն և ռեսուրսների օպտիմիզացված սպառում: Մանրամասները՝ մեջ KEP.
• Օգտագործում BestFit քաղաքականություն в RequestedToCapacityRatio առաջնահերթ գործառույթ պատիճ պլանավորման ժամանակ, ինչը թույլ կտա դիմել աղբամանների փաթեթավորում («Փաթեթավորում բեռնարկղերի մեջ») և՛ հիմնական ռեսուրսների (պրոցեսոր, հիշողություն), և՛ ընդլայնված (օրինակ՝ GPU): Լրացուցիչ մանրամասների համար տե՛ս KEP.

  
  Պլանավորման պատյաններ. նախքան լավագույնս հարմարեցված քաղաքականությունը օգտագործելը (ուղղակիորեն լռելյայն ժամանակացույցի միջոցով) և դրա օգտագործումը (ժամանակացույցի երկարացման միջոցով)

Բացի այդ, ներկայացված է ձեր սեփական ժամանակացույցի պլագինները ստեղծելու ունակություն Kubernetes-ի հիմնական զարգացման ծառից դուրս (ծառից դուրս):

Այլ փոփոխություններ

Նաև Kubernetes 1.16 թողարկումում կարելի է նշել նախաձեռնության համար բերելով հասանելի չափումները լրիվ կարգով, իսկ ավելի ճիշտ՝ համապատասխան պաշտոնական կանոնակարգերը դեպի K8s գործիքավորում: Նրանք մեծապես հենվում են համապատասխանի վրա Պրոմեթևսի փաստաթղթեր. Անհամապատասխանություններ առաջացան տարբեր պատճառներով (օրինակ, որոշ չափումներ պարզապես ստեղծվեցին մինչև ընթացիկ հրահանգների հայտնվելը), և մշակողները որոշեցին, որ ժամանակն է ամեն ինչ բերել մեկ ստանդարտի, «համապատասխանեցված Պրոմեթևսի մնացած էկոհամակարգին»: Այս նախաձեռնության ներկայիս իրականացումը գտնվում է ալֆա կարգավիճակում, որն աստիճանաբար կխթանի Kubernetes-ի հետագա տարբերակներում բետա (1.17) և կայուն (1.18):

Բացի այդ, կարելի է նշել հետևյալ փոփոխությունները.

• Windows-ի աջակցության մշակում с տեսքը Kubeadm կոմունալ ծառայություններ այս ՕՀ-ի համար (ալֆա տարբերակ), հնարավորություն RunAsUserName Windows բեռնարկղերի համար (ալֆա տարբերակ), բարելավում Խմբի կառավարվող ծառայության հաշվի (gMSA) աջակցություն մինչև բետա տարբերակը, աջակցություն տեղադրել/կցել vSphere հատորների համար:
• Վերամշակված տվյալների սեղմման մեխանիզմը API-ի պատասխաններում. Նախկինում այս նպատակների համար օգտագործվում էր HTTP զտիչ, որը սահմանում էր մի շարք սահմանափակումներ, որոնք թույլ չէին տալիս այն լռելյայն միացնել: «Թափանցիկ հարցումների սեղմումը» այժմ աշխատում է. հաճախորդների ուղարկում Accept-Encoding: gzip վերնագրում նրանք ստանում են GZIP սեղմված պատասխան, եթե դրա չափը գերազանցում է 128 ԿԲ-ը: Go-հաճախորդներն ավտոմատ կերպով աջակցում են սեղմմանը (ուղարկելով անհրաժեշտ վերնագիրը), այնպես որ նրանք անմիջապես կնկատեն տրաֆիկի կրճատում: (Մի փոքր փոփոխություններ կարող են անհրաժեշտ լինել այլ լեզուների համար):
• Հնարավոր դարձավ HPA-ի մասշտաբավորումը/մինչև զրոյական պատյաններ՝ հիմնված արտաքին չափումների վրա. Եթե ​​դուք չափում եք օբյեկտների/արտաքին չափումների հիման վրա, ապա, երբ աշխատանքային ծանրաբեռնվածությունը անգործուն է, դուք կարող եք ավտոմատ կերպով չափել մինչև 0 կրկնօրինակ՝ ռեսուրսները խնայելու համար: Այս հատկությունը պետք է հատկապես օգտակար լինի այն դեպքերում, երբ աշխատողները պահանջում են GPU ռեսուրսներ, և տարբեր տեսակի պարապ աշխատողների թիվը գերազանցում է հասանելի GPU-ների թիվը:
• Նոր հաճախորդ - k8s.io/client-go/metadata.Client - օբյեկտների «ընդհանրացված» մուտքի համար: Այն նախագծված է հեշտությամբ վերբերելու մետատվյալները (այսինքն՝ ենթաբաժին metadata) կլաստերային ռեսուրսներից և դրանցով կատարել աղբահանության և քվոտավորման գործողություններ:
• Կառուցեք Kubernetes այժմ դուք կարող եք առանց ժառանգական («ներկառուցված» ծառի մեջ) ամպային մատակարարների (ալֆա տարբերակ):
• Kubeadm կոմունալ ծրագրին ավելացվել է փորձարարական (ալֆա տարբերակ) գործողությունների ընթացքում հարմարեցված կարկատաններ կիրառելու ունակություն init, join и upgrade. Իմացեք ավելին, թե ինչպես օգտագործել դրոշը --experimental-kustomize, տես ներս KEP.
• Նոր վերջնակետ apiserver-ի համար. readyz, - թույլ է տալիս արտահանել տեղեկատվություն դրա պատրաստակամության մասին: API սերվերը նույնպես այժմ ունի դրոշ --maximum-startup-sequence-duration, որը թույլ է տալիս կարգավորել դրա վերագործարկումը:
• Երկու առանձնահատկություններ Azure-ի համար հայտարարվել է կայուն՝ աջակցություն մատչելիության գոտիներ (Հասանելիության գոտիներ) և խաչաձեւ ռեսուրսների խումբ (RG): Բացի այդ, Azure-ն ավելացրել է.
  • նույնականացման աջակցություն AAD և ADFS;
  • անոտացիա service.beta.kubernetes.io/azure-pip-name նշեք բեռի հավասարակշռողի հանրային IP-ն.
  • առիթ պարամետրերը LoadBalancerName и LoadBalancerResourceGroup.
• AWS-ն այժմ ունի աջակցություն EBS-ի համար Windows-ում և օպտիմիզացված EC2 API զանգեր DescribeInstances.
• Kubeadm-ն այժմ անկախ է գաղթում է CoreDNS-ի կոնֆիգուրացիա CoreDNS-ի տարբերակը թարմացնելիս:
• Երկուականներ և այլն համապատասխան Docker պատկերում արել են world-executable, որը թույլ է տալիս գործարկել այս պատկերը՝ առանց արմատային իրավունքների անհրաժեշտության: Նաև, etcd միգրացիայի պատկերը դադարեցրեց etcd2 տարբերակի աջակցություն:
• В Cluster Autoscaler 1.16.0 անցել է առանց ցրելու որպես հիմնական պատկեր օգտագործելու, բարելավված կատարողականություն, ավելացվել են նոր ամպային մատակարարներ (DigitalOcean, Magnum, Packet):
• Օգտագործված/կախված ծրագրաշարի թարմացումներ. Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2:

PS

Կարդացեք նաև մեր բլոգում.

• «Kubernetes 1.15. հիմնական նորամուծությունների ակնարկ";
• «Kubernetes 1.14. հիմնական նորամուծությունների ակնարկ";
• «Kubernetes 1.13. հիմնական նորամուծությունների ակնարկ";
• «Kubernetes 1.12. հիմնական նորամուծությունների ակնարկ.

Source: www.habr.com