company_banner

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



    Сегодня 27 сентября, а это означает, что в рабочее время (по американскому часовому поясу) мы можем ожидать очередной релиз Kubernetes — 1.12 (впрочем, его официальный анонс иногда задерживается). В общем, самое время продолжить славную традицию и рассказать о наиболее значимых изменениях, что мы и сделаем, руководствуясь публичной информацией от проекта: таблицей Kubernetes features tracking, CHANGELOG-1.12, многочисленными issues, pull requests и design proposals. Итак, что нового в K8s 1.12?

    Хранилища


    Если выделять одну вещь, которая чаще любых других упоминается среди всех issues, связанных с релизом Kubernetes 1.12, пожалуй, ей станет Container Storage Interface (CSI), о котором мы уже писали на днях. По этой причине начнём с изменений в поддержке хранилищ.

    Плагины CSI как таковые сохранили статус бета-версии и ожидают признания стабильными к следующему релизу Kubernetes (1.13). Что же нового тогда в поддержке CSI?

    В феврале этого года в самой спецификации CSI началась работа над концепцией топологии. Если вкратце, топология — это информация о сегментировании кластеров (например, по «стойкам» для инсталляций on-premise или же по «регионам» и «зонам» для облачных окружений), которую необходимо знать и учитывать системам оркестровки. Зачем? Тома, выделяемые провайдерами хранилищ, вовсе не обязательно будут одинаково доступными во всём кластере, а поэтому знания о топологии необходимы, чтобы эффективно планировать ресурсы и принимать решения по provisioning'у.

    Следствием появления топологий в CSI (приняты в спецификацию 1 июня) стала их поддержка в Kubernetes 1.12:


    Но на этом связанные с CSI обновления не заканчиваются. Другое важное нововведение в релизе Kubernetes 1.12 — поддержка снапшотов для CSI (пока в статусе альфа-версии). Снапшоты для томов как таковые появились ещё в релизе K8s 1.8. Основную реализацию, включающую в себя контроллер и provisioner (два отдельных бинарника), было решено вынести во внешний репозиторий. С тех пор появилась поддержка для томов GCE PD, AWS EBS, OpenStack Cinder, GlusterFS и Kubernetes hostPath.

    Новый же design proposal призван «продолжить эту инициативу, добавив поддержку снапшотов для CSI Volume Drivers» (поддержка снапшотов в спецификации CSI описана здесь). Поскольку в Kubernetes придерживаются принципа включения в core API минимального набора возможностей, эта реализация (как и для снапшотов в Volume Snapshot Controller) использует CRD (CustomResourceDefinitions).

    И ещё пара новых фич для CSI-драйверов:

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

    Представленный в прошлом релизе Kubernetes механизм динамического лимитирования томов на узлах продвинулся с альфа-версии до беты, получив… как вы догадались, поддержку CSI, а также Azure.

    Наконец, фича Mount namespace propagation, позволяющая монтировать том как rshared (чтобы все примонтированные каталоги контейнера были видны на хосте) и имевшая статус бета-версии в релизе K8s 1.10, объявлена стабильной.

    Планировщик


    В планировщике Kubernetes 1.12 улучшают производительность благодаря альфа-версии механизма ограничения поиска в кластере узлов, подходящих для планирования пода (feasible nodes). Если раньше для каждой попытки планирования каждого пода kube-scheduler проверял доступность всех узлов и передавал их для оценки, то теперь планировщик будет находить лишь некоторое их количество, после чего останавливать свою работу. При этом в механизме предусмотрен обязательный отбор узлов из разных регионов и зон, а также необходимость просматривать разные узлы в разных циклах планирования (не отбирать первые 100 узлов каждый запуск). Решение о реализации этого механизма приняли, руководствуясь результатами анализа данных по производительности планировщика (если 90-й перцентиль показывал время в 30 мс для пода, то 99-й — уже 60 мс).

    Кроме того, дозрели до бета-версии следующие возможности планировщика:

    • Taint node by Condition, появившаяся ещё в K8s 1.8 и позволяющая помечать узел определённым статусом (для дальнейших действий) при наступлении определённых событий: теперь контроллер жизненного цикла узла автоматически создаёт taints, а планировщик их проверяет (вместо условий);
    • планирование подов в DaemonSet с помощью kube-scheduler (вместо контроллера DaemonSet): его тоже сделали активным по умолчанию;
    • указание класса приоритета в ResourceQuota.

    Узлы кластера


    Интересным нововведением стало появление (в статусе альфа-версии) RuntimeClass — нового ресурса уровня кластера, предназначенного для обслуживания параметров исполняемой среды контейнеров (container runtime). RuntimeClasses назначаются на поды через одноимённое поле в PodSpec и реализуют поддержку использования множества исполняемых сред в рамках кластера или узла. Зачем?

    «Интерес к использованию разных исполняемых сред в кластере растёт. На данный момент главным мотиватором для этого являются песочницы (sandboxes) и стремление контейнеров Kata и gVisor интегрироваться с Kubernetes. В будущем также потребуют поддержки другие runtime-модели вроде Windows-контейнеров или даже удалённых исполняемых сред. RuntimeClass предлагает способ выбирать между разными исполняемыми средами, настроенными в кластере, и изменять их свойства (и кластером, и пользователем)».

    Для выбора между предопределёнными конфигурациями в CRI (Container Runtime Interface) передаётся RuntimeHandler, что призвано заменить нынешние аннотации пода:



    А конфигурация в containerd для kata-runtime выглядит примерно так:

    [plugins.cri.containerd.kata-runtime]
        runtime_type = "io.containerd.runtime.v1.linux"
        runtime_engine = "/opt/kata/bin/kata-runtime"
        runtime_root = ""

    Критерием RuntimeClass для альфа-версии является успешная валидация по тесту CRI.

    Кроме того, до статуса бета-версии выросли механизм регистрации локальных плагинов (включая CSI) в Kubelet и shareProcessNamespace (фича стала включённой по умолчанию).

    Сети


    Главная новость в сетевой части Kubernetes — альфа-версия поддержки SCTP (Stream Control Transmission Protocol). Получив поддержку в Pod, Service, Endpoint и NetworkPolicy, этот телекоммуникационный протокол пополнил ряды TCP и UDP. С новой фичей «приложения, требующие SCTP в качестве L4-протокола для своих интерфейсов, можно будет проще деплоить на Kubernetes-кластерах; например, они смогут использовать service discovery на базе kube-dns, а их взаимодействие будет контролироваться через NetworkPolicy». Подробности о реализации доступны в этом документе.

    Стабильного статуса также достигли две сетевые возможности, представленные в K8s 1.8: поддержка политик для исходящего трафика EgressRules в NetworkPolicy API и применение правил по CIDR источника/получателя через ipBlockRule.

    Масштабирование


    Улучшения в Horizontal Pod Autoscaler включают в себя:


    Не стоит на месте и вертикальное масштабирование подов, которому до достижения бета-версии не хватало тестирования пользователями. Авторы сочли его достаточным для релиза K8s 1.12 и напоминают, что эта возможность является скорее дополнением к Kubernetes (не входит в ядро системы). Вся разработка ведётся в отдельном репозитории, бета-релиз в котором будет приурочен к релизу Kubernetes.


    Схема работы Vertical Pod Autoscaler (VPA) в Kubernetes

    Наконец, в K8s 1.12 включены (в виде альфа-версии) результаты работы над «упрощением инсталляции с помощью ComponentConfig» (в рамках sig-cluster-lifecycle), продолжающейся уже почти два года. К сожалению, по непонятной причине (простому недосмотру?), доступ к документу design proposal с подробностями закрыт для анонимных пользователей.

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


    API


    Две новые возможности реализованы в группе api-machinery:

    • параметр dry-run для apiserver (альфа-версия), который производит имитацию валидации и обработки запросов;
    • Resource Quota API (сразу бета-версия), определяющий ограниченные по умолчанию ресурсы (вместо текущего поведения, когда потребление ресурсов не ограничено, если квота не задана).

    Azure


    Объявлена стабильной:


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


    Kubectl


    • Реализована альфа-версия обновлённого механизма плагинов, что позволяет как добавлять новые команды, так и переписывать уже существующие подкоманды любого уровня вложенности. Он сделан похожим на Git и просматривает исполняемые файлы, начинающиеся с kubectl-, в $PATH пользователя. Подробнее см. в design proposal.
    • Реализована бета-версия идеи по выделению пакета pkg/kubectl/genericclioptions из kubectl в самостоятельный репозиторий.
    • Объявлена стабильной функция вывода на стороне сервера (server-side printing).

    Прочие


    • Представлена альфа-версия нового механизма TTL after finish, предназначенного для ограничения времени жизни закончивших выполняться Jobs и Pods. По истечении заданного TTL объекты будут автоматически вычищены без необходимости в пользовательском вмешательстве.
    • Объявлена стабильной генерация в Kubelet приватного ключа и CSR (TLS Bootstrap) для подписи сертификата на уровне кластера.
    • Перешла в статус бета-версии ротация серверного TLS-сертификата в Kubelet.

    P.S.


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

    • +27
    • 8.1k
    • 6
    Флант
    431.30
    Специалисты по DevOps и Kubernetes
    Share post

    Comments 6

      0
      Здравствуйте, подскажите пожалуйста, сейчас вы подам подключаете локальные папки? (речь про github.com/kubernetes/features/issues/121)
        0

        Мы очень давно и активно используем local storage, но до сих пор руки не дошли до local volume provisioner'а.

        0
        И еще вопрос по Helm.
        — показывает ли Helm ошибку при падении выката/деплоя?
        — откатывает ли Helm назад деплой при падении деплоя/выкатки?
          +2

          По поводу ошибок и логирования


          Helm не дожидается, когда приложение начинает функционировать, все ресурсы переходят в состояние Running: при успешном выполнении install или upgrade, т.е. имея release в состоянии success, helm не гарантирует, что ресурсы приложения успешно выкатились (к примеру, нет ошибок типа ImagePullError).


          На текущий момент состояние success говорит о том, что манифесты применились успешно. Если опустить множество деталей, то можно провести аналогию с командой kubectl apply.


          Что касается логирования, то сейчас в helm оно "как-то" поддерживается для Hook-ов. Hook — механизм helm, который позволяет выполнять операции, привязываясь к различным этапам жизненного цикла релиза. К примеру, можно сделать дамп базы перед удалением или накатить фикстуры при инсталяции. Подробнее про них можно почитать здесь.


          "Как-то" нас не устраивает, поэтому мы используем собственное решение при выкате приложений с dapp и параллельно пытаемся добавить этот функционал в helm (почитать можно в соответствующем issue).


          Что касается отладки, то состояние всех ресурсов релиза можно посмотреть, выполнив команду helm status, а далее уже использовать kubectl logs.


          Чего-то существенного от ошибок и сопутствующего вывода helm ждать не стоит.


          Rollback


          Helm позволяет откатываться до определённой ревизии релиза. Список всех ревизий можно посмотреть, выполнив команду helm history, а откатить версию командой helm rollback.

            0
            Helm не дожидается, когда приложение начинает функционировать, все ресурсы переходят в состояние Running: при успешном выполнении install или upgrade, т.е. имея release в состоянии success, helm не гарантирует, что ресурсы приложения успешно выкатились (к примеру, нет ошибок типа ImagePullError).


            Этим параметром регулируется чего ждать, а чего не ждать.
            Configure Liveness and Readiness Probes
              +1

              Да, по задумке helm должен следить за выполнением соответствующих probe при использовании опции --wait:


                    --wait                     if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout

              Но должным образом сейчас это не работает. Поддерживаются не все ресурсы и не все версии API. Да и по самой реализации есть вопросы.

        Only users with full accounts can post comments. Log in, please.