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

48bc2dec061e42928e98c92cbbadf968.png

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

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

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


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

API


Редизайн Event API


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

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


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

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


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

ljiemy7dqprlv0sqa3xend_eqxc.png

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

Admission webhooks


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

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


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

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

Workload API


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

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

Другое


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


Хранилища


Out-of-Tree Volume Plugins (CSI)


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

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

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


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

z8uzjmms4dtd_sau5yrtucar0hm.png

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

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


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

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

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


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

Другое


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


Сети


Поддержка IPv6


Реализована базовая поддержка 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 добавлен экспериментальный режим, в котором CoreDNS используется вместо kube-dns. Подробнее о прогрессе проекта CoreDNS мы писали здесь.
  • Режим IPVS в kube-proxy, впервые представленный в K8s 1.8, перешёл в статус беты.


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


Планировщик


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

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

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


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

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

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


CLI


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

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

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

Windows


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


OpenStack


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

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


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


  • Валидация сторонних ресурсов, определённых через Custom Resource Definition (CRD), получила статус бета-версии, а также добавлен образец CRD-контроллера.
  • В hyperkube (бинарный файл, включающий в себя все серверные компоненты Kubernetes) добавлен 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»;
  • «Kubernetes 1.8: обзор основных новшеств»;
  • «Docker 17.06 и Kubernetes 1.7: ключевые новшества»;
  • «Наш опыт с Kubernetes в небольших проектах» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
  • «Инфраструктура с Kubernetes как доступная услуга».

© Habrahabr.ru