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

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

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

Սկսենք SIG կլաստերի կյանքի ցիկլի կարևոր ներածությունից. դինամիկ ձախողման կլաստերներ Kubernetes-ը (կամ ավելի ճիշտ՝ ինքնակառավարվող HA տեղակայումները) այժմ է կարող է ստեղծվել օգտագործելով ծանոթ (մեկ հանգույցի կլաստերների համատեքստում) հրամաններ kubeadm (init и join) Մի խոսքով, դրա համար.

• կլաստերի կողմից օգտագործվող վկայագրերը փոխանցվում են գաղտնիքներին.
• K8s կլաստերի ներսում etcd կլաստերի օգտագործման հնարավորության համար (այսինքն՝ ազատվել նախկինում գոյություն ունեցող արտաքին կախվածությունից) etcd-օպերատոր;
• Փաստաթղթավորում է արտաքին բեռի հավասարակշռիչի համար առաջարկվող կարգավորումները, որն ապահովում է անսարքության հանդուրժող կոնֆիգուրացիա (ապագայում նախատեսվում է վերացնել այս կախվածությունը, բայց ոչ այս փուլում):

Kubeadm-ով ստեղծված Kubernetes HA կլաստերի ճարտարապետություն

Իրականացման մանրամասներին կարող եք ծանոթանալ այստեղ դիզայնի առաջարկ. Այս ֆունկցիան իսկապես երկար սպասված էր. ալֆա տարբերակը սպասվում էր K8s 1.9-ում, բայց հայտնվեց միայն հիմա:

API

Թիմ apply և ընդհանրապես դեկլարատիվ օբյեկտների կառավարում անցել է - ից kubectl apiserver-ում: Իրենք մշակողները հակիրճ բացատրում են իրենց որոշումը՝ ասելով kubectl apply - Kubernetes-ում կոնֆիգուրացիաների հետ աշխատելու հիմնարար մասն է, այնուամենայնիվ, «այն լի է սխալներով և դժվար է ուղղել», և, հետևաբար, այս ֆունկցիոնալությունը պետք է վերադարձվի նորմալ և փոխանցվի կառավարման հարթություն: Այսօր առկա խնդիրների պարզ և հստակ օրինակներ.

Իրականացման մասին մանրամասները՝ այստեղ KEP. Ընթացիկ պատրաստակամությունը ալֆա է (առաջխաղացում դեպի բետա պլանավորված է Kubernetes-ի հաջորդ թողարկման համար):

Հասանելի է ալֆա տարբերակով առիթ օգտագործելով OpenAPI v3 սխեման համար CustomResources-ի համար OpenAPI փաստաթղթերի ստեղծում և հրապարակում (CR) օգտագործվում է վավերացնելու (սերվերի կողմից) K8s օգտագործողի կողմից սահմանված ռեսուրսները (CustomResourceDefinition, CRD): OpenAPI-ի հրապարակումը CRD-ի համար թույլ է տալիս հաճախորդներին (օրինակ. kubectl) կատարել վավերացում ձեր կողմից (ներսում kubectl create и kubectl apply) և սխեմայի համաձայն թողարկել փաստաթղթեր (kubectl explain) Մանրամասները - մեջ KEP.

Նախապես գոյություն ունեցող տեղեկամատյաններ այժմ բացվում են դրոշով O_APPEND (բայց չէ O_TRUNC) որոշ իրավիճակներում գերանների կորստից խուսափելու և պտտման համար արտաքին կոմունալ տեղեկամատյաններով գերանների կրճատման հարմարության համար:

Նաև Kubernetes API-ի համատեքստում կարելի է նշել, որ ներս PodSandbox и PodSandboxStatus ավելացրել է դաշտը runtime_handler մասին տեղեկություններ գրանցելու համար RuntimeClass պատիճում (այդ մասին ավելին կարդացեք տեքստում Kubernetes 1.12 թողարկում, որտեղ այս դասը հայտնվել է որպես ալֆա տարբերակ), և Admission Webhooks-ում իրականացվել է կարողություն որոշելու, թե որ տարբերակները AdmissionReview նրանք աջակցում են. Վերջապես, ընդունելության Webhooks-ի կանոններն այժմ են կարող է սահմանափակվել դրանց օգտագործման չափը՝ ըստ անվանատարածքների և կլաստերային շրջանակների:

