Очередной релиз системы Kubernetes, 1.9, должен случиться на этой неделе. Согласно текущему плану ^[1], это произойдёт сегодня (13 декабря). Об основных новшествах, которые принесёт этот выпуск, уже известно: как и в прошлый раз ^[2], их накопилось действительно много. Представляем обзор самых значимых изменений, которые приходят в Kubernetes с грядущим релизом 1.9.

При написании этой статьи использовались:

• официальный черновик K8s 1.9 Release Notes ^[3];
• таблица для разработчиков Kubernetes Features OSS tracking board ^[4] (обратите внимание, что некоторые её данные расходятся с реальностью, т.к. не все перечисленные там фичи успели закончить к релизу);
• CHANGELOG-1.9 ^[5].

… и, конечно, бесконечные issues и pull requests в GitHub-репозиториях проекта.

API

Редизайн Event API

В архитектуре API событий (и библиотеке EventRecorder) реализованы ^[6] изменения, направленные на улучшения в двух направлениях:

1. Снизить влияние событий на общую производительность кластера.
2. Сделать объект Event более структурированным, чтобы упростить дальнейшую работу с ним («первый и необходимый шаг для возможности автоматизировать его анализ»).

Среди проблем, решаемых этими изменениями:

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

Сравнение старых и новых объектов Event:

В деталях всё это описано в design-proposals: events-redesign ^[7]. Текущий статус — альфа-версия.

Admission webhooks

Добавлена ^[8] бета-версия механизма под названием admission webhooks, позволяющего изменять и/или принимать и отвергать запросы к API. Он относится к этапу контроля допуска (admission control) и срабатывает на последних шагах обработки запросов перед их сохранением в базу данных (etcd). По своей сути эти webhooks похожи на initializers (о них мы писали в переводной статье «Что происходит в Kubernetes при запуске kubectl run? Часть 1 ^[9]»), однако:

• распространяются на все действия (создание, модификация, удаление);
• выполняются синхронно (т.е. длительные задержки недопустимы);
• объекты, для которых выполняются хуки, недоступны до момента их исполнения.

Пример использования admission webhooks из документации — проверка одного поля объекта и установка значения для его другого поля. Другой пример — автоматическое добавление служебного контейнера (допустим, выполняющего бэкап) по аннотации пода. Например, у нас есть под с MySQL, с одним контейнером (в котором сама MySQL), и у этого пода указана специальная аннотация. Когда мы создаем под, запрос приходит в Kubernetes API, который отправляет запрос в наше приложение через admission webhook, а приложение видит запрос, видит, что создается под, видит свою специальную аннотацию и делает просто rewrite — добавляет в под второй контейнер.

Подробное описание admission webhooks опубликовано здесь ^[10].

Workload API

Workload API был представлен в прошлом релизе Kubernetes и объединил в себе интерфейсы, относящиеся к «рабочим нагрузкам»: DaemonSet, Deployment, ReplicaSet, StatefulSet. Для них была выделена отдельная группа API под названием apps, и с выпуском K8s 1.9 все эти изменения получили стабильный статус.

Основные изменения в Workload API, представленные в релизах Kubernetes 1.8 и 1.9, обобщены в документации проекта ^[11].

Другое

• В состояние StatefulSet (и DaemonSet) добавлена ^[12] поддержка условий ^[13], что делает их совместимыми с другими контроллерами категории core/v1.
• Флаг --chunk-size={SIZE} добавлен в kubectl get, а поддержка ограничения данных, выводимых API (API chunking), в целом получила статус бета-версии.

Хранилища

Out-of-Tree Volume Plugins (CSI)

Имеющиеся плагины томов входят в состав Kubernetes: их называют «in-tree», поскольку весь код включён в основной репозиторий проекта, а в скомпилированном виде они распространяются в составе бинарников K8s. У такого подхода есть очевидный минус: поддержка сторонних хранилищ их производителями/разработчиками зависит от циклов релизов Kubernetes (кроме того, весь исходный код должен быть Open Source). Отчасти эта проблема решается плагином Flexvolume ^[14], однако данный механизм не гарантирует обратной совместимости и (при установке драйвера) требует развёртывания своих файлов в определенные места на узлах и мастерах.

Новый же подход получил название Out-of-Tree CSI Volume Plugins ^[15] (CSI — это Container Storage Interface, определяющий, как системы оркестровки контейнеров могут использовать сторонние хранилища). Он призван реализовать полноценный API в Kubernetes, который позволяет:

• создавать тома «вне дерева» (репозитория Kubernetes);
• не требовать включения скомпилированного кода в бинарные файлы K8s;
• не требовать прямого доступа к машинам с Kubernetes для деплоя этих плагинов (драйверов).

Авторами предложен следующий рекомендуемый механизм для деплоя драйверов CSI в Kubernetes:

Разъяснения по этой схеме и подробности о проекте в целом опубликованы в этом документе ^[16]. Статус реализации в Kubernetes 1.9 — альфа-версия.

Запуск mount внутри подов

Фича под названием Containerized mounts ^[17] привносит в Kubernetes возможность запуска утилит монтирования на подах, а не на хостовой машине. Таким образом, хостовая система может оставаться минимальным дистрибутивом GNU/Linux без стороннего ПО: для создания Ceph RBD (/usr/bin/rbd), монтирования GlusterFS (mount.glusterfs) и т.п., — а все утилиты для работы с томами (операции provision/delete, attach/detach, mount/unmount) помещаются в поды.

Подробности об этой возможности опубликованы в design-proposals: containerized-mounter-pod ^[18]. Текущий статус — альфа-версия.

Изменение размера томов

