🥇Kubernetes 1.17: հիմնական նորությունները

Երեկ, դեկտեմբերի 9-ին, կայացավ կայացել է Kubernetes-ի նոր թողարկումը՝ 1.17։ Մեր blogue ավանդույթի համաձայն, մենք ձեզ կներկայացնենք նոր տարբերակում կատարված ամենակարևոր փոփոխությունները։

Kubernetes 1.17: հիմնական նորույթների ակնարկ

Այս նյութի պատրաստման համար օգտագործված տեղեկատվությունը վերցված է պաշտոնական հայտարարությունից, Kubernetes բարելավումների վարկանիշային աղյուսակ,, CHANGELOG-1.17, և համապատասխան խնդիրներից, pull درخواستներից և Kubernetes Enhancement Proposals (KEP): Ուրեմն, ինչ նորություն կա?..

Տոպոլոգիայով հաշվի առնող երթուղավորում,

Kubernetes համայնքը երկար ժամանակ սպասում էր այս հնարավորությանը՝ Topology-aware service routing,. Եթե KEP-ը, դրա շուրջը հասույթ է ստացել 2018-ի հոկտեմբերից, իսկ պաշտոնական բարելավումը, երկու տարի առաջ, որոնք սովորաբար խնդիրներ են (ինչպես՝ Նաեւ՝ պանելների (կամ ավելի ճիշտ, դրանց բացակայության) հարցը արագ լուծվեց tmux-ով։ Ֆայլերի կառավարը ընտրեցի Ranger + fzf և ripgrep արագ որոնման համար։ Բրաուզերը ընտրեցի elinks (գործընթացում որ հղումներով անցնելու համար ընկալում են թվեր)։ Հազիվ լինում էին այլ խնդիրներ, բայց բոլորը արագ լուծվում էին որոշ օգտակար ծրագրերի ցանկով։) և դեռ ավելի հին մասնակի խնդիրներ…

Ընդհանուր գաղափարը ստեղծել հնարավորություն՝ իրականացնել "լոկալ" երթուղավորում Kubernetes-ում գտնվող ծառայությունների համար։ "Լոկալությունը" այստեղ նշանակում է "նույն տոպոլոգիական մակարդակ", (topology level),, որը կարող է լինել՝

նույն düzelti-ի համար,
նույն սերվերի ռաբաստան,
նույն շրջան,
նույն ամպային ծառայ provider,
…

Այսպիսի նշված հնարավորությունների օրինակներ՝

ծառայությունների համար ալորվելու հանդեպ խնայողություն, որպեսզի անունները, որոնք ունեն շատ տարածքային գծերի (multi-AZ) — տեսեք՝ նոր կերպ նկարագրություն, մեկ շրջան, բայց տարբեր AZ-ներ AWS-ում;
քիչ ուշացում կատարելու առումով/լավագույն անցկության ակտիվություն;
շարդացված ծառայություն, որն ունի տեղական տեղեկատվություն յուրաքանչյուր շարդի հանգույցի վերաբերյալ;
fluentd (կամ իր նմանները) տեղադրելով մեկ հանգույցի վրա այն ծրագրերին, որոնցի արձանագրությունները հավաքվում են;
…

Այսպիսի երթուղավորումը, "ապահովված" տոպոլոգիայով, նաև կոչվում է նմանակի network affinity — ըստներին՝ node affinity,, pod affinity/anti-affinity, կամ տեղեկացված ընդամենը մի քանի ժամ առաջ, Topology-Aware Volume Scheduling, (և Volume Provisioning). Անկաին կատարման մակարդակը ServiceTopology Kubernetes-ում — ալֆա-թողարկում։

Իմանալ ավելին՝ թե ինչպես է այս հնարավորությունը ստեղծված և ինչպես կարող եք արդեն օգտվել դրանից, կարդացեք՝ այս հոդվածի մեկ հեղինակներից։

IPv4/IPv6 կրկնակի ստեղների աջակցություն,