Պահպանում

PersistentLocalVolumes, որը թողարկվելուց հետո ուներ բետա կարգավիճակ K8s 1.10, հայտարարվեց կայուն (GA). այս գործառույթի դարպասն այլևս անջատված չէ և կհեռացվի Kubernetes 1.17-ում:

Հնարավորություն օգտագործելով շրջակա միջավայրի փոփոխականներ, որոնք կոչվում են Downward API (օրինակ՝ pod անվանումը) դիրեկտորիաների անունների համար, որոնք տեղադրված են որպես subPath, մշակվել է՝ նոր դաշտի տեսքով subPathExpr, որն այժմ օգտագործվում է ցանկալի գրացուցակի անունը որոշելու համար: Հատկանիշը սկզբում հայտնվել է Kubernetes 1.11-ում, սակայն 1.14-ի համար այն մնացել է ալֆա տարբերակի կարգավիճակում։

Ինչպես Kubernetes-ի նախորդ թողարկման դեպքում, շատ էական փոփոխություններ են ներդրվել ակտիվորեն զարգացող CSI-ի համար (Container Storage Interface).

CSI- ն

Հասանելի դարձավ (որպես ալֆա տարբերակի մաս) աջակցություն CSI հատորների չափափոխում. Այն օգտագործելու համար դուք պետք է միացնեք կոչվող գործառույթի դարպասը ExpandCSIVolumes, ինչպես նաև այս գործողության համար աջակցության առկայությունը կոնկրետ CSI դրայվերում:

Մեկ այլ առանձնահատկություն CSI-ի համար ալֆա տարբերակում. առիթ ուղղակիորեն (այսինքն՝ առանց PV/PVC-ի օգտագործման) CSI հատորներին՝ պատի հստակեցման շրջանակներում: Սա վերացնում է CSI-ի օգտագործման սահմանափակումը որպես բացառապես հեռավոր տվյալների պահպանման, նրանց համար դռներ բացելով դեպի աշխարհ տեղական ժամանակավոր ծավալներ. Օգտագործման համար (օրինակ փաստաթղթերից) պետք է միացված լինի CSIInlineVolume խաղարկային դարպաս.

Առաջընթաց է նկատվել նաև Kubernetes-ի «ներքին»՝ կապված CSI-ի հետ, որոնք այնքան էլ տեսանելի չեն վերջնական օգտատերերի (համակարգի ադմինիստրատորների) համար... Ներկայումս մշակողները ստիպված են աջակցել յուրաքանչյուր պահեստավորման պլագինի երկու տարբերակ. հին ձևով», K8s կոդերի բազայի ներսում (in-tree), իսկ երկրորդը՝ որպես նոր CSI-ի մաս: (այդ մասին ավելին կարդացեք, օրինակ, ներ այստեղ). Սա հասկանալի անհարմարություններ է առաջացնում, որոնք պետք է լուծվեն, քանի որ ՔՀԻ-ն ինքնին կայունանում է: Հնարավոր չէ պարզապես չեղարկել ներքին (ծառի մեջ) պլագինների API-ը, քանի որ համապատասխան Kubernetes քաղաքականություն.

Այս ամենը հանգեցրեց նրան, որ ալֆա տարբերակը հասավ միգրացիոն գործընթաց ներքին plugin կոդը, ներդրված որպես in-tree, CSI պլագիններում, ինչի շնորհիվ ծրագրավորողների մտահոգությունները կնվազեցվեն իրենց փլագինների մեկ տարբերակի աջակցությամբ, իսկ հին API-ների հետ համատեղելիությունը կմնա, և դրանք կարող են հնացած հայտարարվել սովորական սցենարով: Ակնկալվում է, որ մինչև Kubernetes-ի հաջորդ թողարկումը (1.15) ամպային մատակարարների բոլոր պլագինները կփոխանցվեն, իրականացումը կստանա բետա կարգավիճակ և լռելյայն կակտիվանա K8s-ի տեղադրումներում: Մանրամասների համար տե՛ս դիզայնի առաջարկ. Այս գաղթը նույնպես հանգեցրեց մերժումը որոշակի ամպային մատակարարների կողմից սահմանված ծավալի սահմանաչափերից (AWS, Azure, GCE, Cinder):

