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

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

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

GA для kubeadm

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

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

стабильный консольный интерфейс, который следует политике Kubernetes по устареванию: команды и флаги, представленные в GA-релизе, должны поддерживаться не менее года после того, как объявлены устаревшими;
стабильная реализация «под капотом» благодаря тому, что кластер создаётся методами, которые не будут меняться в ближайшем времени: control plane запускается как множество статичных pod’ов, для kubeadm join используются bootstrap-токены, а для настройки kubelet задействован ComponentConfig;
схема конфигураций с новым 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 пройти небольшой онлайн-опрос, в котором можно высказать свои пожелания по использованию и развитию проекта.

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

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

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

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

Хранилища

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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=

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

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

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

CLI

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

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

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

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

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

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

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

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

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

В SIG Azure реализовали дополнительную поддержку для Azure Disk (Ultra SSD, Standard SSD и Premium Azure Files) и продвинули Cross resource group nodes до бета-версии. Кроме того, в CNI-плагинах для Windows появилась возможность настройки 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.

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