🥇Kubernetes 1.16: негизги инновацияларга сереп

Бүгүн, шаршемби, өтөт Kubernetes кийинки чыгарылышы - 1.16. Блогубуз үчүн калыптанган салт боюнча, жаңы версиядагы эң орчундуу өзгөртүүлөр тууралуу онунчу юбилейлик учур.

Бул материалды даярдоо үчүн колдонулган маалымат алынган Kubernetes жакшыртууларды көзөмөлдөө таблицалары, CHANGELOG-1.16 жана ага байланыштуу маселелер, тартуу сурамдары жана Kubernetes жакшыртуу сунуштары (KEP). Ошентип, кетели!..

Түйүндөр

Чынында эле көп сандагы көрүнүктүү инновациялар (альфа версия статусунда) K8s кластердик түйүндөрүнүн (Kubelet) капталында берилген.

Биринчиден, деп аталган «эфемердик контейнерлер» (Эфемердик контейнерлер), подколордогу мүчүлүштүктөрдү оңдоо процесстерин жөнөкөйлөтүү үчүн иштелип чыккан. Жаңы механизм колдонуудагы поддондордун аталыш мейкиндигинде башталып, кыска убакытка жашай турган атайын контейнерлерди ишке киргизүүгө мүмкүндүк берет. Алардын максаты ар кандай көйгөйлөрдү чечүү жана мүчүлүштүктөрдү оңдоо үчүн башка капчыктар жана контейнерлер менен өз ара аракеттенүү. Бул өзгөчөлүк үчүн жаңы буйрук ишке ашырылган kubectl debug, маңызы боюнча окшош kubectl exec: процессти контейнерде иштетүүнүн ордуна гана ( exec) ал бир контейнерди ишке киргизет. Мисалы, бул буйрук жаңы контейнерди поддонго туташтырат:

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

Эфемердик контейнерлер (жана аларды колдонуунун мисалдары) жөнүндө толук маалыматты бул жерден тапса болот тиешелүү KEP. Учурдагы ишке ашыруу (K8s 1.16да) альфа версиясы жана аны бета версиясына өткөрүү критерийлеринин арасында "[Kubernetes] кеминде 2 чыгарылыш үчүн Ephemeral Containers API сынап көрүү" болуп саналат.

NB: Өзүнүн маңызы жана атүгүл аты боюнча, өзгөчөлүк мурунтан эле бар плагинге окшош kubectl-дебагбул жөнүндө биз буга чейин жазылган. Эфемердик контейнерлердин пайда болушу менен өзүнчө тышкы плагинди иштеп чыгуу токтойт деп күтүлүүдө.

Дагы бир инновация - PodOverhead - камсыз кылуу үчүн иштелип чыккан порошок үчүн кошумча чыгымдарды эсептөө механизми, бул колдонулган иштөө убактысына жараша абдан өзгөрүшү мүмкүн. Мисал катары, авторлор бул KEP натыйжада конок ядросун, ката агентин, init тутумун ж.б. иштетүүнү талап кылган Ката контейнерлери пайда болот. Кошумча чыгымдар ушунчалык чоң болуп калганда, аны этибарга албай коюуга болбойт, демек, андан аркы квоталар, пландаштыруу ж.б. үчүн аны эске алуунун жолу болушу керек. Аны ишке ашыруу үчүн PodSpec талаа кошулду Overhead *ResourceList (берилген маалыматтар менен салыштырылат RuntimeClass, эгер бири колдонулса).