Բացի այդ, աջակցություն բլոկ սարքերին CSI-ով (CSIBlockVolume) փոխանցվել է դեպի բետա տարբերակ:

Հանգույցներ / Kubelet

Ներկայացված է ալֆա տարբերակը նոր վերջնակետ Կուբելեթում, նախատեսված է վերադարձի չափումներ հիմնական ռեսուրսների վրա. Ընդհանրապես, եթե նախկինում Kubelet-ը cAdvisor-ից ստանում էր կոնտեյների օգտագործման վիճակագրություն, այժմ այս տվյալները գալիս են կոնտեյների գործարկման միջավայրից՝ CRI-ի (Container Runtime Interface) միջոցով, սակայն Docker-ի հին տարբերակների հետ աշխատելու համատեղելիությունը նույնպես պահպանվում է: Նախկինում Kubelet-ում հավաքագրված վիճակագրությունն ուղարկվում էր REST API-ի միջոցով, սակայն այժմ վերջնակետը գտնվում է /metrics/resource/v1alpha1. Մշակողների երկարաժամկետ ռազմավարություն բաղկացած է Kubelet-ի կողմից տրամադրված չափումների հավաքածուն նվազագույնի հասցնելն է: Ի դեպ, այս ցուցանիշներն իրենք են հիմա զանգում են ոչ թե «հիմնական չափումներ», այլ «ռեսուրսների չափումներ» և նկարագրվում են որպես «առաջին կարգի ռեսուրսներ, ինչպիսիք են պրոցեսորը և հիշողությունը»:

Շատ հետաքրքիր նրբերանգ. չնայած gRPC վերջնական կետի հստակ կատարողական առավելությունին Պրոմեթևսի ձևաչափի օգտագործման տարբեր դեպքերի համեմատ (տե՛ս ստորև նշված չափանիշներից մեկի արդյունքը), հեղինակները նախընտրել են Պրոմեթևսի տեքստային ձևաչափը՝ համայնքում մոնիտորինգի այս համակարգի հստակ առաջնորդության շնորհիվ։

«gRPC-ն համատեղելի չէ հիմնական մոնիտորինգային խողովակաշարերի հետ: Վերջնակետը օգտակար կլինի միայն չափիչները Metrics սերվերին կամ մոնիտորինգի բաղադրիչներին, որոնք ուղղակիորեն ինտեգրվում են դրա հետ: Prometheus տեքստի ձևաչափի կատարումը Metrics Server-ում քեշավորում օգտագործելիս բավական լավ Որպեսզի մենք նախընտրենք Պրոմեթևսը gRPC-ից, հաշվի առնելով Պրոմեթևսի լայն տարածումը համայնքում: Երբ OpenMetrics ձևաչափը դառնա ավելի կայուն, մենք կկարողանանք մոտենալ gRPC-ի կատարմանը պրոտո-հիմնված ձևաչափով»:

Նոր Kubelet-ի վերջնական կետում չափումների համար gRPC և Prometheus ձևաչափերի օգտագործման համեմատական ​​կատարողական թեստերից մեկը: Լրացուցիչ գրաֆիկներ և այլ մանրամասներ կարելի է գտնել այստեղ KEP.

Ի թիվս այլ փոփոխությունների.

• Kubelet այժմ (մեկ անգամ) փորձում է կանգնեցնել կոնտեյներներ անհայտ վիճակում նախքան վերագործարկվելը և ջնջելը:
• Օգտագործելիս PodPresets հիմա դեպի սկզբնական կոնտեյներ ավելացված է նույն տեղեկատվությունը, ինչ սովորական կոնտեյների համար:
• Կուբելետ սկսել է օգտագործել usageNanoCores CRI վիճակագրության մատակարարից և Windows-ի հանգույցների և կոնտեյներների համար ավելացրել է ցանցի վիճակագրություն.
• Օպերացիոն համակարգի և ճարտարապետության մասին տեղեկությունները այժմ գրանցված են պիտակներում kubernetes.io/os и kubernetes.io/arch Հանգույցի օբյեկտներ (փոխանցված բետա-ից GA):
• Համակարգի հատուկ օգտվողների խումբ նշելու հնարավորություն բեռնարկղերի համար (RunAsGroup, հայտնվել է K8s 1.11) առաջադեմ նախքան բետա (միացված է լռելյայն):
• du and find used in cAdvisor, փոխարինվել է on Go իրականացում:

CLI

cli-runtime-ում և kubectl-ում ավելացրեց -k դրոշ ինտեգրվելու համար հարմարեցնել (ի դեպ, դրա մշակումն այժմ իրականացվում է առանձին պահեստում), այսինքն. լրացուցիչ YAML ֆայլեր մշակելու հատուկ kustomization դիրեկտորիաներից (դրանց օգտագործման մանրամասների համար տե՛ս KEP):

Պարզ ֆայլի օգտագործման օրինակ հարմարեցում (Հնարավոր է kustomize-ի ավելի բարդ կիրառում ներսում երեսապատում)

Բացի այդ,

• Ավելացված է նոր թիմ kubectl create cronjob, որի անունը խոսում է ինքնին.
• В kubectl logs այժմ դուք կարող եք համատեղել դրոշներ -f (--follow հոսքային տեղեկամատյանների համար) և -l (--selector պիտակի հարցման համար):
• կուբեկտլ սովորեցրել է պատճենեք wild card-ով ընտրված ֆայլերը:
• Թիմին kubectl wait ավելացվել է դրոշ --all նշված ռեսուրսի տեսակի անվանատարածքում բոլոր ռեսուրսները ընտրելու համար:

ՈՒրիշ

Հետևյալ հնարավորությունները ստացել են կայուն (GA) կարգավիճակ.

• ReadinessGate, օգտագործվում է պատիճ ճշգրտման մեջ՝ լրացուցիչ պայմաններ սահմանելու համար, որոնք հաշվի են առնվում պատի պատրաստության մեջ.
• Աջակցություն մեծ էջերի համար (կոչվում է խաղարկային դարպաս HugePages);
• CustomPodDNS;
• PriorityClass API Pod Priority & Preemption.

Kubernetes 1.14-ում ներկայացված այլ փոփոխություններ.

• Կանխադրված RBAC քաղաքականությունն այլևս թույլ չի տալիս մուտք գործել API discovery и access-review օգտվողներ առանց նույնականացման (չնույնականացված).
• Պաշտոնական CoreDNS աջակցություն ապահովված է Միայն Linux-ը, այնպես որ, երբ օգտագործում եք kubeadm՝ այն (CoreDNS) կլաստերում տեղակայելու համար, հանգույցները պետք է աշխատեն միայն Linux-ով (այս սահմանափակման համար օգտագործվում են nodeSelectors):
• Կանխադրված CoreDNS կազմաձևումն այժմ է օգտագործում առաջ plugin վստահված անձի փոխարեն: Նաև CoreDNS-ում ավելացրել է ReadinessProbe, որը կանխում է բեռի հավասարակշռումը համապատասխան (սպասարկման համար պատրաստ չէ) պատյանների վրա:
• Kubeadm-ում, փուլերի վրա init կամ upload-certs, հնարավոր դարձավ բեռնեք նոր կառավարման ինքնաթիռը kubeadm-certs գաղտնիքին միացնելու համար անհրաժեշտ վկայականները (օգտագործեք դրոշը --experimental-upload-certs).
• Windows-ի տեղադրման համար ալֆա տարբերակ է հայտնվել աջակցություն gMSA (Group Managed Service Account) - հատուկ հաշիվներ Active Directory-ում, որոնք կարող են օգտագործվել նաև բեռնարկղերի կողմից:
• Համար G.C.E. ակտիվացված mTLS կոդավորումը etcd-ի և kube-apiserver-ի միջև:
• Օգտագործված/կախված ծրագրաշարի թարմացումներ. Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 աջակցություն kubeadm-ում, իսկ Docker API-ի նվազագույն աջակցվող տարբերակն այժմ 1.26 է:

PS

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

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

Source: www.habr.com