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

Kubernetes 1.17: основные новшества:

Маршрутизация с учётом топологии

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

• одинаковый для сервисов узел,
• та же самая серверная стойка,
• тот же самый регион,
• тот же самый облачный провайдер

Примеры использования:

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

Такую маршрутизацию, «знающую» о топологии, ещё называют подобием network affinity — по аналогии с node affinity, pod affinity/anti-affinity или появившимся не так давно Topology-Aware Volume Scheduling (и Volume Provisioning). Текущий уровень реализации 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 — достигла бета-версии. Эта фича критична для того, чтобы перевести существующие плагины хранилищ (in-tree) на современный интерфейс (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'а.