Базовая поддержка ^[19] операции resize для существующих PV (PersistentVolume) появилась в Kubernetes 1.8. К 1.9 она так и не достигла бета-версии, однако заметный прогресс налицо: добавлена поддержка изменения размера для файловых систем, а вместе с ней — для томов GCE, EBS, Cinder, а также Ceph RBD ^[20]. Бета-версия ожидается к релизу 1.10.

Другое

• Удаление PersistentVolumeClaims, используемых какими-либо подами, теперь предотвращается ^[21] (альфа-версия).
• Опции volumeMode и volumeDevice для PV (PersistentVolume), позволяющие ^[22] напрямую использовать блочные raw-устройства вместо файловой системы (альфа-версия).

Сети

Поддержка IPv6

Реализована ^[23] базовая поддержка IPv6, предоставляющая «все возможности Kubernetes в сети IPv6 вместо IPv4». На данный момент эта реализация находится в альфа-версии и включает в себя:

• поддержку развёртывания кластеров Kubernetes в режиме «только IPv6»;
• поддержку деплоя кластера с IPv6 через kubeadm;
• поддержку K8s control plane и data plane;
• поддержку бэкенда iptables kube-proxy с использованием ip6tables;
• использование сборки CNI 0.6.0 для IPv6-сети у подов;
• поддержку IPv6 в kube-dns через SRV-записи;
• ограничения: из плагинов CNI были проверены только bridge и local-ipam; отсутствие поддержки HostPorts; сетевая маска для пода/кластера должна быть /66 или больше.

Другое

• В kubeadm добавлен ^[24] экспериментальный режим, в котором CoreDNS используется вместо kube-dns. Подробнее о прогрессе проекта CoreDNS мы писали здесь ^[25].
• Режим IPVS в kube-proxy, впервые представленный в K8s 1.8, перешёл в статус беты.

Прочие компоненты и изменения

Планировщик

Механизм освобождения ресурсов кластера (pod preemption) был улучшен благодаря поддержке PodDisruptionBudget ^[26] и nominated pods ^[27]. Кроме того, в планировщик добавлена поддержка нового типа очереди, основанной ^[28] на приоритетах (первыми будут планироваться поды с наивысшим приоритетом).

При использовании ^[29] hostPort ^[30] у подов появилась ^[31] возможность прослушивать один и тот же порт на разных IP-адресах.

Аутентификация и безопасность

Важное новшество от SIG Auth — ClusterRole Aggregation ^[32] для возможности добавлять права (permissions) уже существующим, т.е. встроенным в RBAC, ролям (admin, edit, view).

Также можно отметить, что:

• в правила политики RBAC (PolicyRules) добавлена ^[33] поддержка формата */subresource — например, */scale будет включать в себя replicationcontroller/scale;
• в PodSecurityPolicy ^[34] проведены заметные улучшения, включающие многократный рост производительности ^[35] при использовании большого числа политик в кластере (авторизация теперь происходит только для валидных для пода политик, а не всех политик кластера) и поддержку ^[36] дополнений K8s ^[37].

CLI

Название фичи kubectl diff ^[38] говорит за себя: это новая команда, позволяющая просматривать различия между локально описанным объектом Kubernetes и текущим состоянием реального объекта (в кластере). Текущий статус — альфа-версия.

В kubeadm upgrade apply добавлена опция --etcd-upgrade, выполняющая обновление etcd в подах до версии, которая официально поддерживается целевым релизом Kubernetes (3.1.10 в случае K8s 1.9).

У kubeadm появилась ^[39] поддержка Kubelet Dynamic Configuration, что означает возможность выката конфигураций kubelet на работающий кластер (сама фича впервые появилась ^[40] в прошлой версии Kubernetes и сохраняет статус альфа-версии с перспективой повышения до беты в K8s 1.10).

Windows

• Через kubeadm в кластер теперь можно добавлять ^[41] рабочие узлы с Windows.
• У kubelet появилась ^[42] поддержка указания путей монтирования в формате Windows, а не только абсолютных путей Linux, как это было раньше.

OpenStack

Улучшена интеграция с облачной платформой:

• добавлена поддержка Cinder v3 API и исправлено определение версии Cinder;
• OpenStack LBaaS v2 Provider стал настраиваемым;
• для балансировки нагрузки теперь может использоваться OpenStack Octavia v2 (не только Neutron LBaaS v2);
• расширена поддержка групп безопасности OpenStack.

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

• Валидация сторонних ресурсов, определённых через Custom Resource Definition (CRD), получила статус бета-версии, а также добавлен ^[43] образец CRD-контроллера.
• В hyperkube ^[44] (бинарный файл, включающий в себя все серверные компоненты Kubernetes) добавлен ^[45] cloud-controller-manager.
• Обновление cAdvisor до 0.28.1 добавило поддержку мониторинга containerd.
• AppArmor теперь можно отключить, выставив профиль unconfined.
• При запуске kubelet больше не проверяется зависимость от Docker.
• Формат логов контейнеров в CRI научился разбивать длинные строки на несколько, а в fluentd появилась поддержка логов в формате CRI.

Совместимость

• Поддерживаемая версия etcd — 3.1.10 (в Kubernetes 1.8 была 3.0.17).
• Проверенные версии Docker — от 1.11.2 до 1.13.1 и 17.03.x.
• Версия Go — 1.9.2 (вместо 1.8.3), минимально поддерживаемая — 1.9.1.
• Версия CNI — 0.6.0.

P.S.

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

• «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017 ^[25]»;
• «Kubernetes 1.8: обзор основных новшеств ^[2]»;
• «Docker 17.06 и Kubernetes 1.7: ключевые новшества ^[46]»;
• «Наш опыт с Kubernetes в небольших проектах ^[47]» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
• «Инфраструктура с Kubernetes как доступная услуга ^[48]».

Автор: distol

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