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

В конце марта состоялся релиз Kubernetes 1.10. Поддерживая нашу традицию рассказывать подробности о наиболее значимых изменениях в очередном релизе Kubernetes, публикуем этот обзор, подготовленный на основе CHANGELOG-1.10, а также многочисленных issues, pull requests и design proposals. Итак, что же нового приносит K8s 1.10?

Хранилища

Mount propagation — возможность контейнеров подключать тома как rslave, чтобы примонтированные каталоги хоста были видны внутри контейнера (значение HostToContainer), или как rshared, чтобы примонтированные каталоги контейнера были видны на хосте (значение Bidirectional). Статус — бета-версия (документация на сайте). Не поддерживается в Windows.

Добавлена возможность создания локальных постоянных хранилищ (Local Persistent Storage), т.е. PersistentVolumes (PVs) теперь могут быть не только сетевыми томами, но и основываться на локально подключённых дисках. Нововведение преследует две цели: а) улучшить производительность (у локальных SSD скорость лучше, чем у сетевых дисков), б) обеспечить возможность использования более дешёвых хранилищ на железных (bare metal) инсталляциях Kubernetes. Эти работы введутся вместе с созданием Ephemeral Local Storage, ограничения/лимиты в котором (впервые представленные в K8s 1.8) также получили улучшения в очередном релизе — объявлены бета-версией и по умолчанию теперь включены.

Стало доступным (в бета-версии) «планирование томов с учётом топологии» (Topology Aware Volume Scheduling), идея которого сводится к тому, что стандартный планировщик Kubernetes знает (и учитывает) ограничения топологии томов, а в процессе привязки PersistentVolumeClaims (PVCs) к PVs учитываются решения планировщика. Реализовано это таким образом, что под теперь может запрашивать PVs, которые должны быть совместимы с другими его ограничениями: требованиями к ресурсам, политиками affinity/anti-affinity. При этом планирование подов, не использующих PVs с ограничениями, должно происходить с прежней производительностью. Подробности — в design-proposals.

Среди прочих улучшений в поддержке томов / файловых систем:

• улучшения в Ceph RBD с возможностью использования клиента rbd-nbd (на основе популярной библиотеки librbd) в pkg/volume/rbd;
• поддержка монтирования Ceph FS через FUSE;
• в плагине для AWS EBS добавлена поддержка блочных томов и volumeMode, а также поддержка блочных томов появилась в плагине GCE PD;
• возможность изменения размера тома даже в тех случаях, когда он примонтирован.

Наконец, были добавлены (и объявлены стабильными) дополнительные метрики, говорящие о внутреннем состоянии подсистемы хранения в Kubernetes и предназначенные для отладки, а также получения расширенного представления о состоянии кластера. Например, теперь для каждого тома (по volume_plugin) можно узнать общее время на операции mount/umount и attach/detach, общее время privision'а и удаления, а также количество томов в ActualStateofWorld и DesiredStateOfWorld, bound/unbound PVCs и PVs, количество используемых подами PVCs и др. Подробнее — см. документацию.

Kubelet, узлы и управление ими

Kubelet получил возможность настройки через версионируемый конфигурационный файл (вместо традиционного способа с флагами в командной строке), имеющий структуру KubeletConfiguration. Чтобы Kubelet подхватил конфиг, необходимо запускать его с флагом --config (подробности см. в документации). Такой подход называется рекомендуемым, поскольку упрощает разворачивание узлов и управление конфигурациями. Это стало возможным благодаря появлению группы API под названием kubelet.config.k8s.io, которая для релиза Kubernetes 1.10 имеет статус бета-версии. Пример конфигурационного файла для Kubelet:

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
evictionHard:
    memory.available:  "200Mi"

С помощью новой опции в спецификации пода, shareProcessNamespace в PodSpec, контейнеры теперь могут использовать общее для пода пространство имён для процессов (PID namespace). Ранее этой возможности не было из-за отсутствия необходимой поддержки в Docker, что привело к появлению дополнительного API, который с тех пор используется некоторыми образами контейнеров… Теперь всё унифицировали, сохранив обратную совместимость. Результат реализации — поддержка трёх режимов разделения пространств имён PID в Container Runtime Interface (CRI): для каждого контейнера (т.е. свой namespace у каждого контейнера), для пода (общий namespace для контейнеров пода), для узла. Статус готовности — альфа.

Другое значимое изменение в CRI — появление поддержки Windows Container Configuration. До сих пор в CRI можно было конфигурировать только Linux-контейнеры, однако в спецификации исполняемой среды OCI (Open Container Initiative, Runtime Specification) описаны и особенности других платформ — в частности, Windows. Теперь в CRI поддерживаются ограничения по ресурсам памяти и процессора для Windows-контейнеров (альфа-версия).

Кроме того, статуса бета-версии достигли три разработки Resource Management Working Group:

1. CPU Manager (назначение подам конкретных ядер процессора — подробнее о нём писали в статье про K8s 1.8);
2. Huge Pages (возможность использования подами 2Mi и 1Gi Huge Pages, что актуально для приложений, потребляющих большие объёмы памяти);
3. Device Plugin (фреймворк для вендоров, позволяющий объявлять в kubelet ресурсы: например, от GPU, NIC, FPGA, InfiniBand и т.п. — без необходимости модифицировать основной код Kubernetes).

Количество процессов, запущенных в поде, теперь можно ограничивать с помощью параметра --pod-max-pids для консольной команды kubelet. Реализация имеет статус альфа-версии и требует включения фичи SupportPodPidsLimit.

