Kubernetes 1.17 -  відбувся черговий реліз програмного рішення для автоматизації розгортання, масштабування контейнеризованих додатків та управління ними

Kubernetes 1.17: основні нововведення:

Маршрутизація з урахуванням топології

Загальна ідея зводиться до того, щоб надати можливість реалізовувати локальну маршрутизацію для сервісів, що знаходяться в Kubernetes. «Локальність» у цьому випадку означає «той самий топологічний рівень» (topology level), яким може бути:

• однаковий для сервісів вузол,
• та сама серверна стійка,
• той самий регіон,
• той самий хмарний провайдер

Приклади використання:

• економія на трафіку в хмарних інсталяціях з безліччю зон доступності (multi-AZ);
• менші затримки у продуктивності/краща пропускна спроможність;
• шардований сервіс, що має локальну інформацію про сайт у кожному шарді;
• розміщення fluentd (або аналогів) на один вузол із додатками, логи яких збираються.

Таку маршрутизацію, що «знає» про топологію, ще називають подібністю network affinity — за аналогією з node affinity, pod affinity/anti-affinity або що з'явився нещодавно Topology-Aware Volume Scheduing (і Volume Provision). Поточний рівень реалізації 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-тести.

Прогрес CSI

Оголошено стабільною підтримка топологій для сховищ на базі CSI, вперше представлена ​​в K8s 1.12.

Ініціатива з міграції плагінів томів на CSI — CSI Migration — досягла бета-версії. Ця фіча критична для того, щоб перекласти існуючі плагіни сховищ на сучасний інтерфейс на сучасний інтерфейс (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 досягла інша значуща функціональність у контексті CSI, що бере свій початок (альфа-реалізацію) в K8s 1.12, — створення снапшотів і . Серед змін, зроблених у Kubernetes Volume Snapshot на шляху до бета-релізу:

• розбивка sidecar'а CSI external-snapshotter на два контролера,
• додано секрет видалення (deletion secret) як інструкція до вмісту снапшота тома,
• новий фіналізатор (finalizer) для запобігання видаленню API-об'єкта снапшота за наявності зв'язків, що залишилися.

Cloud Provider Labels

Лейбли, які автоматично призначаються на створювані вузли та томи в залежності від використовуваного хмарного провайдера, були доступні в 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

… але, як і раніше, доступні і за своїми старими назвами (для зворотної сумісності). Проте всім адміністраторам рекомендується переходити на актуальні лейбли

Структурований висновок kubeadm

У форматі альфа-версії вперше представлено структурований висновок для утиліти kubeadm. Формати, що підтримуються: JSON, YAML, Go-шаблон.

Хоча Kubernetes і може бути розгорнутий вручну, стандартом де-факто (якщо не де-юре) для цієї операції є використання kubeadm. Популярні інструменти управління системами типу Terraform спираються на kubeadm для деплою Kubernetes. Заплановані поліпшення в Cluster API включають компонований пакет для bootstrapping'а Kubernetes з kubeadm і cloud-init.

Без структурованого висновку навіть найнешкідливіші на перший погляд зміни можуть зламати Terraform, Cluster API та інший софт, kubeadm, що використовує результати роботи.

Реліз Kubernetes 1.17 відбувся під гаслом «Стабільність». Тому сприяв той факт, що дуже багато нововведень у ньому (їх загальна кількість — 14) набули статусу GA. Серед таких:

• «помітка» вузлів за певними умовами (TaintNodesByCondition), що з'явилася в K8s 1.8;
• Watch Bookmarks — новий тип подій, що мають мітку, що всі об'єкти до певної версії (resourceVersion) вже були оброблені watch'ем;
• значення за замовчуванням (defaulting) для Custom Resources;
• розділені між контейнерами в pod'е process namespaces;
• ScheduleDaemonSetPods — планування pod'ів у DaemonSet за допомогою kube-scheduler (замість контролера DaemonSet);
• динамічні ліміти на кількість томів залежно від типу вузла;
• підтримка змінних оточення для назв директорій, що монтуються як subPath;
• перенесення Kubelet heartbeats в спеціалізований Lease API;
• «захист фіналізатора» (Finalizer Protection) для балансувальників навантаження (перевірка відповідних ресурсів Service'а перед видаленням ресурсів LoadBalancer'а);
• оптимізація kube-apiserver в продуктивності при роботі зі безліччю watches, що спостерігають за ідентичними наборами об'єктів, — досягається завдяки уникаю повторної серіалізації одних і тих же об'єктів для кожного watcher'а.

Інші новини