Главная » Хабрахабр » Kubernetes 1.14: обзор основных новшеств

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

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

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

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

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


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

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

API

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

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

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

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

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

Хранилища

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

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

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

CSI

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

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

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

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

Кроме того, поддержка блочных устройств с 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».

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

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


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

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

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

Другие

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

  • 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.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Слушаем SID-музыку через OPL3 на современных ПК

Кто-то может подумает, что это будет что-то ужасное, а оказывается если сделать простой маппер, то можно получить весьма хорошее звучание, как это сделали несколько разработчиков в программе LLSID ещё в далеком 2007 году. Наверное не все любители чиптюн музыки знают, ...

Пользователь в Docker

В новой статье он рассказывает, как создать пользователей в Docker. Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile. Это кажется очень удобно, ведь ...