Kubernetes 1.14: обзор основных новшеств +28





Этой ночью состоится очередной релиз Kubernetes — 1.14. По сложившейся для нашего блога традиции, рассказываем о ключевых изменениях в новой версии этого замечательного Open Source-продукта.

Информация, использованная для подготовки этого материала, взята из таблицы Kubernetes enhancements tracking, CHANGELOG-1.14 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP). UPDATE (26 марта): в блоге K8s появился и официальный анонс релиза.

Начнём с важного введения от SIG cluster-lifecycle: динамические отказоустойчивые кластеры Kubernetes (а если выражаться более точно, то self-hosted HA deployments) теперь можно создавать с помощью привычных (в контексте кластеров с одним узлом) команд kubeadm (init и join). Если вкратце, то для этого:

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


Архитектура HA-кластера Kubernetes, созданного с kubeadm

С подробностями о реализации можно ознакомиться в design proposal. Эта фича была по-настоящему долгожданной: альфа-версия ожидалась ещё в K8s 1.9, но появилась только теперь.

API


Команда apply и вообще декларативное управление объектами вынесены из kubectl в apiserver. Сами разработчики кратко поясняют своё решение тем, что kubectl apply — фундаментальная часть работы с конфигурациями в Kubernetes, однако «полна багов и сложно поддаётся исправлениям», в связи с чем эту функциональность необходимо привести к нормальному виду и перенести в control plane. Простые и наглядные примеры существующих сегодня проблем:



Подробности о реализации — в KEP. Текущая готовность — альфа-версия (продвижение до беты запланировано на следующий релиз Kubernetes).

В альфа-версии стала доступной возможность использования схемы OpenAPI v3 для создания и публикации OpenAPI-документации по CustomResources (CR), используемым для валидации (на стороне сервера) ресурсов K8s, определяемых пользователем (CustomResourceDefinition, CRD). Публикация OpenAPI для CRD позволяет клиентам (например, kubectl) выполнять валидацию на своей стороне (в рамках kubectl create и kubectl apply) и выдавать документацию по схеме (kubectl explain). Подробности — в KEP.

Существовавшие ранее логи теперь открываются с флагом O_APPEND (а не O_TRUNC) во избежание потери логов в некоторых ситуациях и для удобства truncate'а логов внешними утилитами для ротации.

Также в контексте Kubernetes API можно отметить, что в PodSandbox и PodSandboxStatus добавлено поле runtime_handler для учёта информации про RuntimeClass в pod'е (подробнее о нём читайте в тексте про релиз Kubernetes 1.12, где этот класс и появился как альфа-версия), а в Admission Webhooks реализована возможность определять, какие версии AdmissionReview они поддерживают. Наконец, в правилах Admission Webhooks теперь можно ограничивать масштабы их применения namespace'ами и рамками кластера.

Хранилища


PersistentLocalVolumes, имевшие статус бета-версии с релиза K8s 1.10, объявлены стабильными (GA): этот feature gate больше не отключается и будет удалён в Kubernetes 1.17.

