В конце марта состоялся релиз 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:
- CPU Manager (назначение подам конкретных ядер процессора — подробнее о нём писали в статье про K8s 1.8);
- Huge Pages (возможность использования подами 2Mi и 1Gi Huge Pages, что актуально для приложений, потребляющих большие объёмы памяти);
- 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. Статус — альфа-версия.
Аутентификация
Добавлены новые методы аутентификации (альфа-версия):
- внешние клиентские провайдеры: отвечая на давние запросы пользователей K8s на exec-based plugins, в kubectl (client-go) реализовали поддержку исполняемых плагинов, которые могут получать аутентификационные данные исполнением произвольной команды и чтением её вывода (плагин GCP тоже может быть настроен на вызов команд, отличных от gcloud). Один из вариантов применения — облачные провайдеры смогут создавать собственные системы аутентификации (вместо использования стандартных механизмов Kubernetes);
- 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 как доступная услуга».
Автор: Dmitry Stolyarov
