![](https://habrastorage.org/files/48b/c2d/ec0/48bc2dec061e42928e98c92cbbadf968.png)
Сегодня 27 сентября, а это означает, что в рабочее время (по американскому часовому поясу) мы можем ожидать очередной релиз Kubernetes — 1.12 (впрочем, его официальный анонс иногда задерживается). В общем, самое время продолжить славную традицию и рассказать о наиболее значимых изменениях, что мы и сделаем, руководствуясь публичной информацией от проекта: таблицей Kubernetes features tracking, CHANGELOG-1.12, многочисленными issues, pull requests и design proposals. Итак, что нового в K8s 1.12?
Хранилища
Если выделять одну вещь, которая чаще любых других упоминается среди всех issues, связанных с релизом Kubernetes 1.12, пожалуй, ей станет Container Storage Interface (CSI), о котором мы уже писали на днях. По этой причине начнём с изменений в поддержке хранилищ.
Плагины CSI как таковые сохранили статус бета-версии и ожидают признания стабильными к следующему релизу Kubernetes (1.13). Что же нового тогда в поддержке CSI?
В феврале этого года в самой спецификации CSI началась работа над концепцией топологии. Если вкратце, топология — это информация о сегментировании кластеров (например, по «стойкам» для инсталляций on-premise или же по «регионам» и «зонам» для облачных окружений), которую необходимо знать и учитывать системам оркестровки. Зачем? Тома, выделяемые провайдерами хранилищ, вовсе не обязательно будут одинаково доступными во всём кластере, а поэтому знания о топологии необходимы, чтобы эффективно планировать ресурсы и принимать решения по provisioning'у.
Следствием появления топологий в CSI (приняты в спецификацию 1 июня) стала их поддержка в Kubernetes 1.12:
- поддержка как таковая (регистрация информации о топологии тома, сообщаемой драйвером CSI) — альфа-версия;
- поддержка топологий в динамическом provisioning'е (см. подробную документацию в design proposal под названием «Volume Topology-aware Scheduling») — сразу бета-версия;
- поддержка топологии GCE PD — альфа-версия;
- поддержка топологии AWS EBS — бета-версия.
Но на этом связанные с CSI обновления не заканчиваются. Другое важное нововведение в релизе Kubernetes 1.12 — поддержка снапшотов для CSI (пока в статусе альфа-версии). Снапшоты для томов как таковые появились ещё в релизе K8s 1.8. Основную реализацию, включающую в себя контроллер и provisioner (два отдельных бинарника), было решено вынести во внешний репозиторий. С тех пор появилась поддержка для томов GCE PD, AWS EBS, OpenStack Cinder, GlusterFS и Kubernetes
hostPath
.Новый же design proposal призван «продолжить эту инициативу, добавив поддержку снапшотов для CSI Volume Drivers» (поддержка снапшотов в спецификации CSI описана здесь). Поскольку в Kubernetes придерживаются принципа включения в core API минимального набора возможностей, эта реализация (как и для снапшотов в Volume Snapshot Controller) использует CRD (
CustomResourceDefinitions
).И ещё пара новых фич для CSI-драйверов:
- альфа-версия возможности драйвера регистрировать себя в Kubernetes API (с целью упростить для пользователей обнаружение драйверов, установленных в кластере, и позволить драйверам влиять на процессы взаимодействия Kubernetes с ними);
- альфа-версия возможности драйвера получать информацию о поде, запросившем том через
NodePublish
.
Представленный в прошлом релизе Kubernetes механизм динамического лимитирования томов на узлах продвинулся с альфа-версии до беты, получив… как вы догадались, поддержку CSI, а также Azure.
Наконец, фича Mount namespace propagation, позволяющая монтировать том как
rshared
(чтобы все примонтированные каталоги контейнера были видны на хосте) и имевшая статус бета-версии в релизе K8s 1.10, объявлена стабильной.Планировщик
В планировщике Kubernetes 1.12 улучшают производительность благодаря альфа-версии механизма ограничения поиска в кластере узлов, подходящих для планирования пода (feasible nodes). Если раньше для каждой попытки планирования каждого пода kube-scheduler проверял доступность всех узлов и передавал их для оценки, то теперь планировщик будет находить лишь некоторое их количество, после чего останавливать свою работу. При этом в механизме предусмотрен обязательный отбор узлов из разных регионов и зон, а также необходимость просматривать разные узлы в разных циклах планирования (не отбирать первые 100 узлов каждый запуск). Решение о реализации этого механизма приняли, руководствуясь результатами анализа данных по производительности планировщика (если 90-й перцентиль показывал время в 30 мс для пода, то 99-й — уже 60 мс).
Кроме того, дозрели до бета-версии следующие возможности планировщика:
- Taint node by Condition, появившаяся ещё в K8s 1.8 и позволяющая помечать узел определённым статусом (для дальнейших действий) при наступлении определённых событий: теперь контроллер жизненного цикла узла автоматически создаёт taints, а планировщик их проверяет (вместо условий);
- планирование подов в
DaemonSet
с помощью kube-scheduler (вместо контроллераDaemonSet
): его тоже сделали активным по умолчанию; - указание класса приоритета в
ResourceQuota
.
Узлы кластера
Интересным нововведением стало появление (в статусе альфа-версии)
RuntimeClass
— нового ресурса уровня кластера, предназначенного для обслуживания параметров исполняемой среды контейнеров (container runtime). RuntimeClasses
назначаются на поды через одноимённое поле в PodSpec
и реализуют поддержку использования множества исполняемых сред в рамках кластера или узла. Зачем?«Интерес к использованию разных исполняемых сред в кластере растёт. На данный момент главным мотиватором для этого являются песочницы (sandboxes) и стремление контейнеров Kata и gVisor интегрироваться с Kubernetes. В будущем также потребуют поддержки другие runtime-модели вроде Windows-контейнеров или даже удалённых исполняемых сред. RuntimeClass предлагает способ выбирать между разными исполняемыми средами, настроенными в кластере, и изменять их свойства (и кластером, и пользователем)».
Для выбора между предопределёнными конфигурациями в CRI (Container Runtime Interface) передаётся
RuntimeHandler
, что призвано заменить нынешние аннотации пода:![](https://habrastorage.org/webt/wm/jm/yh/wmjmyh4_fivl7msyzb0ghzeqa68.png)
А конфигурация в containerd для kata-runtime выглядит примерно так:
[plugins.cri.containerd.kata-runtime]
runtime_type = "io.containerd.runtime.v1.linux"
runtime_engine = "/opt/kata/bin/kata-runtime"
runtime_root = ""
Критерием
RuntimeClass
для альфа-версии является успешная валидация по тесту CRI.Кроме того, до статуса бета-версии выросли механизм регистрации локальных плагинов (включая CSI) в Kubelet и
shareProcessNamespace
(фича стала включённой по умолчанию).Сети
Главная новость в сетевой части Kubernetes — альфа-версия поддержки SCTP (Stream Control Transmission Protocol). Получив поддержку в Pod, Service, Endpoint и NetworkPolicy, этот телекоммуникационный протокол пополнил ряды TCP и UDP. С новой фичей «приложения, требующие SCTP в качестве L4-протокола для своих интерфейсов, можно будет проще деплоить на Kubernetes-кластерах; например, они смогут использовать service discovery на базе kube-dns, а их взаимодействие будет контролироваться через NetworkPolicy». Подробности о реализации доступны в этом документе.
Стабильного статуса также достигли две сетевые возможности, представленные в K8s 1.8: поддержка политик для исходящего трафика
EgressRules
в NetworkPolicy API и применение правил по CIDR источника/получателя через ipBlockRule
.Масштабирование
Улучшения в Horizontal Pod Autoscaler включают в себя:
- обновлённый алгоритм для более быстрого достижения правильного размера (сразу и альфа-, и бета-версия), подробнее о котором читайте в новом разделе документации;
- развитие произвольных/пользовательских метрик, вторая бета-версия которых получила переработанный API и поддержку селекторов лейблов.
Не стоит на месте и вертикальное масштабирование подов, которому до достижения бета-версии не хватало тестирования пользователями. Авторы сочли его достаточным для релиза K8s 1.12 и напоминают, что эта возможность является скорее дополнением к Kubernetes (не входит в ядро системы). Вся разработка ведётся в отдельном репозитории, бета-релиз в котором будет приурочен к релизу Kubernetes.
![](https://habrastorage.org/webt/sl/0e/je/sl0ejeaihoybtqm8khj5y_tkffa.png)
Схема работы Vertical Pod Autoscaler (VPA) в Kubernetes
Наконец, в K8s 1.12 включены (в виде альфа-версии) результаты работы над «упрощением инсталляции с помощью
ComponentConfig
» (в рамках sig-cluster-lifecycle), продолжающейся уже почти два года. К сожалению, по непонятной причине (простому недосмотру?), доступ к документу design proposal с подробностями закрыт для анонимных пользователей.Другие изменения
API
Две новые возможности реализованы в группе api-machinery:
-
параметр dry-run
для apiserver (альфа-версия), который производит имитацию валидации и обработки запросов; - Resource Quota API (сразу бета-версия), определяющий ограниченные по умолчанию ресурсы (вместо текущего поведения, когда потребление ресурсов не ограничено, если квота не задана).
Azure
Объявлена стабильной:
Добавлены первые реализации (альфа-версии):
- поддержки Azure Availability Zones;
- поддержки узлов типа cross resource group (RG) и неуправляемых узлов (on-prem).
Kubectl
- Реализована альфа-версия обновлённого механизма плагинов, что позволяет как добавлять новые команды, так и переписывать уже существующие подкоманды любого уровня вложенности. Он сделан похожим на Git и просматривает исполняемые файлы, начинающиеся с
kubectl-
, в$PATH
пользователя. Подробнее см. в design proposal. - Реализована бета-версия идеи по выделению пакета
pkg/kubectl/genericclioptions
из kubectl в самостоятельный репозиторий. - Объявлена стабильной функция вывода на стороне сервера (server-side printing).
Прочие
- Представлена альфа-версия нового механизма TTL after finish, предназначенного для ограничения времени жизни закончивших выполняться Jobs и Pods. По истечении заданного TTL объекты будут автоматически вычищены без необходимости в пользовательском вмешательстве.
- Объявлена стабильной генерация в Kubelet приватного ключа и CSR (TLS Bootstrap) для подписи сертификата на уровне кластера.
- Перешла в статус бета-версии ротация серверного TLS-сертификата в Kubelet.
P.S.
Читайте также в нашем блоге:
- «Kubernetes 1.11: обзор основных новшеств»;
- «Интеграция containerd с Kubernetes, заменяющая Docker, готова к production»;
- «Kubernetes 1.10: обзор основных новшеств»;
- «Kubernetes 1.9: обзор основных новшеств»;
- «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
- «Kubernetes 1.8: обзор основных новшеств»;
- «Docker 17.06 и Kubernetes 1.7: ключевые новшества».