Kubernetes 1.12: обзор основных новшеств

Сегодня 27 сентября, а это означает ^[1], что в рабочее время (по американскому часовому поясу) мы можем ожидать очередной релиз Kubernetes — 1.12 (впрочем, его официальный анонс иногда задерживается). В общем, самое время продолжить славную традицию и рассказать о наиболее значимых изменениях, что мы и сделаем, руководствуясь публичной информацией от проекта: таблицей Kubernetes features tracking ^[2], CHANGELOG-1.12 ^[3], многочисленными issues, pull requests и design proposals. Итак, что нового в K8s 1.12?

Хранилища

Если выделять одну вещь, которая чаще любых других упоминается среди всех issues, связанных с релизом Kubernetes 1.12, пожалуй, ей станет Container Storage Interface (CSI), о котором мы уже писали ^[4] на днях. По этой причине начнём с изменений в поддержке хранилищ.

Плагины CSI ^[5] как таковые сохранили ^[6] статус бета-версии и ожидают признания стабильными к следующему релизу Kubernetes (1.13). Что же нового тогда в поддержке CSI?

В феврале этого года в самой спецификации CSI началась ^[7] работа над концепцией топологии. Если вкратце, топология — это информация о сегментировании кластеров (например, по «стойкам» для инсталляций on-premise или же по «регионам» и «зонам» для облачных окружений), которую необходимо знать и учитывать системам оркестровки. Зачем? Тома, выделяемые провайдерами хранилищ, вовсе не обязательно будут одинаково доступными во всём кластере, а поэтому знания о топологии необходимы, чтобы эффективно планировать ресурсы и принимать решения по provisioning'у.

Следствием появления топологий в CSI (приняты ^[8] в спецификацию 1 июня) стала их поддержка в Kubernetes 1.12:

• поддержка как таковая ^[9] (регистрация информации о топологии тома, сообщаемой драйвером CSI) — альфа-версия;
• поддержка топологий в динамическом provisioning'е ^[10] (см. подробную документацию в design proposal под названием «Volume Topology-aware Scheduling ^[11]») — сразу бета-версия;
• поддержка топологии GCE PD ^[12] — альфа-версия;
• поддержка топологии AWS EBS ^[13] — бета-версия.

Но на этом связанные с CSI обновления не заканчиваются. Другое важное нововведение в релизе Kubernetes 1.12 — поддержка снапшотов для CSI ^[14] (пока в статусе альфа-версии). Снапшоты для томов как таковые появились ещё в релизе K8s 1.8 ^[15]. Основную реализацию, включающую в себя контроллер и provisioner (два отдельных бинарника), было решено вынести во внешний репозиторий ^[16]. С тех пор появилась поддержка для томов GCE PD, AWS EBS, OpenStack Cinder, GlusterFS и Kubernetes hostPath.

Новый же design proposal ^[17] призван «продолжить эту инициативу, добавив поддержку снапшотов для CSI Volume Drivers» (поддержка снапшотов в спецификации CSI описана здесь ^[18]). Поскольку в Kubernetes придерживаются принципа включения в core API минимального набора возможностей, эта реализация (как и для снапшотов в Volume Snapshot Controller) использует CRD (CustomResourceDefinitions).

И ещё пара новых фич для CSI-драйверов:

• альфа-версия возможности драйвера регистрировать себя ^[19] в Kubernetes API (с целью упростить для пользователей обнаружение драйверов, установленных в кластере, и позволить драйверам влиять на процессы взаимодействия Kubernetes с ними);
• альфа-версия возможности драйвера получать информацию о поде ^[20], запросившем том через NodePublish.

Представленный в прошлом релизе Kubernetes механизм динамического лимитирования ^[21] томов на узлах продвинулся с альфа-версии до беты, получив ^[22]… как вы догадались, поддержку CSI, а также Azure.

Наконец, фича Mount namespace propagation ^[23], позволяющая монтировать том как rshared (чтобы все примонтированные каталоги контейнера были видны на хосте) и имевшая статус бета-версии в релизе K8s 1.10 ^[24], объявлена стабильной.

Планировщик

В планировщике Kubernetes 1.12 улучшают производительность благодаря альфа-версии механизма ограничения ^[25] поиска в кластере узлов, подходящих для планирования пода (feasible nodes). Если раньше для каждой попытки планирования каждого пода kube-scheduler проверял доступность всех узлов и передавал их для оценки, то теперь планировщик будет находить лишь некоторое их количество, после чего останавливать свою работу. При этом в механизме предусмотрен обязательный отбор узлов из разных регионов и зон, а также необходимость просматривать разные узлы в разных циклах планирования (не отбирать первые 100 узлов каждый запуск). Решение о реализации этого механизма приняли, руководствуясь результатами анализа данных по производительности планировщика (если 90-й перцентиль показывал время в 30 мс для пода, то 99-й — уже 60 мс).

Кроме того, дозрели до бета-версии следующие возможности планировщика:

• Taint node by Condition ^[26], появившаяся ещё в K8s 1.8 и позволяющая помечать узел определённым статусом (для дальнейших действий) при наступлении определённых событий: теперь контроллер жизненного цикла узла автоматически создаёт taints, а планировщик их проверяет (вместо условий ^[27]);
• планирование подов в DaemonSet с помощью kube-scheduler (вместо контроллера DaemonSet): его тоже сделали активным по умолчанию;
• указание класса приоритета ^[28] в ResourceQuota.

Узлы кластера