Բարձր առաջընթաց գրանցվել է մեկ այլ ցանցային հնարավորության մեջ՝ երկու IP ստեղների միաժամանակյա աջակցություն, որը առաջին անգամ ներկայացվել է, K8s 1.16-ում։Այդ տեղը նոր թողարկումը հետագայում բերեց հետևյալ փոփոխությունները՝

kube-proxy-ում իրականացվել է երկուսն էլ ռեժիմների (IPv4 և IPv6) միաժամանակյա աշխատանքային ընդունակություն;
մեջ Pod.Status.PodIPs, առաջացել է այս իջեցավ downward API (այս ընթացքում /etc/hosts այժմ պահանջում է, որպեսզի հյուրընկալողը ավելացնի IPv6 հասցե);
երկու ստեղների աջակցություն KIND, (Kubernetes IN Docker) և kubeadm;
նորացված e2e փորձարկումներ։

Kubernetes 1.17: հիմնական նորույթների ակնարկ
Նկարագրություն IPv4/IPv6 կրկնակի ստեղների օգտագործում KIND-ում,

CSI-ի առաջընթաց,

Հայտարարվել է կայուն տոպոլոգիայի աջակցություն CSI հիման վրա պահեստների համար, որը առաջին անգամ ներկայացվել է K8s 1.12,.

Պլագինի փոխանցման ներդրումները CSI Migration, — հասել են բետա-թողարկման մակարդակին։ Այս հնարավորությունը համապարփակ է, որպեսզի փոխադրվեն գոյություն ունեցող պահեստային պլագինները (in-tree) մոդեռացված ինտերֆեյսի (CSI, out-of-tree)։ на современный интерфейс (CSI, out-of-tree) Kubernetes-ով վերջնական օգտվողների համար աննկատ։ Կլաստերի ադմինիստրատորները պարզապես պետք է ակտիվացնեն CSI Migration-ը, այնուհետև առկա stateful ռեսուրսներն ու աշխատանքային բեռները շարունակում են «վճռել»… սակայն արդեն արդիական CSI վարորդների օգտագործմամբ փոխարեն հին, Kubernetes-ի միջուկում առկա վարորդների:

Այս պահին բետա տարբերակով միգրացիան պատրաստ է AWS EBS վարորդների համար (kubernetes.io/aws-ebs) և GCE PD (kubernetes.io/gce-pd)։ Մյուս պահեստների կանխատեսումները հետևյալն են․

Kubernetes 1.17: հիմնական նորույթների ակնարկ

Ինչպես « המסורתային » պահեստների աջակցությունը K8s-ի միջոցով հասավ CSI-ի մասին նկարագրված է մեր հոդվածում, այս հոդվածիԻսկ CSI միգրացիայի բետա կարգավիճակը ներկայացված է անսահման հրապարակում նախագծի բլոգում։

Բացի այդ, Kubernetes 1.17 թողարկման մեջ (նվազագույնով ակտիվացման վիճակում) հասավ ևս մեկ կարևոր գործառույթ, որն իր չափազանց կարևոր նշանակություն ունի (ալֆա-իրագործումը) K8s 1.12-ում, — սնապշոթների ստեղծում և դրանցից վերականգնելու գործընթացը։Kubernetes Volume Snapshot-ի բետա-թողարկման ճանապարհին իրականացված փոփոխությունների թվում են՝

CSI external-snapshotter sidecar-ի շերտավորումը երկու վերահսկիչների վրա,
փոխանակված գաղտնաբառը (deletion secret) որպես սեղմակոնտենտի անոթի լուրը,
նոր վերջնականացուցիչ (finalizer) առաջին հղումով API-օբյեկտի անվտանգության կանխարգելման համար՝ կապված մնացյալ կապերի հետ։

