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

Сегодня, в среду, состоится ^[1] очередной релиз Kubernetes — 1.16. По сложившейся для нашего блога традиции, вот уже в юбилейный — десятый — раз мы рассказываем о наиболее значимых изменениях в новой версии.

Информация, использованная для подготовки этого материала, взята из таблицы Kubernetes enhancements tracking ^[2], CHANGELOG-1.16 ^[3] и сооветствующих issues, pull requests, а также Kubernetes Enhancement Proposals (KEP). Итак, поехали!..

Узлы

По-настоящему большое число заметных нововведений (в статусе альфа-версии) представлено на стороне узлов K8s-кластеров (Kubelet).

Во-первых, представлены так называемые «эфемерные контейнеры ^[4]» (Ephemeral Containers), призванные упростить процессы отладки в pod'ах. Новый механизм позволяет запускать специальные контейнеры, которые стартуют в пространстве имён существующих pod'ов и живут непродолжительное время. Их предназначение — взаимодействие с другими pod'ами и контейнерами в целях решения каких-либо проблем и отладки. Для этой возможности реализована новая команда kubectl debug, схожая по своей сути с kubectl exec: только вместо запуска процесса в контейнере (как в случае exec) она запускает контейнер в pod'е. Например, такая команда подсоединит новый контейнер к pod'у:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Подробности об эфемерных контейнерах (и примеры их использования) можно найти в соответствующем KEP ^[5]. Текущая реализация (в K8s 1.16) — альфа-версия, а среди критериев её перевода в бета-версию значится «тестирование Ephemeral Containers API на протяжении не менее 2 релизов [Kubernetes]».

NB: По своей сути и даже названию фича напоминает уже существующий плагин kubectl-debug ^[6], о котором мы уже писали ^[7]. Предполагается, что с появлением эфемерных контейнеров развитие отдельного внешнего плагина прекратится.

Другое новшество — PodOverhead ^[8] — призвано предоставить механизм подсчёта накладных расходов на pod'ы, которые могут сильно отличаться в зависимости от используемой исполняемой среды (runtime). В качестве примера авторы этого KEP ^[9] приводят Kata Containers, которые требуют запуска гостевого ядра, агента kata, init-системы и т.п. Когда overhead становится таким большим, его нельзя игнорировать, а значит — требуется способ учитывать его для дальнейшего квотирования, планирования и т.п. Для его реализации в PodSpec добавлено поле Overhead *ResourceList (сопоставляется с данными в RuntimeClass, если таковой используется).

Ещё одно заметное нововведение — менеджер топологии узла (Node Topology Manager), призванный унифицировать подход к тонкой настройке распределения аппаратных ресурсов для различных компонентов в Kubernetes. Эта инициатива вызвана растущей потребностью различных современных систем (из области телекоммуникаций, машинного обучения, финансовых услуг и т.п.) в высокопроизводительных параллельных вычислениях и минимизации задержек при исполнении операций, для чего они используют продвинутые возможности CPU и аппаратного ускорения. Такие оптимизации в Kubernetes до сих пор достигались благодаря разрозненным компонентам (CPU manager, Device manager, CNI), а теперь им добавят единый внутренний интерфейс, который унифицирует подход и упростит подключение новых аналогичных — так называемых topology-aware — компонентов на стороне Kubelet. Подробности — в соответствующем KEP ^[10].

Схема компонентов Topology Manager

Следующая фича — проверка контейнеров во время их запуска (startup probe ^[11]). Как известно, для контейнеров, что долго запускаются, затруднительно получить актуальный статус: их либо «убивают» ещё до реального начала функционирования, либо они на долгое время попадают в deadlock. Новая проверка (включается через feature gate под названием StartupProbeEnabled) отменяет — точнее, откладывает — действие любых других проверок до того момента, когда pod закончил свой запуск. По этой причине фичу изначально называли pod-startup liveness-probe holdoff ^[12]. Для pod'ов, что долго стартуют, можно проводить опрос состояния в относительно короткие временные интервалы.

Кроме того, сразу в статусе бета-версии представлено улучшение для RuntimeClass, добавляющее поддержку «гетерогенных кластеров». C RuntimeClass Scheduling ^[13] теперь вовсе не обязательно каждому узлу иметь поддержку каждого RuntimeClass'а: для pod'ов можно выбирать RuntimeClass, не думая о топологии кластера. Раньше для достижения этого — чтобы pod'ы оказывались на узлах с поддержкой всего им нужного — приходилось назначать соответствующие правила к NodeSelector и tolerations. В KEP ^[14] рассказывается о примерах использования и, конечно же, подробностях реализации.

Сеть

Две значимые сетевые фичи, что появились впервые (в альфа-версии) в Kubernetes 1.16 — это:

• Поддержка ^[15] двойного сетевого стека — IPv4/IPv6 — и соответствующее его «понимание» на уровне pod'ов, узлов, сервисов. Она включает в себя взаимодействие IPv4-to-IPv4 и IPv6-to-IPv6 между pod'ами, с pod'ов во внешние сервисы, эталонные реализации (в рамках плагинов Bridge CNI, PTP CNI и Host-Local IPAM), а также обратную совместимость с кластерами Kubernetes, работающими только по IPv4 или IPv6. Подробности реализации — в KEP ^[16].

  Пример вывода IP-адресов двух видов (IPv4 и IPv6) в списке pod'ов:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• Новый API для Endpoint — EndpointSlice API ^[17]. Он решает проблемы существующего Endpoint API с производительностью/масштабируемостью, что затрагивают различные компоненты в control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Новый API будет добавлен в API-группу Discovery и сможет обслуживать десятки тысяч backend endpoint'ов на каждом сервисе в кластере, состоящем из тысячей узлов. Для этого каждый Service отображается в N объектов EndpointSlice, каждый из которых по умолчанию имеет не более 100 endpoint'ов (значение настраивается). В EndpointSlice API предусмотрят и возможности для его будущего развития: поддержки множества IP-адресов у каждого pod'а, новых состояний для endpoint'ов (не только Ready и NotReady), динамического subsetting для endpoint'ов.

До бета-версии продвинулся представленный в прошлом релизе finalizer ^[18], названный service.kubernetes.io/load-balancer-cleanup и прикрепляемый к каждому сервису с типом LoadBalancer. В момент удаления такого сервиса он предотвращает фактическое удаление ресурса, пока не завершена «зачистка» всех соответствующих ресурсов балансировщика.

API Machinery

Настоящая «веха стабилизации» зафиксирована в области API-сервера Kubernetes и взаимодействия с ним. Во многом это случилось благодаря переводу в статус stable не нуждающихся в особом представлении CustomResourceDefinitions ^[19] (CRD), что имели статус бета-версии со времён далёкого Kubernetes 1.7 (а это июнь 2017 года!). Такая же стабилизация пришла и к связанным с ними фичам:

• «подресурсы» (subresources) ^[20] со /status и /scale для CustomResources;
• преобразование ^[21] версий для CRD, основанное на внешнем webhook'е;
• представленные недавно ^[22] (в K8s 1.15) значения по умолчанию (defaulting) и автоматическое удаление полей (pruning) для CustomResources;
• возможность ^[23] применения схемы OpenAPI v3 для создания и публикации OpenAPI-документации, используемой для валидации CRD-ресурсов на стороне сервера.

Ещё один механизм, давно ставший привычным для администраторов Kubernetes: admission webhook ^[24] — тоже долгое время пребывал в статусе беты (с K8s 1.9) и теперь объявлен стабильным.

Две другие фичи достигли бета-версии: server-side apply ^[25] и watch bookmarks ^[26].

А единственным значимым нововведением в альфа-версии стал отказ ^[27] от SelfLink — специального URI, представляющего указанный объект и являющегося частью ObjectMeta и ListMeta (т.е. частью любого объекта в Kubernetes). Зачем от него отказываются? Мотивация «по-простому» звучит ^[28] как отсутствие настоящих (непреодолимых) причин для того, чтобы это поле по-прежнему существовало. Более формальные причины — оптимизировать производительность (убрав ненужное поле) и упростить работу generic-apiserver, который вынужден обрабатывать такое поле особым образом (это единственное поле, которое устанавливается прямо перед сериализацией объекта). Настоящее «устаревание» (в рамках бета-версии) SelfLink произойдет к версии Kubernetes 1.20, а окончательное — 1.21.

Хранение данных

Основная работа в области storage, как и в прошлых релизах, наблюдается в области поддержки CSI ^[29]. Главными изменениями здесь стали:

• впервые (в альфа-версии) появилась ^[30] поддержка CSI-плагинов для рабочих узлов с Windows: актуальный способ работы с хранилищами и здесь придёт на смену плагинам in-tree в ядре Kubernetes и FlexVolume-плагинам от Microsoft на базе Powershell;

  
  Схема реализации CSI-плагинов в Kubernetes для Windows

• возможность изменения размера CSI-томов ^[31], представленная ещё в K8s 1.12, доросла до бета-версии;
• аналогичного «повышения» (с альфа- до бета-версии) достигла возможность использования CSI для создания локальных эфемерных томов (CSI Inline Volume Support ^[32]).

Появившаяся в прошлой версии Kubernetes функция клонирования томов ^[33] (использование существующих PVC в качестве DataSource для создания новых PVC) тоже теперь получила статус бета-версии.

Планировщик

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

• EvenPodsSpreading ^[34] — возможность использовать для «честного распределения» нагрузок pod'ы вместо логических единиц приложения (вроде Deployment и ReplicaSet) и регулировки этого распределения (как жёсткого требования или как мягкого условия, т.е. приоритета). Фича расширит имеющиеся возможности распределения планируемых pod'ов, ныне ограниченные опциями PodAffinity и PodAntiAffinity, предоставив администраторам более тонкий контроль в этом вопросе, а значит — лучшую высокую доступность и оптимизированное потребление ресурсов. Подробности — в KEP ^[35].
• Использование BestFit Policy в RequestedToCapacityRatio Priority Function во время планирования pod'ов, что позволит применять bin packing ^[36] («упаковку в контейнеры») как для основных ресурсов (процессор, память), так и расширенных (вроде GPU). Подробнее см. в KEP ^[37].

  
  Планирование pod'ов: до использования best fit policy (напрямую через default scheduler) и с её использованием (через scheduler extender)