Интересным нововведением стало появление (в статусе альфа-версии) RuntimeClass ^[29] — нового ресурса уровня кластера, предназначенного для обслуживания параметров исполняемой среды контейнеров (container runtime). RuntimeClasses назначаются на поды через одноимённое поле в PodSpec и реализуют поддержку использования множества исполняемых сред в рамках кластера или узла. Зачем?

«Интерес к использованию разных исполняемых сред в кластере растёт. На данный момент главным мотиватором для этого являются песочницы (sandboxes) и стремление контейнеров Kata и gVisor интегрироваться с Kubernetes. В будущем также потребуют поддержки другие runtime-модели вроде Windows-контейнеров или даже удалённых исполняемых сред. RuntimeClass предлагает способ выбирать между разными исполняемыми средами, настроенными в кластере, и изменять их свойства (и кластером, и пользователем)».

Для выбора между предопределёнными конфигурациями в CRI (Container Runtime Interface) передаётся RuntimeHandler ^[30], что призвано заменить нынешние аннотации пода:

А конфигурация в 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 ^[31].

Кроме того, до статуса бета-версии выросли механизм регистрации локальных плагинов ^[32] (включая CSI) в Kubelet и shareProcessNamespace ^[33] (фича стала включённой по умолчанию).

Сети

Главная новость в сетевой части Kubernetes — альфа-версия ^[34] поддержки SCTP ^[35] (Stream Control Transmission Protocol). Получив поддержку в Pod, Service, Endpoint и NetworkPolicy, этот телекоммуникационный протокол пополнил ряды TCP и UDP. С новой фичей «приложения, требующие SCTP в качестве L4-протокола для своих интерфейсов, можно будет проще деплоить на Kubernetes-кластерах; например, они смогут использовать service discovery на базе kube-dns, а их взаимодействие будет контролироваться через NetworkPolicy». Подробности о реализации доступны в этом документе ^[36].

Стабильного статуса также достигли две сетевые возможности, представленные в K8s 1.8: поддержка политик ^[37] для исходящего трафика EgressRules в NetworkPolicy API и применение правил ^[38] по CIDR источника/получателя через ipBlockRule.

Масштабирование

Улучшения в Horizontal Pod Autoscaler включают в себя:

• обновлённый алгоритм ^[39] для более быстрого достижения правильного размера (сразу и альфа-, и бета-версия), подробнее о котором читайте в новом разделе документации ^[40];
• развитие произвольных/пользовательских метрик ^[41], вторая бета-версия которых получила переработанный API и поддержку селекторов лейблов.

Не стоит на месте и вертикальное масштабирование подов ^[42], которому до достижения бета-версии не хватало тестирования пользователями. Авторы сочли его достаточным для релиза K8s 1.12 и напоминают ^[43], что эта возможность является скорее дополнением к Kubernetes (не входит в ядро системы). Вся разработка ведётся в отдельном репозитории, бета-релиз в котором будет приурочен к релизу Kubernetes.

Схема работы Vertical Pod Autoscaler (VPA) в Kubernetes

Наконец, в K8s 1.12 включены (в виде альфа-версии) результаты работы ^[44] над «упрощением инсталляции с помощью ComponentConfig» (в рамках sig-cluster-lifecycle), продолжающейся уже почти два года. К сожалению, по непонятной причине (простому недосмотру?), доступ к документу design proposal ^[45] с подробностями закрыт для анонимных пользователей.

Другие изменения

API

Две новые возможности реализованы в группе api-machinery:

• параметр dry-run ^[46] для apiserver (альфа-версия), который производит имитацию валидации и обработки запросов;
• Resource Quota API ^[47] (сразу бета-версия), определяющий ограниченные по умолчанию ресурсы (вместо текущего поведения, когда потребление ресурсов не ограничено, если квота не задана).

Azure

Объявлена стабильной:

• поддержка ^[48] Azure Virtual Machine Scale Sets (VMSS);
• поддержка ^[49] Azure в cluster-autoscaler.

Добавлены первые реализации (альфа-версии):

• поддержки ^[50] Azure Availability Zones;
• поддержки ^[51] узлов типа cross resource group ^[52] (RG) и неуправляемых узлов (on-prem).

Kubectl

• Реализована альфа-версия обновлённого механизма плагинов ^[53], что позволяет как добавлять новые команды, так и переписывать уже существующие подкоманды любого уровня вложенности. Он сделан похожим на Git и просматривает исполняемые файлы, начинающиеся с kubectl-, в $PATH пользователя. Подробнее см. в design proposal ^[54].
• Реализована бета-версия идеи по выделению ^[55] пакета pkg/kubectl/genericclioptions из kubectl в самостоятельный репозиторий.
• Объявлена стабильной функция вывода на стороне сервера ^[56] (server-side printing).

Прочие

• Представлена альфа-версия нового механизма TTL after finish ^[57], предназначенного для ограничения времени жизни закончивших выполняться Jobs и Pods. По истечении заданного TTL объекты будут автоматически вычищены без необходимости в пользовательском вмешательстве.
• Объявлена стабильной генерация в Kubelet приватного ключа и CSR (TLS Bootstrap) для подписи сертификата на уровне кластера.
• Перешла в статус бета-версии ротация серверного TLS-сертификата в Kubelet.

P.S.

Читайте также в нашем блоге:

• «Kubernetes 1.11: обзор основных новшеств ^[58]»;
• «Kubernetes 1.10: обзор основных новшеств ^[24]»;
• «Kubernetes 1.9: обзор основных новшеств ^[59]»;
• «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017 ^[60]»;
• «Kubernetes 1.8: обзор основных новшеств ^[15]»;
• «Docker 17.06 и Kubernetes 1.7: ключевые новшества ^[61]».

Автор: distol

Источник ^[62]