1.17 թողարկման պահին այս ֆունկցիան աջակցվում է երեք CSI վարորդների կողմից՝ GCE Persistent Disk CSI Driver, Portworx CSI Driver և NetApp Trident CSI Driver։ Շատ ավելին այս ֆունկցիայի իրականացումը և օգտագործման մասին կարող եք կարդալ այս հրապարակման բլոգում։

Cloud Provider Labels

Լեյբլները, որոնք ինքնաբերաբար հատկացվում են ստեղծվող узлы և volumes՝ կախված օգտագործվող ամպային ծառայությունից,ահա, որ Kubernetes-ում որպես բետայի տարբերակ արդեն շատ վաղուց հասանելի են՝ սկսած K8s 1.2 թողարկումից (ապրիլ 2016-ից!)։ Այդքան երկար ժամանակ շատ լայն տարածում ունենալով՝ մշակողները որոշեցին, որ ժամանակն է հայտարարելու ֆունկցիան կայուն (GA)։

Հետևաբար, բոլորը վերանվանվել են համապատասխան կերպով (տոպոլոգիաների վրա):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… բայց դեռ հասանելի են նաև իրենց հին անուններով (հետադարձ համեմատականությունից իջեցնելու համար): Այնուամենայնիվ, բոլոր ադմինիստրատորներին խորհուրդ է տրվում անցնել արդիական լեյբլներին: Կուշտոմի համապատասխան փաստաթղթավորումը K8s-ն թարմացվել է։

kubeadm-ի կառուցվածքային ելք

Ալֆա-թողարկման ձևաչափում առաջին անգամ ներկայացվել է kubeadm-ի գործիքի կառուցվածքային ելքը։Դ podpor Անվտանգ ձևաչափերը: JSON, YAML, Go-բաղադրիչ։