Кроме того, представлена ^[38] возможность создавать свои плагины для планировщика вне основного дерева разработки Kubernetes (out-of-tree).

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

Также в релизе Kubernetes 1.16 можно отметить инициативу по приведению ^[39] имеющихся метрик в полный порядок, а если точнее — в соответствие с официальными предписаниями ^[40] к инструментации K8s. Они по большому счёту опираются на соответствующую документацию Prometheus ^[41]. Несыстоковки же образовались по разным причинам (например, некоторые метрики были попросту созданы ещё до того, как текущие инструкции появились), и разработчики решили, что настало время привести всё к единому стандарту, «в соответствие с остальной экосистемой Prometheus». Текущая реализация этой инициативы носит статус альфа-версии, который будет последовательно повышаться в последующих версиях Kubernetes до беты (1.17) и стабильного (1.18).

Кроме того, можно отметить следующие изменения:

• Развитие поддержки Windows с появлением ^[42] утилиты Kubeadm для этой ОС (альфа-версия), возможностью ^[43] RunAsUserName для Windows-контейнеров (альфа-версия), улучшением ^[44] поддержки Group Managed Service Account (gMSA) до бета-версии, поддержкой ^[45] mount/attach для томов vSphere.
• Переработанный ^[46] механизм сжатия данных в ответах API. Раньше для этих целей использовался HTTP-фильтр, который накладывал ряд ограничений, препятствующих его включению по умолчанию. Теперь работает «прозрачное сжатие запросов»: клиенты, отправляющие Accept-Encoding: gzip в заголовке, получают сжатый в GZIP ответ, если его размер превышал 128 Кб. Клиенты на Go автоматически поддерживают сжатие (отправляют нужный заголовок), так что сразу заметят снижение трафика. (Для других языков могут потебоваться небольшие модификации.)
• Стало возможным ^[47] масштабирование HPA из/до нуля pod'ов на основе внешних метрик. Если масштабирование производится на основе объектов/внешних метрик, то когда рабочие нагрузки простаивают, можно автоматически масштабироваться до 0 реплик, чтобы сэкономить ресурсы. Особенно полезной эта фича должна оказаться для случаев, когда worker'ы запрашивают ресурсы GPU, а количество различных типов простаивающих worker'ов превышает число доступных GPU.
• Новый клиент — k8s.io/client-go/metadata.Client ^[48] — для «обобщённого» доступа к объектам. Он предназначен для того, чтобы легко получать метаданные (т.е. подраздел metadata) из ресурсов кластера и осуществлять с ними операции из разряда сбора мусора и квотирования.
• Собирать Kubernetes теперь можно ^[49] без устаревших («встроенных» в in-tree) облачных провайдеров (альфа-версия).
• В утилиту kubeadm добавили ^[50] экспериментальную (альфа-версия) возможность применять патчи kustomize во время операций init, join и upgrade. Подробнее о том, как пользоваться флагом --experimental-kustomize, см. в KEP ^[51].
• Новый endpoint для apiserver — readyz ^[52], — позволяющий экспортировать информацию о его готовности (readiness). Также у API-сервера появился флаг --maximum-startup-sequence-duration, позволяющий регулировать его перезапуски.
• Две фичи для Azure объявлены стабильными: поддержка зон доступности ^[53] (Availability Zones) и cross resource group ^[54] (RG). Кроме того, в Azure добавлены:
  • поддержка аутентификации ^[55] AAD и ADFS;
  • аннотация ^[56] service.beta.kubernetes.io/azure-pip-name для указания публичного IP у балансировщика нагрузки;
  • возможность ^[57] настройки LoadBalancerName и LoadBalancerResourceGroup.
• У AWS появилась поддержка ^[58] для EBS в Windows и оптимизированы ^[59] API-вызовы EC2 DescribeInstances.
• Kubeadm теперь самостоятельно мигрирует ^[60] конфигурацию CoreDNS при обновлении версии CoreDNS.
• Бинарники etcd в соответствующем Docker-образе сделали ^[61] world-executable, что позволяет запускать этот образ без необходимости в правах root. Кроме того, образ миграции etcd прекратил ^[62] поддержку версии etcd2.
• В Cluster Autoscaler 1.16.0 ^[63] перешли на использование distroless в качестве базового образа, улучшили производительность, добавили новых облачных провайдеров (DigitalOcean, Magnum, Packet).
• Обновления в используемом/зависимом программном обеспечении: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

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

• «Kubernetes 1.15: обзор основных новшеств ^[64]»;
• «Kubernetes 1.14: обзор основных новшеств ^[65]»;
• «Kubernetes 1.13: обзор основных новшеств ^[66]»;
• «Kubernetes 1.12: обзор основных новшеств ^[67]».

Автор: Dmitry Stolyarov

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