Большое и хорошо организованное Open Source-сообщество, стоящее за разработкой Kubernetes, приучило нас ждать значимых и многочисленных изменений от каждого релиза. И Kubernetes 1.8 не стал исключением, представив на радость DevOps-инженерам и всем со
Официальный релиз Kubernetes 1.8 был запланирован ещё на минувшую среду, однако официальные анонсы (в блоге проекта и CNCF) пока не состоялись. Тем не менее, сегодня в 3:35 ночи по MSK в Git-репозитории проекта было замечено изменение в CHANGELOG, которое сигнализирует о готовности Kubernetes 1.8 для скачивания и использования:
Итак, что же нового принёс релиз Kubernetes 1.8?
Сеть
В kube-proxy добавлена альфа-версия поддержки режима IPVS для балансировки нагрузки (вместо iptables). В этом режиме kube-proxy следит за сервисами и endpoints в Kubernetes, создавая netlink-интерфейс (
virtual server
и real server
соответственно). Кроме того, он периодически синхронизирует их, поддерживая консистентность состояния IPVS. При запросе на доступ к сервису трафик перенаправляется на один из подов бэкенда. При этом IPVS предлагает различные алгоритмы для балансировки нагрузки (round-robin, least connection, destination hashing, source hashing, shortest expected delay, never queue). Такую возможность часто запрашивали в тикетах Kubernetes, и мы сами тоже очень её ждали.Среди других сетевых новшеств — бета-версии поддержки политик для исходящего трафика
EgressRules
в NetworkPolicy API, а также возможность (в том же NetworkPolicy
) применения правил по CIDR источника/получателя (через ipBlockRule
).Планировщик
Главное новшество в планировщике — возможность задавать подам приоритеты (в спецификации пода,
PodSpec
, пользователи определяют поле PriorityClassName
, а Kubernetes на его основе выставляет Priority
). Цель банальна: улучшить распределение ресурсов в случаях, когда их не хватает, а требуется одновременно выполнить по-настоящему критичные задачи и менее срочные/важные. Теперь поды с высоким приоритетом будут получать больший шанс на исполнение. Кроме того, при освобождении ресурсов в кластере (preemption) поды с меньшим приоритетом будут затронуты скорее подов с высоким приоритетом. В частности, для этого в kubelet была изменена стратегия по выборке подов (eviction strategy), в которой теперь учитываются одновременно и приоритет пода, и потребление им ресурсов. Реализация всех этих возможностей имеет статус альфа-версии. Приоритеты Kubernetes и работа с ними подробно описаны в документации по архитектуре.Ещё одно интересное новшество, представленное в альфа-версии, — более сложный механизм обработки поля условий (
Condition
, см. документацию) на узлах. Традиционно в этом поле фиксируются проблемные состояния узла — например, при отсутствии сети условие NetworkUnavailable
ставится в True
, в результате чего поды перестанут назначаться на этот узел. С помощью нового подхода Taints Node by Condition такая же ситуация приведёт к пометке узла определённым статусом (например, node.kubernetes.io/networkUnavailable=:NoSchedule
), на основе которого (в спецификации пода) можно решить, что делать дальше (действительно ли не назначать под такому проблемному узлу).Хранилища
Указание опций монтирования для томов стало стабильным, а одновременно с этим:
- в спецификации
PersistentVolume
появилось новое полеMountOptions
для указания опций монтирования (вместо annotations); - в спецификации
StorageClass
появилось аналогичное полеMountOptions
для динамически создаваемых томов.
В API метрики Kubernetes добавлена информация о доступном пространстве в постоянных томах (PV), а также метрики успешности выполнения и времени задержки для всех вызовов mount/unmount/attach/detach/provision/delete.
В спецификации
PersistentVolume
для Azure File, CephFS, iSCSI, GlusterFS теперь можно ссылаться на ресурсы в пространствах имён.Среди нестабильных нововведений (в статусах альфа и бета):
- в
StorageClass
добавлена бета-версия поддержки определения reclaim policy (аналогично PersistentVolume) вместо применения политикиdelete
всегда по умолчанию; - в Kubernetes API добавлена возможность увеличения размера тома — альфа-версия этой фичи увеличивает размер только для тома (не делает resize для файловой системы) и поддерживает только Gluster;
- началась работа над изоляцией/ограничениями для хранилищ данных — в статусе альфа представлен новый ресурс
ephemeral-storage
, который включает в себя всё дисковое пространство, доступное контейнеру, и позволяет устанавливать ограничения на возможный объём (quota management) и запросы к нему (limitrange) — подробнее см. в текущей документации; - новое поле
VolumeMount.Propagation
дляVolumeMount
в контейнерах пода (альфа-версия) позволяет устанавливать значениеBidirectional
для возможности использования того же примонтированного каталога на хосте и в других контейнерах; - доступен ранний прототип создания снимков томов (volume snapshots) через Kubernetes API — пока эти снапшоты могут быть неконсистентными, и ответственный за них код вынесен из ядра Kubernetes во внешний репозиторий.
kubelet
В kubelet появилась альфа-версия нового компонента — CPU Manager, — взаимодействующего напрямую с kuberuntime и позволяющего назначать контейнерам подов выделенные ядра процессоров (т.е. CPU affinity policies на уровне контейнеров). Как уточняется в документации, его появление стало ответом на две проблемы:
- плохая или непредсказуемая производительность по сравнению с виртуальными машинами (из-за большого количества переключений контекста и недостаточно эффективного использования кэша),
- недопустимые задержки, относящиеся к планировщику процессов ОС, что особенно заметно в функциях виртуальных сетевых интерфейсов.
Динамическая конфигурация kubelet — ещё одна фича в альфа-статусе, позволяющая обновлять конфигурацию этого агента во всех узлах «живого» кластера. Доведение её до стабильного состояния (GA) ожидается только в релизе 1.10.
Метрики
Поддержка пользовательских метрик в Horizontal Pod Autoscaler (HPA) получила статус бета-версии, и связанные с ней API переведены на
v1beta1
.metrics-server стал рекомендованным способом предоставления API для метрик ресурсов. Деплоится как дополнение по аналогии с Heapster. Прямое получение метрик из Heapster объявлено устаревшим.
Cluster Autoscaler
Утилита Cluster Autoscaler, созданная для автоматического изменения размера кластера Kubernetes (когда есть поды, которые не запускаются из-за недостатка ресурсов, или некоторые узлы плохо используются долгое время), получила стабильный статус (GA) и поддержку до 1000 узлов.
Кроме того, при удалении узлов Cluster Autoscaler теперь даёт подам по 10 минут для корректного завершения работы (graceful termination). В случае, если под так и не остановлен за это время, узел всё равно удаляется. Раньше этот лимит составлял 1 минуту или корректного завершения не дожидались вообще.
kubeadm и kops
В kubeadm появилась альфа-реализация деплоя кластера (control plane) типа self-hosted (
kubeadm init
с флагом --feature-gates=SelfHosting=true
). Сертификаты при этом могут храниться на диске (hostPath
) или в секретах. А новая подкоманда kubeadm upgrade
(находится в бета-статусе) позволяет автоматически выполнять обновление кластера self-hosted, созданного с помощью kubeadm.Другая новая возможность kubeadm в статусе альфа — выполнение подзадач вместо всего цикла
kubeadm init
с помощью подкоманды phase
(на текущий момент доступна как kubeadm alpha phase
и будет приведена в официальный вид в следующем релизе Kubernetes). Основное предназначение — возможность лучшей интеграции kubeadm с provisioning-утилитами вроде kops и GKE.В kops, тем временем, представлены две новые фичи в статусе альфа: поддержка bare metal-машин в качестве целевых и возможность запуска как сервера (см. Kops HTTP API Server). Наконец, поддержку GCE в kops «повысили» до статуса бета-версии.
CLI
Консольная утилита kubectl получила экспериментальную (альфа-версия) поддержку дополнений. Это означает, что стандартный набор входящих в неё команд теперь можно расширять с помощью плагинов.
Команды
rollout
и rollback
в kubectl теперь поддерживают StatefulSet
.API
Изменения в API включают в себя
APIListChunking
— новый подход к выдаче ответов на запросы LIST
. Теперь они разбиваются на небольшие куски и выдаются клиенту в соответствии с указанным им лимитом. В результате, сервер потребляет меньше памяти и CPU при выдаче очень больших списков, и такое поведение станет стандартным для всех инфомеров в Kubernetes 1.9.CustomResourceDefinition API научился валидировать объекты, основываясь на JSON-схеме (из CRD-спецификации) — альфа-реализация доступна как
CustomResourceValidation
в kube-apiserver.Сборщик мусора получил поддержку пользовательских API, добавленных через
CustomResourceDefinition
или агрегированные API-серверы. Поскольку обновления контроллера происходят периодически, между добавлением API и началом работы сборщика мусора для него стоит ожидать задержку около 30 секунд.Workload API
Так называемый Workload API — это базовая часть Kubernetes API, относящаяся к «рабочим нагрузкам» и включающая в себя
DaemonSet
, Deployment
, ReplicaSet
, StatefulSet
. На данный момент эти API перенесены в группу apps и с релизом Kubernetes 1.8 получили версию v1beta2. Стабилизация же Workload API предполагает вынесение этих API в отдельную группу и достижение максимально возможной консистентности с помощью стандартизации этих API путём удаления/добавления/переименования имеющихся полей, определения однотипных значений по умолчанию, общей валидации. Например, стратегией spec.updateStrategy
по умолчанию для StatefulSet
и DaemonSet
стал RollingUpdate
, а выборка по умолчанию spec.selector
для всех Workload API (из-за несовместимости с kubectl apply
и strategic merge patch) отключена и теперь требует явного определения пользователем в манифесте. Обобщающий тикет с подробностями — #353.Другое
Среди прочих (и весьма многочисленных!) изменений в релизе Kubernetes 1.8 отмечу:
- управление доступом на основе ролей (RBAC), использующее группу API
rbac.authorization.k8s.io
для возможности конфигурации динамических политик, переведено в стабильный статус (GA), а также получило бета-версию нового API (SelfSubjectRulesReview
) для просмотра действий, которые пользователь может выполнить с пространством имён; - представлена альфа-версия механизма для хранения ключей шифрования ресурсов в сторонних системах (Key Management Systems, KMS), и одновременно с этим появился плагин Google Cloud KMS (#48522);
- в
PodSecurityPolicies
добавлена поддержка белого списка разрешённых путей для томов хоста; - поддержка CRI-O (Container Runtime Interface) на базе стандарта от Open Container Initiative объявлена стабильной (прошла все тесты e2e) [CRI-O — связующее звено между kubelet и исполняемыми средами, совместимыми с OCI, такими как runc; подробнее см. в GitHub], а также проект cri-containerd достиг статуса альфа-версии;
- поддержка Multi-cluster, ранее известная как Federation, готовится к стабильному выпуску (GA) в следующих релизах Kubernetes, а пока стали доступны альфа-реализации Federated Jobs, которые автоматически деплоятся на множество кластеров, и Federated Horizontal Pod Autoscaling (HPA), работающих аналогично обычным HPA, но, опять же, с распространением на множество кластеров;
- команда, ответственная за масштабируемость, формально зафиксировала процесс своего тестирования, создала документацию для имеющихся пороговых значений, определила новые наборы по уровням обслуживания (Service Level Indicators и Service Level Objectives).
P.S.
Во время подготовки Kubernetes 1.8 проект собирался со следующими версиями Docker: 1.11.2, 1.12.6, 1.13.1, 17.03.2. Список известных проблем (known issues) для них см. здесь. В том же документе, озаглавленном как «Introduction to v1.8.0», можно найти и более полный список всех крупных изменений.
Сами мы затянули с обновлением обслуживаемых кластеров Kubernetes с релиза 1.6 до 1.7 и провели основную миграцию только 2 недели назад (на данный момент осталось несколько инсталляций с версией 1.6). Повсеместное обновление до нового релиза — 1.8 — планируем уже в октябре.
Читайте также в нашем блоге:
- «Docker 17.06 и Kubernetes 1.7: ключевые новшества»;
- «Наш опыт с Kubernetes в небольших проектах» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
- «Зачем нужен Kubernetes и почему он больше, чем PaaS?»;
- «Как на самом деле работает планировщик Kubernetes?» (перевод).