Այս ֆունկցիայի կյանքի մեջ խթանելու մոտիվացումը (հետաքրքրություն) հետևյալն է՝ KEP-ը,Նախ, քանի որ Kubernetes-ը կարող է ձեռք բերվել ձեռքով, գործողության անկեղծ ստանդարտ է դարձել kubeadm-ի կիրառումը։ Խորհուրդ է տրվում, որպեսզի նման նախագծեր, ինչպիսիք են Terraform-ը, որակեն kubeadm-ը Kubernetes-ի տարեկան»,-կենտրոնացված դրոշումով: Արտահերթ հանելու ծրագրերը Cluster API-ում ներառում են կոմպոզիտի փաթեթ` Kubernetes ստանդարտը kubeadm-ի և cloud-init-ի հետ համատեղելու համար:

Хоть Kubernetes и может быть развёрнут вручную, стандартом де-факто (если не де-юре) для этой операции является использование kubeadm. Популярные инструменты управления системами вроде Terraform опираются на kubeadm для деплоя Kubernetes. Запланированные улучшения в Cluster API включают в себя компонуемый пакет для bootstrapping’а Kubernetes с kubeadm и cloud-init.
Առանց կառուցվածքային ելքի նույնիսկ առաջին հայացքից անվնաս փոփոխությունները կարող են խորտակել Terraform-ը, Cluster API-ն և մյուս ծրագրերը, որոնք օգտագործում են kubeadm-ի աշխատանքի արդյունքները.

Ամենամոտ ծրագրերում նախատեսված է աջակցություն (կառուցվածքային ելքի տարբերակով) kubeadm-ի հետևյալ հրամանների համար:

alpha certs
config images list
Նախնական պատրաստություն, այստեղ կարող է լինել ամեն ինչ՝ կախվածությունների ներբեռնումը, գաղտնիքների բացահայտումը և այլ բաներ։
token create
token list
upgrade plan
version

JSON պատասխանների պատկերումը հրամանի համար kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "'kubeadm init'-ով ստեղծված միջին bootstrap token:",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Այլ նորարարությունների կայունացում

Առհասարակ, Kubernetes 1.17-ի թողարկումը տեղի ունեցավ «Աջակցություն» լոզունգով: Դրան նպատակը դարձավ այն փաստը, որ շատ գործառույթներ (նրանց ընդհանուր թիվը — 14) ստացել են GA կարգավիճակ: Դրանցից են՝

Ձևակիր узлов по determinadas условиям (TaintNodesByCondition), որը հայտնվել է K8s 1.8-ում;
Watch Bookmarks — նոր տեսակի իրադարձություններ, որոնք նշում են, որ բոլոր օբյեկտները մինչև որոշակի տարբերակ (resourceVersion) արդեն մշակվել են watch’ով:
Զանգվածային արժեքները (defaulting) մուտք գործելու համար Custom Resources;
container-ների միջև կիսված pod-ի process namespaces;
ScheduleDaemonSetPods — pod’երի պլանավորում DaemonSet-ում kube-scheduler-ով (փոխարենը DaemonSet վերահսկողից);
դինամիկ սահմանափակումներ ծավալների քանակի սահմանափակման համար узловի տեսակով;
ցանկացած փոխվող շրջապատի աջակցության արվել ենք անունների դակտորների համար, որպես subPath;
քայլ անվտանգության Kubelet heartbeats հատուկ Lease API-ում:
finalizer-ի պաշտպանությունը (Finalizer Protection) բեռնափակիչների համար (համապատասխան կամքի վստահում՝ բեռնափակիչ ռեսուրսների մաքրման ժամանակ);
kube-apiserver-ի մանրամասների խույժի արդյունավետության բարելավման պարագայում՝ դիտելով դուրս թողված անցումներ, որոնք դիտում են նույն օբյեկտների հավաքածուները, խուսափում է յուրաքանչյուր դիտողից մեկից ետ վերագային:

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

Kubernetes 1.17-ի նորարարությունների միակ ամբողջական ցանկը, ավանդաբար, չի սահմանափակվում նշվածներով: Սա մի քանի այլներից (և ավելի ամբողջական ցանկի համար — տես Փոփոխությունների օրագիր):

վերջին թողարկման մեջ ներկայացված ֆունկցիայի՝ բետա տարբերակին «հասնելու» համաձայն RunAsUserName Windows-ի համար;
համընկնող փոփոխություն բնակից EndpointSlice API (նույնիսկ K8s 1.16-ին), սակայն մինչ այժմ այս լուծումը Endpoint API-ի կատարելագործման համար դեռ ակտիվացված չէ ըստ միջացվի:
կլաստերի կենդանի pod-եր հիմա կարող են ստեղծվել ոչ միայն անունների տարածքներում kubectl -n kube-system edit cm kubelet-config-1.16 (նշանակություններին նայեք Limit Priority Class consumption);
kubelet-ի համար նոր կարգավիճակը — --reserved-cpus — թույլ է տալիս նշանակել CPU-ների ցանկ, որոնք անմիջապես լինելու են համակարգում;
լիովին kubectl logs ներդրված նոր նշան --prefix, որը ավելացնում է pod-ի և աղբյուրի տարրաի անվան հարցը դեպի յուրաքանչյուր ստացված տվյալ:
մեջ label.Selector ավելացրել են RequiresExactMatch;
բոլոր konteyners-ը kube-dns-ում այժմ մեկնարկում են ափսոսանքի ավելի քիչ իրավունքներով;
hyperkube անջատվել է առանձին GitHub պահոցում և այլևս չի ներառվի Kubernetes-ի թողարկումներում;
քան պատահական խթանվել է արդյունավետությունը kube-proxy-ի համար ոչ-UDP պորտերի;

Պահպանողական փոփոխություններ:

CoreDNS-ի տարբերակը, որը ներառված է kubeadm-ում՝ 1.6.5;
crictl-ի տարբերակը հասցենված է v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
վերջին ստուգված Docker-ի տարբերակը բարձրացվել է մինչև 19.03;
Kubernetes 1.17-ի համար անհրաժեշտ նվազագույն Go տարբերակը 1.13.4 է:

P.S.

Նաեւ կարդացեք մեր բլոգում:

Ընտանիք: habr.com