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

Этой ночью состоится очередной релиз 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.

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

• «Kubernetes 1.13: обзор основных новшеств»;
• «Kubernetes 1.12: обзор основных новшеств»;
• «Kubernetes 1.11: обзор основных новшеств»;
• «Kubernetes 1.10: обзор основных новшеств».

Автор: Dmitry Stolyarov

Источник