Kubernetes 1.16. հիմնական նորամուծությունների ակնարկ
Այսօր՝ չորեքշաբթի, տեղի է ունեցել Kubernetes-ի հաջորդ թողարկումը՝ 1.16. Մեր բլոգի համար ձևավորված ավանդույթի համաձայն՝ արդեն տասներորդ տարեդարձն է, ինչ խոսում ենք նոր տարբերակի ամենաէական փոփոխությունների մասին։
Իսկապես մեծ թվով նշանակալի նորամուծություններ (ալֆա տարբերակի կարգավիճակում) ներկայացված են K8s կլաստերային հանգույցների կողքին (Kubelet):
Նախ, այսպես կոչված «վաղանցիկ տարաներ» (Վերջնական տարաներ), նախագծված է հեշտացնելու վրիպազերծման գործընթացները pods-ում. Նոր մեխանիզմը թույլ է տալիս գործարկել հատուկ բեռնարկղեր, որոնք սկսվում են գոյություն ունեցող պատիճների անվանատարածքից և ապրում են կարճ ժամանակով։ Նրանց նպատակն է փոխազդել այլ պատյանների և տարաների հետ՝ ցանկացած խնդիր լուծելու և վրիպազերծելու համար: Այս ֆունկցիայի համար ներդրվել է նոր հրաման kubectl debug, ըստ էության նման kubectl execՄիայն կոնտեյներով գործընթացն իրականացնելու փոխարեն (ինչպես exec) այն գործարկում է կոնտեյներ պատիճով: Օրինակ, այս հրամանը նոր կոնտեյներ կմիացնի պատիճին.
Ժամանակավոր տարաների մասին մանրամասները (և դրանց օգտագործման օրինակները) կարելի է գտնել այստեղ համապատասխան 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-ի օգտագործման ունակությամբ՝ տեղական ժամանակավոր ծավալներ ստեղծելու համար (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-ն ավելացրել է.
անոտացիա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: