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

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

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

Възли

Наистина голямо число забележителни нововъведения (в статуса alpha) е представено от страната на възлите на 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) е версия alpha, а сред критериите за нейното прехвърляне в версия beta фигурира „teстване на Ephemeral Containers API за поне 2 издания [Kubernetes]“.

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

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

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

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

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

Освен това, веднага в бета-статус е представено подобрение за RuntimeClass, което добавя поддръжка на „хетерогенни клъстери“. С 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 и ще може да обслужва десетки хиляди backend endpoint’а на всяка услуга в клъстера, състоящ се от хиляди възли. За целта всяка услуга се изобразява в N обекта EndpointSlice, всеки от които по подразбиране има не повече от 100 endpoint’а (настройваемо значение). В EndpointSlice API ще се предвидят и възможности за неговото бъдещо развитие: поддръжка на множество IP адреси за всеки pod, нови състояния за endpoint’ите (не само Готов и НеГотов), динамично подмножество за endpoint’ите.

До бета версия напредна представеният в миналия релиз финализатор, наречен 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, който е принуден да обработва такова поле по особен начин (това е единственото поле, което се задава точно преди сериализацията на обекта). Настоящото „остаряване“ (в рамките на бета версията) ще се случи с версия на Kubernetes 1.20, а окончателното — 1.21. — специален URI, представляващ посочения обект и част от Основната работа в областта на storage, както и в предишните версии, се наблюдава в областта на

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

подкрепата на 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, предоставяйки на администраторите по-фин контрол по този въпрос, а следователно — по-добра висока достъпност и оптимизирана консумация на ресурси. Подробности — в KEP.
Използване BestFit Policy в RequestedToCapacityRatio Priority Function по време на планирането на 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, join и 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 вече сам мигрира конфигурацията на 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.

P.S.

Прочетете също в нашия блог:

Източник: habr.com