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

В начале этой недели состоялся ^[1] очередной релиз Kubernetes, который окрестили «ангельским», — 1.13 ^[2]. Такое название связано с числом 113, которое считается ^[3] «ангельским» и, со слов разработчиков Kubernetes, символизирует «новые начинания, трансформацию и конец одной главы перед открытием новых». Не вдаваясь в дальнейший анализ символизма происходящего, по уже сложившейся для нашего блога традиции, мы в седьмой раз расскажем о ключевых изменениях в новой версии Kubernetes, что призваны порадовать DevOps-/SRE-инженеров, работающих с этим продуктом.

В качестве источников информации мы оперировали данными из таблицы Kubernetes enhancements tracking ^[4], CHANGELOG-1.13 ^[5] и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP).

GA для kubeadm

Одним из главных событий релиза Kubernetes 1.13 стало объявление стабильного статуса (General Availability, GA) для консольной утилиты kubeadm. В блоге K8s этому даже посвятили отдельную публикацию ^[6]. Как многие знают, kubeadm — инструмент для создания кластеров Kubernetes согласно лучшим практикам проекта, а также их дальнейшего минимального сопровождения. Отличительная особенность в том, что разработчики стремятся сохранить его компактным и независимым от поставщика/инфраструктуры, не включая в него решение таких вопросов, как provisioning инфраструктуры, сторонние сетевые решения, дополнения (мониторинг, логирование и т.п.), специфичные интеграции с облачными провайдерами.

Статус GA ознаменовал зрелость kubeadm в следующих вопросах:

• стабильный консольный интерфейс, который следует политике Kubernetes по устареванию: команды и флаги, представленные в GA-релизе, должны поддерживаться не менее года после того, как объявлены устаревшими;
• стабильная реализация «под капотом» благодаря тому, что кластер создаётся методами, которые не будут меняться в ближайшем времени: control plane запускается как множество статичных pod'ов, для kubeadm join используются bootstrap-токены ^[7], а для настройки kubelet задействован ComponentConfig ^[8];
• схема конфигураций с новым API (v1beta1), которая позволяет декларативно описать практически все компоненты кластеров (становится возможным GitOps для создаваемых с kubeadm кластеров), — обновление до версии v1 запланировано с никакими или минимальными изменениями;
• так называемые phases (или интерфейс toolbox) в kubeadm (kubeadm init phase), позволяющие выбирать, какие инициализирующие процедуры будут выполняться;
• команда kubeadm upgrade гарантирует обновления кластера между релизами 1.10.x, 1.11.x, 1.12.x и 1.13.x (обновляет etcd, API Server, Controller Manager и Scheduler);
• безопасная инсталляция etcd по умолчанию (повсеместно использует TLS) с возможностью расширения до HA-кластера при необходимости.

Также можно отметить, что kubeadm теперь корректно распознает Docker 18.09.0 и его более новые версии. Наконец, разработчики просят пользователей kubeadm пройти небольшой онлайн-опрос ^[9], в котором можно высказать свои пожелания по использованию и развитию проекта.

CoreDNS по умолчанию

CoreDNS, получивший стабильный статус в релизе Kubernetes 1.11 ^[10], пошёл ещё дальше и стал ^[11] DNS-сервером по умолчанию в K8s (вместо использовавшегося до сих пор kube-dns). Планировалось, что это произойдёт ещё в 1.12, однако разработчики столкнулись с необходимостью проведения дополнительных оптимизаций в масштабируемости и потреблении памяти, которые были завершены только к нынешнему релизу.

Поддержка kube-dns сохранится «как минимум на один следующий релиз», но разработчики говорят о необходимости начинать миграцию на актуальное решение уже сейчас.

Из связанных с темой CoreDNS изменений в Kubernetes 1.13 можно также отметить ^[12] появление плагина NodeLocal DNS Cache ^[13], призванного улучшить производительность работы DNS. Улучшение достигается благодаря запуску на узлах кластера агента для DNS-кэша, к которому будут напрямую обращаться pod'ы этого узла. По умолчанию функция отключена, а для её активации необходимо выставить KUBE_ENABLE_NODELOCAL_DNS=true.

Хранилища

Большое внимание в последних релизах Kubernetes уделяется работе с Container Storage Interface (CSI), что началась с альфа-версии CSI в K8s 1.9 ^[14], продолжилась бета-версией в 1.10 ^[15]… Впрочем, мы уже писали ^[16] о нём и не раз ^[17]. В K8s 1.13 достигнута новая значимая веха: поддержка CSI объявлена стабильной (GA).

(Схема из статьи «Понимаем Container Storage Interface ^[16]»)

Вместе с этим, появилась поддержка спецификации CSI версии v1.0.0 и признана устаревшей поддержка старых версий стандарта (0.3 и более ранних). Это означает, что старым драйверам CSI для работы в Kubernetes 1.15 и старших версий потребуется обновление до CSI 1.0 (и перемещение в новый каталог регистрации плагинов Kubelet). К слову, из самих драйверов стоит отметить появление ^[18] альфа-версии интерфейса CSI для управления жизненным циклом томов AWS EBS (Elastic Block Store).

Новое дополнение ^[19] в addon manager теперь производит автоматическую установку CRD от CSI, если активирован хотя бы один из двух feature gates: CSIDriverRegistry и CSINodeInfo. Оно имеет статус альфа-версии, а по сути является лишь временным решением задачи, подробно описанной как механизм установки CRD ^[20].

Стало стабильным планирование томов с учётом топологии (Topology Aware Volume Scheduling ^[21]), про которое мы рассказывали в контексте релиза Kubernetes 1.10 ^[15]. Если вкратце, то с ним планировщик в своей работе учитывает ограничения топологии тома pod'а (например, его зону и узел).

Представленная ещё в Kubernetes 1.9 ^[14] возможность ^[22] использовать блочные raw-устройства (не сетевые) как Persistent Volumes переведена ^[23] в бета-версию и отныне включена по умолчанию.

Завершим тему хранилищ тем, что поддержка GCERegionalPersistentDisk объявлена ^[24] стабильной.

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

Представлена альфа-версия поддержки ^[25] сторонних плагинов для мониторинга устройств. Идея этой инициативы заключается в том, чтобы вынести из Kubelet специфичные для устройств знания вовне (out-of-tree). Администраторы кластеров получат метрики, сообщаемые плагинами устройств на уровне контейнера, а производители — возможность создавать эти метрики без необходимости вносить изменения в ядро Kubernetes. С подробностями о реализации можно ознакомиться в предложении, получившем название Kubelet Metadata API ^[26].

Объявлен ^[27] стабильным Kubelet Plugin Watcher ^[28] (его же называли Kubelet Device Plugin Registration), позволяющий плагинам уровня узла (плагины устройств, CSI и CNI) сообщать о себе Kubelet и взаимодействовать с ним.

Новая возможность в статусе альфа-версии — NodeLease ^[29]. Если раньше «пульс» (heartbeat) узла определялся по NodeStatus, то с новой фичей у каждого узла появляется связанный с ним объект Lease (в пространстве имён kube-node-lease), который периодически обновляется узлом. «Пульс» же теперь задают оба параметра: и прежний NodeStatus, который сообщается мастеру только в случае изменений либо по фиксированному таймауту (по умолчанию это раз в минуту), и новый объект (он обновляется часто). Поскольку этот объект совсем небольшой, это значительно улучшит масштабируемость и производительность. Авторы взялись за создание нового «пульса» после тестирования кластеров с размером более 2000 узлов, которые во время своей работы могли упираться в лимиты etcd, — подробнее см. в KEP-0009 ^[30].

type Lease struct {
  metav1.TypeMeta `json:",inline"`
  // Standard object's metadata.
  // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
  // +optional
  ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"`

  // Specification of the Lease.
  // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
  // +optional
  Spec LeaseSpec `json:"spec,omitempty"`
}

type LeaseSpec struct {
  HolderIdentity       string           `json:"holderIdentity"`
  LeaseDurationSeconds int32            `json:"leaseDurationSeconds"`
  AcquireTime          metav1.MicroTime `json:"acquireTime"`
  RenewTime            metav1.MicroTime `json:"renewTime"`
  LeaseTransitions     int32            `json:"leaseTransitions"`
}

(Компактная спецификация нового объекта для представления «пульса» узла — Lease — идентична LeaderElectionRecord ^[31])

Безопасность

Альфа-версия Dynamic Audit Control ^[32] следует идеям Dynamic Admission Control и обеспечивает динамическую конфигурацию продвинутых возможностей аудита — для этого теперь можно зарегистрировать (динамически) webhook, который будет получать поток событий. Потребность в этой фиче объясняется тем, что аудит в Kubernetes предлагает очень мощные возможности, однако они сложны в настройке, а каждое изменение конфигурации до сих пор требовало перезагрузки apiserver.