Дагы бир көрүнүктүү инновация болуп саналат түйүн топологиясынын менеджери (Түйүн топологиясынын менеджери), Kubernetes ар кандай компоненттери үчүн аппараттык ресурстарды бөлүштүрүү так жөндөө ыкмасын унификациялоо үчүн иштелип чыккан. Бул демилге ар кандай заманбап системаларга (телекоммуникация, машина үйрөнүү, финансылык кызматтар ж.б. чөйрөсүнөн) жогорку өндүрүмдүүлүктөгү параллелдүү эсептөөлөргө жана операцияларды аткаруудагы кечигүүлөрдү минималдаштырууга болгон муктаждыктын өсүшү менен шартталган, алар үчүн прогрессивдүү CPU жана аппараттык тездетүү мүмкүнчүлүктөрү. Kubernetes'теги мындай оптималдаштыруулар ар башка компоненттердин (CPU менеджери, Түзмөк менеджери, CNI) аркасында жетишилген, эми аларга ыкманы бириктирген жана жаңы окшош топологиянын байланышын жөнөкөйлөткөн бирдиктүү ички интерфейс кошулат. кабардар - Кубелет тарабында компоненттер. Толук маалымат - in тиешелүү KEP.

Топология менеджеринин компонент диаграммасы

Кийинки өзгөчөлүк - алар иштеп жатканда контейнерлерди текшерүү (баштоо иликтөө). Белгилүү болгондой, ишке киргизүүгө көп убакыт талап кылынган контейнерлер үчүн актуалдуу статуска ээ болуу кыйын: алар иш жүзүндө иштей электе эле «өлтүрүлөт», же алар узак убакытка туюкка кептелет. Жаңы текшерүү (чалуу функция дарбазасы аркылуу иштетилген StartupProbeEnabled) жокко чыгарат, же тагыраак айтканда, башка текшерүүлөрдүн эффектисин подряд иштеп бүткөнгө чейин кийинкиге калтырат. Ушул себептен улам, өзгөчөлүк алгач аталган pod-startup liveness-probe holdoff. Баштоо үчүн көп убакыт талап кылынган поддондор үчүн, сиз штатты салыштырмалуу кыска убакыт аралыгында сурамжылоого болот.

Мындан тышкары, RuntimeClass үчүн жакшыртуу "гетерогендүү кластерлерди" колдоону кошуп, бета статусунда дароо жеткиликтүү болот. C RuntimeClass Scheduling Эми ар бир түйүн үчүн ар бир RuntimeClass үчүн колдоого ээ болушу таптакыр зарыл эмес: подколор үчүн кластердин топологиясы жөнүндө ойлонбостон RuntimeClass тандай аласыз. Буга чейин, буга жетүү үчүн - поддондор өздөрүнө керектүү нерселердин бардыгын колдоо менен түйүндөрдө бүтүшү үчүн - NodeSelector жана сабырдуулукка тиешелүү эрежелерди дайындоо керек болчу. IN САКТА Бул колдонуунун мисалдары жана, албетте, ишке ашыруунун деталдары жөнүндө айтылат.

тармак

Kubernetes 1.16да биринчи жолу (альфа версиясында) пайда болгон эки маанилүү тармактык өзгөчөлүктөр:

