🥇Kubernetes 1.16: преглед на основните нововъведения

Днес, сряда, ще се състои е поредното издание на Kubernetes — 1.16. По традиция за нашия блог, вече за десети път, представяме най-значимите промени в новата версия.

Информацията, използвана за подготовката на този материал, е взета от таблица за проследяване на подобренията в Kubernetes, CHANGELOG-1.16 и съответстващите проблеми, pull requests, а също и Kubernetes Enhancement Proposals (KEP). И така, да започваме!..

Възли

Истински голям брой забележителни нововъведения (в статус на алфа версия) са представени на страна на възлите на K8s клъстери (Kubelet).

На първо място, представени са т. нар. «ефемерни контейнери» (Ephemeral Containers), предназначени да опростят процесите на отстраняване на грешки в pod'овете. Новият механизъм позволява стартиране на специални контейнери, които се стартират в пространството на съществуващите pod'ове и живеят кратко време. Целта им е взаимодействие с други pod'ове и контейнери с цел решаване на проблеми и отстраняване на грешки. За тази възможност е реализирана нова команда kubectl debug, сходна по същността си с kubectl exec: само че вместо да стартира процес в контейнер (както в случая exec) тя стартира контейнер в pod'а. Например, такава команда ще свърже нов контейнер с pod'а:

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

Подробности за ефемерните контейнери (и примери за тяхната употреба) можете да намерите в съответния KEP. Текущата реализация (в K8s 1.16) е алфа версия, а сред критериите за нейния преход в бета версия е 'тестиране на Ephemeral Containers API в продължение на не по-малко от 2 издания [Kubernetes]'.

NB: По своята същност и дори име, функцията напомня на вече съществуващ плъгин. kubectl-debug, за което вече пишехмеПредполага се, че с появата на ефемерните контейнери, развитието на отделен външен плъгин ще спре.

Друго нововъведение — PodOverhead — е предназначено да предостави механизъм за изчисляване на накладните разходи на pod'овете, които могат да се различават значително в зависимост от използваната изпълнителна среда (runtime). Като пример авторите на този KEP представят Kata Containers, които изискват стартиране на гост система, агента kata, init система и т.н. Когато накладните разходи станат толкова значителни, те не могат да бъдат игнорирани, а следователно — необходим е начин да ги вземем предвид за последващо квотиране, планиране и т.н. За тяхната реализация в PodSpec е добавено поле Overhead *ResourceList (съотнесено с данните в RuntimeClass, ако такова се използва).

Още едно забележително нововъведение — мениджър на топологията на възлите (Node Topology Manager), предназначена да унифицира подхода за финна настройка на разпределението на хардуерни ресурси за различни компоненти в Kubernetes. Тази инициатива е предизвикана от нарастващата потребност на различни съвременни системи (от сферата на телекомуникациите, машинното обучение, финансовите услуги и т.н.) от високоефективни паралелни изчисления и минимизиране на закъсненията при изпълнението на операции, за което те използват усъвършенстваните възможности на CPU и хардуерното ускорение. Такива оптимизации в Kubernetes до сега се постигали чрез разпръснати компоненти (CPU мениджър, Device мениджър, CNI), а сега ще им бъде добавен единен вътрешен интерфейс, който да унифицира подхода и да улесни свързването на нови подобни — така наречените topology-aware — компоненти на страната на Kubelet. Подробностите — в съответния KEP.

Схема на компонентите на Topology Manager

Следващата функция — проверка на контейнерите по време на старта им (startup probe). Както е известно, за контейнерите, които се стартират дълго, е трудно да се получи актуален статус: те или „се убиват“ още преди реалното начало на функционирането, или за дълго време попадат в deadlock. Новата проверка (включваща се чрез feature gate с името StartupProbeEnabled) отменя — по-точно, отлага — действието на всички други проверки до момента, в който pod е завършил старта си. По тази причина функцията първоначално е наречена pod-startup liveness-probe holdoff. За pod-ове, които се стартират дълго, може да се провеждат проверки на състоянието в относително кратки времеви интервали.

Освен това, направо в статус бета версия е представено подобрение за RuntimeClass, добавящо поддръжка за „хетерогенни клъстери“. C RuntimeClass Scheduling сега не е задължително всеки възел да има поддръжка на всеки RuntimeClass: за pod-ове може да се избира RuntimeClass, без да се мисли за топологията на клъстера. По-рано, за да се постигне това — за pod-овете да се намират на възли с поддръжка на всичко необходимо — се е налагало да се назначават соответствующи правила на NodeSelector и tolerations. В KEP се разказва за примери на приложение и, разбира се, подробности за реализацията.

Мрежа

Две значими мрежови функции, които се появиха за пръв път (в алфа версия) в Kubernetes 1.16 — това са:

Поддръжка двойния мрежов стек — IPv4/IPv6 — и съответствието на неговото «разбиране» на ниво pod-ове, възли, услуги. Той включва взаимодействие между pod-овете по IPv4-to-IPv4 и IPv6-to-IPv6, от pod-ове към външни услуги, референтни реализации (в рамките на плъгините Bridge CNI, PTP CNI и Host-Local IPAM), както и обратна съвместимост с Kubernetes клъстери, работещи само по IPv4 или IPv6. Подробности за реализацията — в KEP.
Пример за извеждане на IP адреси от два вида (IPv4 и IPv6) в списъка на pod-овете:
```
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 за Endpoint — EndpointSlice API. Той решава проблемите на съществуващия Endpoint API с производителност/мащабируемост, които засягат различни компоненти в control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Новият API ще бъде добавен в API групата Discovery и ще може да обслужва десетки хиляди бекенд ендпоинта на всяка услуга в клъстера, състоящ се от хиляди възли. За целта всяка услуга се отразява в N обекта EndpointSlice, всеки от които по подразбиране има не повече от 100 ендпоинта (стойността е настраиваема). В EndpointSlice API са предвидени и възможности за бъдещо развитие: поддръжка на множество IP адреси за всеки pod, нови състояния за ендпоинтите (не само Готово и NotReady), динамично разпределяне за ендпоинтите.

До бета версия премина представеният в миналия релиз finalizer, наречен service.kubernetes.io/load-balancer-cleanup и прикрепван към всяка услуга с тип LoadBalancer. В момента на изтриването на такава услуга той предотвратява фактическото изтриване на ресурса, докато не приключи «почистването» на всички съответстващи ресурси на балансировщика.

API Machinery

Настоящата «етапна стабилизация» е зафиксирана в областта на API сървъра на Kubernetes и взаимодействието с него. В значителна степен това се случи благодарение на превода в статус stable на не нуждаещи се от специално представяне CustomResourceDefinitions (CRD), които имаха статус бета версия от времето на далечния Kubernetes 1.7 (а това е юни 2017 година!). Подобна стабилизация дойде и за свързаните с тях характеристики:

«подресурси» (subresources) с /status и /scale за CustomResources;
преобразуване версии за CRD, основани на външен webhook;
представените наскоро (в K8s 1.15) по подразбиране стойности (defaulting) и автоматично изтриване на полета (pruning) за CustomResources;
възможността прилагане на схемата OpenAPI v3 за създаване и публикуване на OpenAPI документация, използвана за валидация на CRD ресурсите на сървъра.

Още един механизъм, който отдавна е познат на администраторите на Kubernetes: admission webhook — също дълго време беше в статус бета (с K8s 1.9) и сега е обявен за стабилен.

Две други функции достигнаха бета версия: server-side apply и watch bookmarks.

А единственото значимо нововъведение в алфа версията стана отказ от SelfLink — специален URI, представляващ посочения обект и част от ObjectMeta и ListMeta (т.е. част от всеки обект в Kubernetes). Защо се отказват от него? Мотивацията 'по-простичко' звучи като липса на истински (непреодолими) причини за продължаването на съществуването на това поле. По-формалните причини — оптимизиране на производителността (като се премахне ненужното поле) и опростяване на работата на generic-apiserver, който е принуден да обработва такова поле по специален начин (това е единственото поле, което се задава непосредствено преди сериализацията на обекта). Истинското 'устаряване' (в рамките на бета версията) SelfLink ще се случи с версия Kubernetes 1.20, а окончателното — 1.21.

Съхранение на данни

Основната работа в областта на съхранението, както и в предишните версии, се наблюдава в областта на поддръжката на CSI. Главните промени тук бяха:

за първи път (в алфа версията) е добавена поддръжка на CSI плъгини за работни възли с Windows: актуалният начин за работа с хранилища ще замени in-tree плъгини в ядрото на Kubernetes и FlexVolume плъгини от Microsoft, базирани на Powershell;

Схемата за реализация на CSI плъгини в Kubernetes за Windows
възможността промени в размера на CSI томовете, представена още в K8s 1.12, достигна бета версия;
аналогично 'повишаване' (от алфа до бета версия) достигна възможността за използване на CSI за създаване на локални ефимерни томове (CSI Inline Volume Support).

Функцията за клониране на томове, появила се в предната версия на Kubernetes (използване на съществуващи PVC като DataSource за създаване на нови PVC) също сега получи статус бета версия. Две забележителни промени в планирането (и двете в алфа версия):

Планировчик

EvenPodsSpreading

— възможност да се използват pod'ове вместо логически единици приложение за 'честно разпределение' на натоварванията (като Deployment и ReplicaSet) и регулиране на това разпределение (като строго изискване или като мека условие, т.е. приоритет). Функцията ще разшири съществуващите възможности за разпределение на планираните pod'ове, които в момента са ограничени от опциите PodAffinity PodAntiAffinity и PodAntiAffinity, предоставявайки на администраторите по-фините контрол в този въпрос, и следователно — по-добра висока наличност и оптимизирана консумация на ресурси. Повече подробности — в KEP.
Използването Политика BestFit в Приоритетна функция RequestedToCapacityRatio по време на планирането на pod-ове, което ще позволи да прилага опаковане в контейнери («bin packing») както за основните ресурси (процесор, памет), така и за разширените (като GPU). Повече информация можете да намерите в KEP.

Планиране на pod-ове: преди използването на best fit policy (директно през default scheduler) и с нейното използване (чрез scheduler extender)

Освен това, беше представена възможността за създаване на собствени плъгини за планиращия механизъм извън основното дърво на разработката на Kubernetes (out-of-tree).

Други промени

Също така в изданието Kubernetes 1.16 можем да отбележим инициативата за привеждане на съществуващите метрики в пълен ред, а по-точно — в съответствие с официалните указания към инструментизацията на K8s. Те по същество се основават на съответната документация на Prometheus.Несъответствията, от своя страна, са възникнали по различни причини (например, някои метрики са били създадени все още преди появата на текущите инструкции), и разработчиците решиха, че е време всичко да бъде приведено към единен стандарт, «в съответствие с останалата екосистема на Prometheus». Текущата реализация на тази инициатива носи статут алфа-версия, който ще бъде последователно повишаван в следващите версии на Kubernetes до бета (1.17) и стабилна (1.18).

Освен това можем да отбележим следните промени:

Развитие на поддръжката на Windows с с появата на инструментите Kubeadm за тази ОС (алфа-версия), възможността RunAsUserName за Windows контейнери (алфа-версия), подобрение поддръжка на Group Managed Service Account (gMSA) до бета-версия, поддръжка mount/attach за томове vSphere.
Преработен механизъм за компресия на данни в API отговорите.По-рано за тези цели се използваше HTTP филтър, който налагаше редица ограничения, затрудняващи включването му по подразбиране. Сега работи «прозрачна компресия на заявките»: клиентите, изпращащи Accept-Encoding: gzip в заглавката, получават GZIP компресиран отговор, ако размерът му надвишава 128 Кб. Клиентите на Go автоматично поддържат компресия (изпращат необходимата заглавка), така че веднага ще забележат намаление на трафика. (За други езици могат да са необходими малки модификации.)
Стана възможно масштабиране на HPA от/до нула pod-ове на база на външни метрики. Ако мащабирането се извършва на базата на обекти/външни метрики, когато натоварванията са неактивни, може автоматично да се мащабира до 0 реплики, за да се спестят ресурси. Особено полезна, тази функция трябва да е в случаите, когато worker-ите искат ресурси от GPU, а броят на различните видове неактивни worker-и надвишава броя на наличните GPU.
Нов клиент — k8s.io/client-go/metadata.Client — за „обобщен“ достъп до обекти. Той е предназначен за лесно извличане на метаданни (т.е. подраздел metadata) от ресурсите на клъстера и извършване на операции като събиране на отпадъци и квотиране.
Събиране на Kubernetes сега можете без остарели („вградени“ в in-tree) облачни доставчици (алфа версия).
В утилитата kubeadm добавиха експериментална (алфа версия) възможност да се прилагат патчи kustomize по време на операции init, присъединете се и upgrade. Повече информация за това как да използвате флага --experimental-kustomize, вижте в KEP.
Нов endpoint за apiserver — readyz, — позволяващ експортиране на информация за готовността му (readiness). Също така, API сървърът получи флаг --maximum-startup-sequence-duration, позволяващ регулиране на неговите рестартирания.
Две функции за Azure са обявени за стабилни: поддръжка на зони на достъпност (Availability Zones) и cross resource group (RG). Освен това, в Azure добавени:
- поддръжка на аутентификация AAD и ADFS;
- анотация service.beta.kubernetes.io/azure-pip-name за указване на публичен IP за балансьор на натоварването;
- възможността настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS получи подкрепа за EBS в Windows и оптимизирани API извиквания EC2 DescribeInstances.
Kubeadm сега самостоятелно мигрira конфигурацията на CoreDNS при обновяване на версията на CoreDNS.
Бинарниците etcd в съответстващия Docker образ направиха world-executable, което позволява стартиране на този образ без необходимост от права root. Освен това, образът за миграция etcd прекрати подкрепя версия etcd2.
В Cluster Autoscaler 1.16.0 премина на използване на distroless като базов образ, подобри производителността, добави нови облачни доставчици (DigitalOcean, Magnum, Packet).
Актуализации в използвания/зависим софтуер: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.