Возможность использования переменных окружения так называемого Downward API (например, имени pod'а) для названий директорий, монтируемых как subPath, получила развитие — в виде нового поля subPathExpr, с помощью которого теперь и определяется нужное имя директории. Изначально фича появилась в Kubernetes 1.11, но и для 1.14 осталась в статусе альфа-версии.

Как и в прошлый релиз Kubernetes, много значимых изменений представлено для активно развивающегося CSI (Container Storage Interface):

CSI


Стала доступной (в рамках альфа-версии) поддержка изменения размера для CSI-томов. Для её использования потребуется включить feature gate под названием ExpandCSIVolumes, а также наличие поддержки этой операции в конкретном CSI-драйвере.

Ещё одна фича для CSI в альфа-версии — возможность ссылаться напрямую (т.е. без использования PV/PVC) на CSI-томы в рамках спецификации pod'ов. Это снимает ограничение на использование CSI как исключительно удалённых хранилищ данных, открывая для них двери в мир local ephemeral volumes. Для использования (пример из документации) необходимо включить CSIInlineVolume feature gate.

Наметился прогресс и во «внутренностях» Kubernetes, связанных с CSI, которые не так заметны конечным пользователям (системным администраторам)… В настоящий момент разработчики вынуждены поддерживать две версии каждого плагина хранилища: один — «на старый лад», внутри кодовой базы K8s (in-tree), а второй — в рамках нового CSI (подробнее о нём читайте, например, в здесь). Это вызывает понятные неудобства, которые необходимо устранить по мере стабилизации CSI как такового. Просто взять и объявить устаревшими (deprecated) API внутренних (in-tree) плагинов не представляется возможным из-за соответствующей политики Kubernetes.

Всё это привело к тому, что альфа-версии достиг процесс миграции внутреннего кода плагинов, реализуемых как in-tree, в CSI plugins, благодаря чему заботы разработчиков будут сведены к поддержке одной версии их плагинов, а совместимость со старыми API сохранится и их можно будет объявить устаревшими по обычному сценарию. Ожидается, что к следующему релизу Kubernetes (1.15) будет проведена миграция всех плагинов облачных провайдеров, реализация получит статус бета-версии и будет активирована в инсталляциях K8s по умолчанию. Подробности см. в design proposal. Следствием этой миграции также стал отказ от ограничений для томов, определяемых конкретными облачными провайдерами (AWS, Azure, GCE, Cinder).

Кроме того, поддержка блочных устройств с CSI (CSIBlockVolume) преведена в бета-версию.

Узлы / Kubelet


Представлена альфа-версия нового endpoint в Kubelet, предназначенного для отдачи метрик по основным ресурсам. Вообще говоря, если раньше Kubelet получал статистику по использованию контейнеров из cAdvisor, то теперь эти данные поступают из исполняемой среды контейнера через CRI (Container Runtime Interface), однако сохранена и совместимость для работы со старыми версиями Docker. Раньше собранная в Kubelet статистика отдавалась через REST API, а теперь для этого используется endpoint, расположенный по адресу /metrics/resource/v1alpha1. Долгосрочная же стратегия разработчиков заключается в том, чтобы минимизировать набор метрик, предоставляемых Kubelet. Кстати, сами эти метрики теперь называют не «core metrics», а «resource metrics», и описывают как «first-class resources, such as cpu, and memory».

Весьма занятный нюанс: несмотря на явное преимущество в производительности gRPC endpoint в сравнении с разными случаями использования формата Prometheus (результат одного из benchmark'ов см. ниже), авторы предпочли текстовый формат Prometheus из-за явного лидерства этой системы мониторинга в сообществе.

«gRPC не совместим с основными пайплайнами мониторинга. Endpoint же будет полезен только для поставки метрик в Metrics Server или компоненты мониторинга, которые интегрируются напрямую с ним. При использовании кэширования в Metrics Server производительность текстового формата Prometheus достаточно хороша для нас, чтобы предпочесть Prometheus, а не gRPC, учитывая широкую распространённость Prometheus в сообществе. Когда формат OpenMetrics станет более стабильным, мы сможем приблизиться к поизводительности gRPC с помощью формата на основе proto».


Один из сравнительных тестов производительности использования форматов gRPC и Prometheus в новом endpoint'е Kubelet для метрик. Больше графиков и другие подробности можно найти в KEP.

Среди прочих изменений:

  • Kubelet теперь принимает параметр pid=<number> в опциях --system-reserved и --kube-reserved, гарантируя, что указанный PID будет зарезервирован для системы в целом или системных демонов Kubernetes соответственно. Возможность активируется при включённом feature gate под названием SupportNodePidsLimit.
  • Kubelet теперь (единожды) пытается остановить контейнеры в неизвестном состоянии (unknown) перед операциями рестарта и удаления.
  • При использовании PodPresets теперь init-контейнеру добавляется та же информация, что и обычному контейнеру.
  • Kubelet начал использовать usageNanoCores из провайдера статистики CRI, а для узлов и контейнеров в Windows добавлена сетевая статистика.
  • Информация об операционной системе и архитектуре теперь записывается в лейблы kubernetes.io/os и kubernetes.io/arch объектов Node (переведено из беты в GA).
  • Возможность указания конкретной системной группы пользователей для контейнеров в pod'е (RunAsGroup, появилась в K8s 1.11) продвинулась до бета-версии (включена по умолчанию).
  • du и find, используемые в cAdvisor, заменены на Go-реализации.

CLI


В cli-runtime и kubectl добавлен флаг -k для интеграции с kustomize (кстати, его разработка теперь ведётся в отдельном репозитории), т.е. для обработки дополнительных YAML-файлов из специальных директорий kustomization (подробности об их использовании см. в KEP):


Пример простого использования файла kustomization (возможно и более сложное применение kustomize в рамках overlays)

Кроме того:

  • Обновились логотип kubectl и его документация — см. kubectl.docs.kubernetes.io.

  • Добавлена новая команда kubectl create cronjob, название которого говорит за себя.
  • В kubectl logs теперь можно сочетать флаги -f (--follow для стриминга логов) и -l (--selector для label query).
  • kubectl научили копировать файлы, выбираемые с помощью wild card.
  • В команду kubectl wait добавили флаг --all для выбора всех ресурсов в пространстве имён указанного типа ресурсов.
  • Объявлен стабильным механизм плагинов для kubectl.

Другие


Стабильный (GA) статус получили следующие возможности:

  • Поддержка Windows-узлов (включая Windows Server 2019), что подразумевает возможность планирования контейнеров Windows Server в Kubernetes (см. также KEP);
  • ReadinessGate, используемый в спецификации pod'а для определения дополнительных условий, учитываемых в готовности pod'а;
  • Поддержка больших страниц (feature gate под названием HugePages);
  • CustomPodDNS;
  • PriorityClass API, Pod Priority & Preemption.

Прочие изменения, представленные в Kubernetes 1.14:

  • Политика RBAC по умолчанию больше не даёт доступа к API discovery и access-review пользователям без аутентификации (unauthenticated).
  • Официальная поддержка CoreDNS обеспечивается только для Linux, поэтому при использовании kubeadm для его (CoreDNS) развёртывания в кластере узлы должны работать только в Linux (для этого ограничения используются nodeSelectors).
  • Конфигурация CoreDNS по умолчанию теперь использует плагин forward вместо proxy. Кроме того, в CoreDNS добавлена readinessProbe, предотвращающая балансировку нагрузки на соответствующие (не готовые к обслуживанию) pod'ы.
  • В kubeadm, на фазах init или upload-certs, стало возможным загружать сертификаты, требуемые для подключения нового control-plane к секрету kubeadm-certs (используется флаг --experimental-upload-certs).
  • Для Windows-инсталляций появилась альфа-версия поддержки gMSA (Group Managed Service Account) — специальных учётных записей в Active Directory, которые могут использоваться и контейнерами.
  • Для GCE активировали mTLS-шифрование между etcd и kube-apiserver.
  • Обновления в используемом/зависимом программном обеспечении: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, поддержка Docker 18.09 в kubeadm, а минимальной поддерживаемой версией Docker API стала 1.26.

P.S.


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

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (9):

  1. AlexMayerLab
    /#19940282 / +1

    Быстро они))) Docker 18.09 особенно радует)
    etcd внутри кластера боязно, но к этому давно шли)

    • zuzzas
      /#19940328 / +3

      На большинстве способов установки он уже был «внутри» кластера. Используя static manifests в kubelet'е master ноды. Это следующий логический шаг, чтобы отвязаться от необходимости трогать файловую систему.

  2. kvaps
    /#19940394 / +1

    Огонь! Релиз обещает быть очень вкусным на нововведения…

  3. heysharpy
    /#19943358

    Зануда mode ON.

    в новой версии этого замечательного Open Source-продукта.

    Это замечательный Open Source-проект, а не продукт. Продуктом он становится когда появляется саппорт, road map, product life cycle и SLA. L3 саппорт возможен только, если ты контрибьютишь в проект или если ты предлагаешь свой форк проекта, что как бы тупик. Нет L3 — нет возможности предоставить пользователю патчи, значит ты сам просто продвинутый пользователь, но никак не вендор с продуктом. Про остальное и говорить не имеет смысла. Есть over 9000 дистрибутивов кубера, есть огромное количество людей, которые утверждают, что могут саппортить кубер, но это неправда. Они не могут. Они могут установить, настроить, может быть даже придумать костыль. Это не энтерпрайз. Такие дела. Не вводите людей в заблуждение, пожалуйста.

    • shurup
      /#19943522

      Это больше похоже на «хотелось вот такое написать, но не знал, к чему бы…».

      «Продукты» бывают только от вендоров и только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)? Или вы считаете, что сам по себе Kubernetes (не будучи каким-то вендорским проявлением…) в принципе не готов к enterprise, поэтому не «продукт»?

      • heysharpy
        /#19943764

        Это больше похоже на «хотелось вот такое написать, но не знал, к чему бы…».

        Да вы не стесняйтесь, переходите сразу к оскорблениям, чего уж там.
        «Продукты» бывают только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)?

        Эмм, да. Продукт — это только для энтерпраза. В этом смысл слова «продукт». Вендор предлагает заплатить ему деньги за экспертизу, от пресейла и проектирования архитектуры до проактивного сопровождения решения на всем жизненном цикле. Ваши истории успеха очень успешны, но заказчики настолько большие, богатые и компетентные, что это скорее аргумент использовать вендорские решения, т.к. далеко не каждый ООО «Вектор» может себе позволить тратить существенные деньги и время на внутреннюю экспертизу, ведь сделать Kubernetes правильно — это непросто, кому как не вам это знать. Однако, каждый сможет получить преимущества использование Kubernetes в бизнесе.
        https://en.wikipedia.org/wiki/Product_(business)

        Перед вами живой пример — компания «Флант», которая обслуживает upstream-дистрибутив Kubernetes для production у многих компаний. Что не так?

        Я озвучил один простой тезис — upstream это не продукт, это проект. Я не знаю, что с этим утверждением не так. И почему это так вас задевает. У меня встречный вопрос, почему истории успеха сферические в вакууме, а не ваши?

        • shurup
          /#19943944

          Цикл историй успеха своих клиентов мы уже готовим. Скоро вы их увидите здесь же в блоге.

        • Singaporian
          /#19946822

          На основе какого источника основывается ваша терминология? Хочу почитать определение продукта и проекта.

  4. heysharpy
    /#19947102

    На основе какого источника основывается ваша терминология? Хочу почитать определение продукта и проекта.

    А это не моя терминология, это как раз первоисточники. Прошу ознакомиться.
    https://opensource.com/resources/what-open-source
    Есть опенсорс проекты, продукты и инициативы.

    Вот, например, Kubernetes, который вы свободно скачиваете и устанавливаете — это проект. Вы никому ничего не должны. Вам, впрочем, тоже никто ничего не должен и не несет никаких обязательств перед вами.
    Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.

    kubernetes.io/docs/concepts/overview/what-is-kubernetes

    Но есть коммерческие предложения, например от того же Google — Kubernetes Engine. Это продукт.
    Есть цена, есть понимание что покупатель получит за эту цену, есть права и обязанности сторон.
    cloud.google.com/kubernetes-engine
    cloud.google.com/kubernetes-engine/pricing

    И есть инициативы. Например.
    en.wikipedia.org/wiki/Open_Source_Initiative