колдоо кош тармак стек - IPv4/IPv6 - жана ага ылайыктуу "түшүнүү" поддондордун, түйүндөрдүн, кызматтардын деңгээлинде. Ал IPv4-то IPv4 жана IPv6-дан IPv6га чейин подтексттердин ортосундагы өз ара аракеттенүүнү камтыйт, поддондордон тышкы кызматтарга чейин, маалымдама ишке ашыруулар (Bridge CNI, PTP CNI жана Host-Local IPAM плагиндеринин ичинде), ошондой эле иштеп жаткан Kubernetes кластерлери менен тескери шайкеш келет. IPv4 же IPv6 гана. Ишке ашыруу чоо-жайы бөлүмдө САКТА.
Кошумчалардын тизмесинде эки түрдөгү (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#
```
Endpoint үчүн жаңы API - EndpointSlice API. Ал башкаруу тегиздигиндеги ар кандай компоненттерге (аписервер, ж.б., акыркы чекиттер-контроллер, kube-прокси) таасирин тийгизген учурдагы Endpoint API'нин аткаруу/кеңейтүү маселелерин чечет. Жаңы API Discovery API тобуна кошулат жана миңдеген түйүндөрдөн турган кластерде ар бир кызматта он миңдеген акыркы чекиттерди тейлей алат. Бул үчүн, ар бир Кызмат N объектиге түшүрүлгөн EndpointSlice, алардын ар бири демейки боюнча 100дөн ашпаган акыркы чекиттерге ээ (маани конфигурацияланат). EndpointSlice API ошондой эле анын келечектеги өнүгүшү үчүн мүмкүнчүлүктөрдү камсыз кылат: ар бир поддон үчүн бир нече IP даректерди колдоо, акыркы чекиттер үчүн жаңы штаттар (гана эмес Ready и NotReady), акыркы чекиттер үчүн динамикалык субситтинг.

Акыркы чыгарылышта берилген бета версияга жетти жыйынтыктоочудеген service.kubernetes.io/load-balancer-cleanup жана түрү менен ар бир кызматка тиркелет LoadBalancer. Мындай кызмат жок кылынган учурда, ал бардык тиешелүү баланстоочу ресурстарды "тазалоо" аяктаганга чейин ресурстун иш жүзүндө жок кылынышына жол бербейт.

API Machinery

Чыныгы "стабилдештирүү этапы" Kubernetes API серверинин чөйрөсүндө жана аны менен өз ара аракеттенүүдө. Бул негизинен аркасында болду өзгөчө киргизүүнү талап кылбагандарды стабилдүү статуска которуу CustomResource Definitions (CRD), Kubernetes 1.7 алыскы күндөрүнөн бери бета статусуна ээ болгон (жана бул 2017-жылдын июнь айында!). Ошол эле турукташтыруу тиешелүү өзгөчөлүктөргө келди:

"субресурстар" менен /status и /scale CustomResources үчүн;
кайра CRD үчүн версиялар, тышкы вебхукка негизделген;
жакында эле тартууланды (K8s 1.15те) демейки маанилер (демейки) жана автоматтык талааны алып салуу (бутоо) CustomResources үчүн;
мүмкүнчүлүк OpenAPI v3 схемасын колдонуу менен сервер тарабында CRD ресурстарын текшерүү үчүн колдонулган OpenAPI документтерин түзүү жана жарыялоо.

Kubernetes администраторлоруна көптөн бери тааныш болгон дагы бир механизм: кирүү вебхук - ошондой эле узак убакыт бою бета статусунда калды (K8s 1.9 бери) жана азыр туруктуу деп жарыяланды.

Дагы эки функция бетага чыкты: сервер тарабы колдонулат и кыстармаларды көрүү.

Ал эми альфа версиясындагы бирден-бир олуттуу жаңылык болду ката от SelfLink — көрсөтүлгөн объектти билдирген жана анын бир бөлүгү болгон атайын URI ObjectMeta и ListMeta (б.а. Кубернетестеги каалаган объектинин бөлүгү). Эмне үчүн алар андан баш тартып жатышат? Жөнөкөй жол менен мотивация үндөр бул талаанын дагы деле бар болушу үчүн реалдуу (басып) себептердин жоктугу катары. Көбүрөөк расмий себептер - бул ишти оптималдаштыруу (керексиз талааны алып салуу менен) жана мындай талааны өзгөчө жол менен иштетүүгө аргасыз болгон генерик-аписервердин ишин жөнөкөйлөтүү (бул объекттин алдына коюлган жалгыз талаа. серияланган). Чыныгы эскирүү (бета ичинде) SelfLink Kubernetes версиясы 1.20 жана акыркы - 1.21 менен болот.

маалыматтарды сактоо

Сактоо чөйрөсүндөгү негизги иш, мурунку чыгарылыштардагыдай эле, аймакта байкалат CSI колдоосу. Бул жерде негизги өзгөрүүлөр болду:

биринчи жолу (альфа версиясында) пайда Windows жумушчу түйүндөрү үчүн CSI плагинди колдоо: сактагыч менен иштөөнүн учурдагы ыкмасы Kubernetes өзөгүндөгү дарак ичиндеги плагиндерди жана Powershell негизиндеги Microsoftтун FlexVolume плагиндерин алмаштырат;

Windows үчүн Kubernetesте CSI плагиндерин ишке ашыруу схемасы
мүмкүнчүлүк CSI көлөмүн өзгөртүү, K8s 1.12 кайра киргизилген, бета нускасына чейин өстү;
Окшош "алмашуу" (альфадан бетага чейин) жергиликтүү эфемердик томдорду түзүү үчүн CSIди колдонуу мүмкүнчүлүгү менен жетишилди (CSI Inline көлөмүн колдоо).

Kubernetesтин мурунку версиясында киргизилген көлөмдү клондоо функциясы (бар болгон PVC катары колдонуу DataSource жаңы PVC түзүү) азыр бета статусун алды.

Пландаштыруучу

Графикке эки көрүнүктүү өзгөртүү (экөө тең альфада):

EvenPodsSpreading - мүмкүнчүлүк жүктөрдү "адилет бөлүштүрүү" үчүн логикалык колдонмо бирдиктеринин ордуна поддондорду колдонуңуз (Орнотуу жана ReplicaSet сыяктуу) жана бул бөлүштүрүүнү тууралоо (катуу талап же жумшак шарт катары, б.а. артыкчылык). Функция учурда варианттар менен чектелген пландаштырылган поддондордун учурдагы бөлүштүрүү мүмкүнчүлүктөрүн кеңейтет PodAffinity и PodAntiAffinity, администраторлорго бул маселеде жакшыраак көзөмөлдү берүү, бул жакшыраак жогорку жеткиликтүүлүктү жана оптималдаштырылган ресурстарды керектөө дегенди билдирет. Толук маалымат - in САКТА.
пайдалануунун BestFit саясаты в RequestedToCapacityRatio Priority Function мүмкүндүк берет под пландоо учурунда колдонулат идиш таңгактоо ("контейнерлерге таңгактоо") негизги ресурстар үчүн (процессор, эс тутум) жана кеңейтилген ресурстар үчүн (GPU сыяктуу). Көбүрөөк маалымат алуу үчүн, караңыз САКТА.

Пландаштыруу подколор: эң ылайыктуу саясатты колдонуудан мурун (түздөн-түз демейки пландоочу аркылуу) жана аны колдонуу менен (пландаштыруучу кеңейтүүчү аркылуу)

Мындан тышкары, берилген негизги Kubernetes өнүктүрүү дарагынын сыртында өз пландоочу плагиндериңизди түзүү мүмкүнчүлүгү (дарактын сыртында).

Башка өзгөрүүлөр

Ошондой эле Kubernetes 1.16 релизинде белгилей аласыз үчүн демилге алып келүү толук тартипте жеткиликтүү метрикалар, тагыраак айтканда, ылайык расмий жоболор K8s приборлоруна. Алар негизинен тиешелүү таянышат Прометейдин документтери. Ар кандай себептерден улам дал келбестиктер пайда болгон (мисалы, кээ бир метрика учурдагы нускамалар пайда болгонго чейин эле түзүлгөн) жана иштеп чыгуучулар "Прометей экосистемасынын калган бөлүгүнө ылайык" бардыгын бирдиктүү стандартка алып келүүгө убакыт келди деп чечишти. Бул демилгенин учурдагы аткарылышы альфа статусунда, ал Kubernetesтин кийинки версияларында бара-бара бета (1.17) жана туруктуу (1.18) версияларына көтөрүлөт.

Мындан тышкары, төмөнкү өзгөрүүлөрдү белгилей кетүү керек:

Windows өнүктүрүүнү колдоо с көрүнүшү Бул ОС үчүн Kubeadm утилиталары (альфа версиясы), мүмкүнчүлүк RunAsUserName Windows контейнерлери үчүн (альфа версиясы), жакшыртуу Group Managed Service Account (gMSA) бета версиясына чейин колдойт, колдоо vSphere көлөмдөрү үчүн орнотуу/тиркеме.
Кайра иштетилген API жоопторундагы маалыматтарды кысуу механизми. Буга чейин бул максаттар үчүн HTTP чыпкасы колдонулган, ал демейки боюнча анын иштетилишине тоскоол болгон бир катар чектөөлөрдү киргизген. "Айкын суроо-талапты кысуу" азыр иштейт: кардарлар жөнөтүүдө Accept-Encoding: gzip аталышта, эгерде анын көлөмү 128 КБ ашса, алар GZIP кысылган жоопту алышат. Go кардарлары автоматтык түрдө компрессияны колдойт (керектүү аталышты жөнөтөт), ошондуктан алар трафиктин азайгандыгын дароо байкашат. (Башка тилдер үчүн бир аз өзгөртүүлөр талап кылынышы мүмкүн.)
Мүмкүн болду тышкы көрсөткүчтөрдүн негизинде HPAны нөлгө чейин масштабдоо. Эгер сиз объекттерге/тышкы көрсөткүчтөрдүн негизинде масштабдасаңыз, анда жумуш жүктөрү бош турганда ресурстарды үнөмдөө үчүн автоматтык түрдө 0 репликага чейин масштабдасаңыз болот. Бул өзгөчөлүк жумушчулар GPU ресурстарын сураган учурларда жана бош иштеген ар кандай типтеги жумушчулардын саны жеткиликтүү GPUлардын санынан ашкан учурларда өзгөчө пайдалуу болушу керек.
Жаңы кардар - k8s.io/client-go/metadata.Client — объекттерге «жалпыланган» кирүү үчүн. Ал метадайындарды оңой алуу үчүн иштелип чыккан (б.а. бөлүм metadata) кластердик ресурстардан жана алар менен таштандыларды чогултуу жана квота операцияларын жүргүзүү.
Kubernetes куруу азыр сен болот эски (“курулган” дарактагы) булут провайдерлери жок (альфа версиясы).
кубеадм утилитасына кошулду эксперименталдык (альфа версиясы) операция учурунда ыңгайлаштырылган тактарды колдонуу мүмкүнчүлүгү init, join и upgrade. Желекти кантип колдонуу керектиги жөнүндө көбүрөөк билүү --experimental-kustomize, караңыз САКТА.
Аписервер үчүн жаңы акыркы чекит - readyz, - анын даярдыгы жөнүндө маалыматты экспорттоого мүмкүндүк берет. API серверинде азыр желек бар --maximum-startup-sequence-duration, анын кайра баштоосун жөнгө салууга мүмкүндүк берет.
эки Azure үчүн өзгөчөлүктөр туруктуу деп жарыяланды: колдоо жеткиликтүү зоналар (Жеткиликтүү зоналар) жана кайчылаш ресурстар тобу (RG). Мындан тышкары, Azure кошумчалады:
- аутентификацияны колдоо AAD жана ADFS;
- жалпылаган service.beta.kubernetes.io/azure-pip-name жүк балансынын коомдук ИМди көрсөтүү;
- мүмкүнчүлүк орнотуулары LoadBalancerName и LoadBalancerResourceGroup.
AWS азыр бар колдоо Windows жана EBS үчүн оптималдаштырылган EC2 API чалуулары DescribeInstances.
Кубеадм азыр кез каранды эмес көчүп кетет CoreDNS версиясын жаңыртууда CoreDNS конфигурациясы.
Binaries ж.б. тиешелүү Docker сүрөтүндө кылдым дүйнөлүк аткарылуучу, бул сүрөттү тамыр укуктарынын кереги жок иштетүүгө мүмкүндүк берет. Ошондой эле, ж.б. миграция сүрөтү калды etcd2 версиясын колдоо.
В Cluster Autoscaler 1.16.0 негизги сүрөт катары distroless колдонууга өттү, жакшыртылган аткаруу, жаңы булут провайдерлери (DigitalOcean, Magnum, Пакет) кошулду.
Колдонулган/көз каранды программалык камсыздоонун жаңыртуулары: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Kubernetes 1.16: Жаңылыктын негизги учурлары