🥇Kubernetes 1.16: огляд основних нововведень ProHoster

Сьогодні, у середу, відбудеться черговий реліз Kubernetes - 1.16. За традицією, що склалася для нашого блогу, ось уже в ювілейний — десятий — раз ми розповідаємо про найбільш значущі зміни в новій версії.

Інформація, використана для підготовки цього матеріалу, взята з таблиці Kubernetes enhancements tracking, CHANGELOG-1.16 і співвідносних issues, 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 - Покликано надати механізм підрахунку накладних витрат на під'ї, які можуть сильно відрізнятися в залежності від використовуваного середовища (runtime). Як приклад автори цього KEP наводять Kata Containers, які вимагають запуску гостьового ядра, агента kata, init-системи тощо. Коли overhead стає таким великим, його не можна ігнорувати, а отже, потрібен спосіб враховувати його для подальшого квотування, планування тощо. Для його реалізації в PodSpec додано поле Overhead *ResourceList (порівняється з даними в RuntimeClass, якщо така використовується).

Ще одне помітне нововведення менеджер топології вузла (Node Topology Manager), покликаний уніфікувати підхід до тонкого настроювання розподілу апаратних ресурсів для різних компонентів Kubernetes. Ця ініціатива викликана зростаючою потребою різних сучасних систем (в галузі телекомунікацій, машинного навчання, фінансових послуг тощо) у високопродуктивних паралельних обчисленнях та мінімізації затримок при виконанні операцій, для чого вони використовують просунуті можливості CPU та апаратного прискорення. Такі оптимізації в Kubernetes досі досягалися завдяки розрізненим компонентам (CPU manager, Device manager, CNI), а тепер їм додадуть єдиний внутрішній інтерфейс, який уніфікує підхід та спростить підключення нових аналогічних – так званих topology-aware – компонентів на стороні Kubelet. Подробиці - в відповідному KEP.

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

Наступна фіча - перевірка контейнерів під час їхнього запуску (startup probe). Як відомо, для контейнерів, які довго запускаються, важко отримати актуальний статус: їх або «вбивають» ще до реального початку функціонування, або вони на тривалий час потрапляють у lock. Нова перевірка (включається через feature gate під назвою StartupProbeEnabled) скасовує - точніше, відкладає - дію будь-яких інших перевірок до того моменту, коли pod закінчив свій запуск. З цієї причини фічу спочатку називали pod-startup liveness-probe holdoff. Для pod'ів, що довго стартують, можна проводити опитування стану відносно короткі часові інтервали.

Крім того, відразу в статусі бета-версії представлено покращення для RuntimeClass, що додає підтримку гетерогенних кластерів. C RuntimeClass Scheduling тепер зовсім не обов'язково кожному вузлу мати підтримку кожного RuntimeClass'а: для pod'ів можна вибирати RuntimeClass, не думаючи про топологію кластера. Раніше для досягнення цього — щоб під'ї опинялися на вузлах із підтримкою всього їм потрібного — доводилося призначати відповідні правила NodeSelector і tolerations. У КЕП розповідається про приклади використання та, звичайно ж, подробиці реалізації.

Мережа

Дві значні мережеві фічі, що з'явилися вперше (в альфа-версії) у Kubernetes 1.16 - це:

Підтримка подвійного мережевого стека - IPv4/IPv6 - і відповідне його "розуміння" на рівні pod'ів, вузлів, сервісів. Вона включає взаємодію IPv4-to-IPv4 і IPv6-to-IPv6 між pod'ами, з pod'ів у зовнішні сервіси, еталонні реалізації (в рамках плагінів Bridge CNI, PTP CNI і Host-Local IPAM), а також зворотну сумісність із кластерами Kubernetes, що працюють лише за IPv4 або IPv6. Подробиці реалізації - у КЕП.
Приклад виведення 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'ів на кожному сервісі в кластері, що складається з тисяч вузлів. Для цього кожен Service відображається в N об'єктів EndpointSlice, кожен з яких за умовчанням має не більше 100 endpoint'ів (значення налаштовується). В EndpointSlice API передбачать і можливості для його майбутнього розвитку: підтримки безлічі IP-адрес у кожного pod'а, нових станів для endpoint'ів (не тільки Ready и NotReady), динамічний subsetting для 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, який змушений обробляти таке поле особливим чином (це єдине поле, яке встановлюється перед серіалізацією об'єкта). Справжнє «старіння» (в рамках бета-версії) SelfLink відбудеться до версії Kubernetes 1.20, а остаточна – 1.21.

Зберігання даних

Основна робота в галузі 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, надавши адміністраторам більш тонкий контроль у цьому питанні, а отже, кращу високу доступність та оптимізоване споживання ресурсів. Подробиці - в КЕП.
Використання BestFit Policy в RequestedToCapacityRatio Priority Function під час планування pod'ів, що дозволить застосовувати упаковка для сміття («Упаковка в контейнери») як для основних ресурсів (процесор, пам'ять), так і розширених (на зразок GPU). Детальніше див. КЕП.

Планування 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, див. КЕП.
Новий 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.
Бінарники тощо у відповідному 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.

PS

Читайте також у нашому блозі:

Джерело: habr.com

Kubernetes 1.16: огляд основних нововведень