Благодаря тому, что в containerd 1.1 появилась родная поддержка CRI v1alpha2, в Kubernetes 1.10 с containerd 1.1 можно работать напрямую, без необходимости в «посреднике» cri-containerd (подробнее мы о нём писали в конце этой статьи). В CRI-O тоже обновили версию CRI до v1alpha2, а в сам CRI (Container Runtime Interface) добавили поддержку указания GID контейнера в LinuxSandboxSecurityContext и в LinuxContainerSecurityContext (в дополнение к UID) — поддержка реализована для dockershim и имеет статус альфа-версии.

Сеть

Опция с использованием CoreDNS вместо kube-dns достигла статуса бета-версии. В частности, это принесло возможность миграции на CoreDNS при апгрейде с помощью kubeadm кластера, использующего kube-dns: в этом случае kubeadm сгенерирует конфигурацию CoreDNS (т.е. Corefile) на основе ConfigMap из kube-dns.

Традиционно /etc/resolv.conf на поде управляется kubelet, а данные этого конфига генерируются на основе pod.dnsPolicy. В Kubernetes 1.10 (в статусе бета-версии) представлена поддержка конфигурации resolv.conf для пода. Для этого в PodSpec добавлено поле dnsParams, которое позволяет переписывать имеющиеся настройки DNS. Подробнее — в design-proposals. Иллюстрация использования dnsPolicy: Custom с dnsParams:

# Pod spec
apiVersion: v1
kind: Pod
metadata: {"namespace": "ns1", "name": "example"}
spec:
  ...
  dnsPolicy: Custom
  dnsParams:
    nameservers: ["1.2.3.4"]
    search:
    - ns1.svc.cluster.local
    - my.dns.search.suffix
    options:
    - name: ndots
      value: 2
    - name: edns0

В kube-proxy добавлена опция, позволяющая определять диапазон IP-адресов для NodePort, т.е. инициировать фильтрацию допустимых значений с помощью --nodeport-addresses (со значением по умолчанию 0.0.0.0/0, т.е. пропускать всё, чему соответствует нынешнее поведение NodePort). Предусмотрена реализация в kube-proxy для iptables, Linux userspace, IPVS, Window userspace, winkernel. Статус — альфа-версия.

Аутентификация

Добавлены новые методы аутентификации (альфа-версия):

1. внешние клиентские провайдеры: отвечая на давние запросы пользователей K8s на exec-based plugins, в kubectl (client-go) реализовали поддержку исполняемых плагинов, которые могут получать аутентификационные данные исполнением произвольной команды и чтением её вывода (плагин GCP тоже может быть настроен на вызов команд, отличных от gcloud). Один из вариантов применения — облачные провайдеры смогут создавать собственные системы аутентификации (вместо использования стандартных механизмов Kubernetes);
2. TokenRequest API для получения токенов JWT (JSON Web Tokens), привязанных к клиентам (audience) и времени.

Кроме того, стабильный статус получила возможность ограничения доступа узлов к определённым API (с помощью режима авторизации Node и admission-плагина NodeRestriction) с целью выдавать им разрешение только на ограниченное число объектов и связанных с ними секретов.

CLI

Достигнут прогресс в переработке вывода, показываемого командами kubectl get и kubectl describe. Глобальная задача инициативы, получившей в Kubernetes 1.10 статус бета-версии, заключается в том, что получение столбцов для табличного отображения данных должно происходить на стороне сервера (а не клиента), — это делается с целью улучшить пользовательский интерфейс при работе с расширениями. Начавшаяся ранее (в K8s 1.8) работа на серверной стороне доведена до уровня беты, а также были проведены основные изменения на стороне клиента.

В kubectl port-forward добавлена возможность использования имени ресурса для выбора подходящего пода (и флаг --pod-running-timeout для ожидания, пока хотя бы один под будет запущен), а также поддержка указания сервиса для проброса порта (например: kubectl port-forward svc/myservice 8443:443).

Новые сокращённые имена для команд kubectl: cj вместо CronJobs, crds — CustomResourceDefinition. Например, стала доступна команда kubectl get crds.

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

• API Aggregation, т.е. агрегация пользовательских apiservers с основным API в Kubernetes, получил стабильный статус и официально готов к использованию в production.
• Kubelet и kube-proxy теперь могут запускаться как родные службы в Windows. Добавлена поддержка Windows Service Control Manager (SCM) и экспериментальная поддержка изоляции с Hyper-V для подов с единственным контейнером.
• Функция Persistent Volume Claim Protection (PVCProtection), «защищающая» от возможного удаления PVCs, которые активно используются подами, переименована в Storage Protection и доведена до бета-версии.
• Альфа-версия поддержки Azure в cluster-autoscaler.

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

• Поддерживаемая версия etcd — 3.1.12. При этом etcd2 в качестве бэкенда объявлена устаревшей, её поддержка будет удалена в релизе Kubernetes 1.13.
• Проверенные версии Docker — от 1.11.2 до 1.13.1 и 17.03.x (не изменились с релиза K8s 1.9).
• Версия Go — 1.9.3 (вместо 1.9.2), минимально поддерживаемая — 1.9.1.
• Версия CNI — 0.6.0.

P.S.

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

• «Kubernetes 1.9: обзор основных новшеств»;
• «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
• «Kubernetes 1.8: обзор основных новшеств»;
• «Docker 17.06 и Kubernetes 1.7: ключевые новшества»;
• «Инфраструктура с Kubernetes как доступная услуга».