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



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



    В деталях всё это описано в 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 — альфа-версия.

    Запуск 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.


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

    • +33
    • 8,4k
    • 9
    Флант 188,13
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией
    Комментарии 9
    • 0
      > Очередной релиз системы Kubernetes, 1.9, должен случиться на этой неделе

      Ну вы как-то спешите.
      • 0
        github.com/kubernetes/features/blob/master/release-1.9/release-1.9.md
        Wed Dec 13: v1.9.0
        Thu Dec 14: v1.10.0-alpha.1
        • 0
          Почему тогда новости о релизе нет нигде (даже блога K8s), кроме Хабра?
          • 0
            Потому что его задерживают — предположу, что на день или на два; такое уже случалось. А по ссылке из комментария выше (она указана и в статье) — официальный план по датам от разработчиков.
            • 0
              Я просто говорю о преждевременности этой новости. Со стороны это выглядит так, будто вы изобрели машину времени. :)
              • 0
                Не мы одни ;-)

                P.S. Если в былые времена, в контексте по-настоящему массовых проектов (условно — популярных Linux-дистрибутивов), такие анонсы на популярных веб-ресурсах негативно сказывались на распространении их образов по зеркалам, то… здесь всё-таки не тот случай.
      • +3
        Немного похвастаюсь — товарищи, которые делают поддержку IPv6, используют для тестирования kubeadm-dind-cluster — один из проектов, над которыми я работаю. В отличие от minikube эта штука умеет запускать многонодовые кластеры и собирать Kubernetes с исходников, помимо других полезных свойств.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое