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

Сегодня 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, что призвано заменить нынешние аннотации пода:

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

Схема работы 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 Virtual Machine Scale Sets (VMSS);
• поддержка Azure в cluster-autoscaler.

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

• поддержки 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: обзор основных новшеств»;
• «Kubernetes 1.10: обзор основных новшеств»;
• «Kubernetes 1.9: обзор основных новшеств»;
• «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
• «Kubernetes 1.8: обзор основных новшеств»;
• «Docker 17.06 и Kubernetes 1.7: ключевые новшества».

Автор: distol

Источник