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

в 7:14, , рубрики: devops, kubernetes, open source, Блог компании Флант

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

Очередной релиз системы 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:

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

В деталях всё это описано в 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, обобщены в документации проекта.

Другое

  • В состояние StatefulSetDaemonSet) добавлена поддержка условий, что делает их совместимыми с другими контроллерами категории 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:

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

Разъяснения по этой схеме и подробности о проекте в целом опубликованы в этом документе. Статус реализации в 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.

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

Автор: distol

Источник

Поделиться

* - обязательные к заполнению поля