Шифрование данных в etcd (см. официальную документацию ^[33]) переведено ^[34] из экспериментального статуса в бета-версию.

kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
resources:
  - resources:
    - secrets
    providers:
    - identity: {}
    - aesgcm:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - secretbox:
        keys:
        - name: key1
          secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=

(Пример конфигурации с зашифрованными данными — взят из документации ^[35].)

Среди менее значимых новшеств в этой категории:

• Теперь apiserver можно настроить ^[36] на отказ от запросов, которые не могут попасть в audit-логи.
• Объектам PodSecurityPolicy добавили ^[37] поддержку правила MayRunAs для опций fsGroup и supplementalGroups, позволяющего определять диапазон разрешённых идентификаторов групп (GID) для подов/контейнеров без принудительного установления GID по умолчанию. Кроме того, с PodSecurityPolicy теперь в спецификации pod'ов возможна ^[38] стратегия RunAsGroup, т.е. можно контролировать основной GID для контейнеров.
• Для kube-scheduler заменили ^[39] прежний небезопасный порт (10251) на новый безопасный (10259) и включили его по умолчанию. Если никаких дополнительных флагов не указано, то при загрузке для него в памяти создаются самоподписанные сертификаты.

CLI

Команда kubectl diff, показывающая ^[40] разницу между локальной конфигурацией и актуальным описанием работающего объекта (работает и рекурсивно для каталогов с конфигурациями), получила статус бета-версии.

Фактически diff «предсказывает» изменения, которые будут внесены с выполнением команды kubectl apply, и для этого используется другая новая возможность — APIServer DryRun ^[41]. Её суть — холостой запуск — должна быть ясна из названия, а более подробное описание доступно в документации Kubernetes ^[42]. К слову, в релизе 1.13 функцию DryRun тоже «повысили» до бета-версии и включили по умолчанию.

И ещё одно продвижение до бета-версии в консольном мире Kubernetes затронуло новый механизм плагинов ^[43]. Попутно в нём исправили ^[44] порядок вывода плагинов (kubectl plugin list), убрав оттуда дополнительную сортировку.

Кроме того, в kubectl describe node добавили ^[45] вывод используемых ресурсов ephemeral-storage ^[46], а в kubectl describe pod — томов типа projected ^[47].

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

Функция планировщика Taint Based Eviction ^[48] переведена в статус бета-версии и включена по умолчанию после долгого затишья ^[49] в разработке. Её предназначение — автоматическое добавление taints ^[50] на узлы (посредством NodeController или kubelet) при наступлении определённых условий, таких как, например, node.kubernetes.io/not-ready, что соответствует значению NodeCondition в Ready=False.

Аннотация критически важных для работы кластера pod'ов — critical-pod — объявлена ^[51] устаревшей. Вместо неё предлагается использовать приоритеты ^[52] (в бета-версии с Kubernetes 1.11).

Для AWS впервые (в рамках альфа-версий) стали доступны:

• интеграция ^[53] для AWS ALB (Application Load Balancer) с ресурсами Kubernetes Ingress — aws-alb-ingress-controller ^[54] (проект был изначально создан компаниями Ticketmaster и CoreOS для миграции первой в облако AWS);
• внешний CCM ^[55] (Cloud Controller Manager) для AWS — cloud-provider-aws ^[56], — который отвечает за запуск контроллеров со специфичной для облачного провайдера (AWS) функциональностью.

В SIG Azure реализовали дополнительную поддержку для Azure Disk (Ultra SSD, Standard SSD и Premium Azure Files) и продвинули Cross resource group nodes ^[57] до бета-версии. Кроме того, в CNI-плагинах для Windows появилась ^[58] возможность настройки DNS в контейнере.

Совместимость

• Версия etcd — 3.2.24 (не изменилась с Kubernetes 1.12).
• Проверенные версии Docker — 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (тоже не изменились).
• Версия Go — 1.11.2, совпадает с минимально поддерживаемой.
• Версия CNI — 0.6.0.
• Версия CSI — 1.0.0.
• Версия CoreDNS — 1.2.6.

P.S.

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

• «Понимаем Container Storage Interface (в Kubernetes и не только) ^[16]»;
• «Kubernetes 1.12: обзор основных новшеств ^[59]»;
• «Kubernetes 1.11: обзор основных новшеств ^[10]»;
• «Kubernetes 1.10: обзор основных новшеств ^[15]»;
• «Kubernetes 1.9: обзор основных новшеств ^[14]».

Автор: distol

Источник ^[60]