- PVSM.RU - https://www.pvsm.ru -

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

Kubernetes 1.8: обзор основных новшеств - 1

Большое и хорошо организованное Open Source-сообщество, стоящее за разработкой Kubernetes, приучило нас ждать значимых и многочисленных изменений от каждого релиза. И Kubernetes 1.8 не стал исключением, представив на радость DevOps-инженерам и всем сочувствующимучастникам улучшения и новые возможности практически во всех своих компонентах.

Официальный релиз Kubernetes 1.8 был запланирован [1] ещё на минувшую среду, однако официальные анонсы (в блоге проекта и CNCF) пока не состоялись. Тем не менее, сегодня в 3:35 ночи по MSK в Git-репозитории проекта было замечено изменение в CHANGELOG [2], которое сигнализирует о готовности Kubernetes 1.8 для скачивания и использования:

Kubernetes 1.8: обзор основных новшеств - 2

Итак, что же нового принёс релиз Kubernetes 1.8?

Сеть

В kube-proxy добавлена альфа-версия поддержки режима IPVS [3] для балансировки нагрузки (вместо iptables). В этом режиме kube-proxy следит [4] за сервисами и endpoints в Kubernetes, создавая netlink-интерфейс (virtual server и real server соответственно). Кроме того, он периодически синхронизирует их, поддерживая консистентность состояния IPVS. При запросе на доступ к сервису трафик перенаправляется на один из подов бэкенда. При этом IPVS предлагает различные алгоритмы для балансировки нагрузки (round-robin, least connection, destination hashing, source hashing, shortest expected delay, never queue). Такую возможность часто запрашивали [5] в тикетах Kubernetes, и мы сами тоже очень её ждали.

Среди других сетевых новшеств — бета-версии поддержки политик для исходящего трафика EgressRules в NetworkPolicy API, а также возможность (в том же NetworkPolicy) применения правил по CIDR источника/получателя (через ipBlockRule).

Планировщик

Главное новшество в планировщике — возможность задавать подам приоритеты (в спецификации пода, PodSpec, пользователи определяют поле PriorityClassName, а Kubernetes на его основе выставляет Priority). Цель банальна: улучшить распределение ресурсов в случаях, когда их не хватает, а требуется одновременно выполнить по-настоящему критичные задачи и менее срочные/важные. Теперь поды с высоким приоритетом будут получать больший шанс на исполнение. Кроме того, при освобождении ресурсов в кластере (preemption) поды с меньшим приоритетом будут затронуты скорее подов с высоким приоритетом. В частности, для этого в kubelet была изменена стратегия по выборке подов (eviction strategy), в которой теперь учитываются одновременно и приоритет пода, и потребление им ресурсов. Реализация всех этих возможностей имеет статус альфа-версии. Приоритеты Kubernetes и работа с ними подробно описаны в документации по архитектуре [6].

Ещё одно интересное новшество, представленное в альфа-версии, — более сложный механизм обработки поля условий (Condition, см. документацию [7]) на узлах. Традиционно в этом поле фиксируются проблемные состояния узла — например, при отсутствии сети условие NetworkUnavailable ставится в True, в результате чего поды перестанут назначаться на этот узел. С помощью нового подхода Taints Node by Condition [8] такая же ситуация приведёт к пометке узла определённым статусом (например, node.kubernetes.io/networkUnavailable=:NoSchedule), на основе которого (в спецификации пода) можно решить, что делать дальше (действительно ли не назначать под такому проблемному узлу).

Хранилища

Указание опций монтирования для томов стало стабильным, а одновременно с этим:

  • в спецификации PersistentVolume появилось новое поле MountOptions для указания опций монтирования (вместо annotations [9]);
  • в спецификации StorageClass появилось аналогичное поле MountOptions для динамически создаваемых томов.

В API метрики Kubernetes добавлена информация о доступном пространстве в постоянных томах (PV), а также метрики успешности выполнения и времени задержки для всех вызовов mount/unmount/attach/detach/provision/delete.

В спецификации PersistentVolume для Azure File, CephFS, iSCSI, GlusterFS теперь можно ссылаться на ресурсы в пространствах имён.

Среди нестабильных нововведений (в статусах альфа и бета):

  • в StorageClass добавлена бета-версия поддержки определения reclaim policy (аналогично PersistentVolume [10]) вместо применения политики delete всегда по умолчанию;
  • в Kubernetes API добавлена возможность увеличения размера тома — альфа-версия этой фичи увеличивает размер только для тома (не делает resize для файловой системы) и поддерживает только Gluster;
  • началась работа над изоляцией/ограничениями для хранилищ данных — в статусе альфа представлен новый ресурс ephemeral-storage, который включает в себя всё дисковое пространство, доступное контейнеру, и позволяет устанавливать ограничения на возможный объём (quota management) и запросы к нему (limitrange) — подробнее см. в текущей документации [11];
  • новое поле VolumeMount.Propagation для VolumeMount в контейнерах пода (альфа-версия) позволяет устанавливать значение Bidirectional для возможности использования того же примонтированного каталога на хосте и в других контейнерах;
  • доступен ранний прототип создания снимков томов (volume snapshots) через Kubernetes API — пока эти снапшоты могут быть неконсистентными, и ответственный за них код вынесен из ядра Kubernetes во внешний репозиторий [12].

kubelet

В kubelet появилась альфа-версия нового компонента — CPU Manager, — взаимодействующего напрямую с kuberuntime и позволяющего назначать контейнерам подов выделенные ядра процессоров (т.е. CPU affinity policies на уровне контейнеров). Как уточняется в документации [13], его появление стало ответом на две проблемы:

  1. плохая или непредсказуемая производительность по сравнению с виртуальными машинами (из-за большого количества переключений контекста и недостаточно эффективного использования кэша),
  2. недопустимые задержки, относящиеся к планировщику процессов ОС, что особенно заметно в функциях виртуальных сетевых интерфейсов.

Динамическая конфигурация kubelet — ещё одна фича в альфа-статусе, позволяющая обновлять конфигурацию этого агента во всех узлах «живого» кластера. Доведение её до стабильного состояния (GA) ожидается только в релизе 1.10.

Метрики

Поддержка пользовательских метрик в Horizontal Pod Autoscaler (HPA) получила статус бета-версии, и связанные с ней API переведены на v1beta1.

metrics-server [14] стал рекомендованным способом предоставления API для метрик ресурсов. Деплоится как дополнение по аналогии с Heapster [15]. Прямое получение метрик из Heapster объявлено устаревшим.

Cluster Autoscaler

Утилита Cluster Autoscaler [16], созданная для автоматического изменения размера кластера 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 [17]). Наконец, поддержку 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 перенесены в группу [18] apps и с релизом Kubernetes 1.8 получили версию v1beta2. Стабилизация же Workload API предполагает вынесение этих API в отдельную группу и достижение максимально возможной консистентности с помощью стандартизации этих API путём удаления/добавления/переименования имеющихся полей, определения однотипных значений по умолчанию, общей валидации. Например, стратегией spec.updateStrategy по умолчанию для StatefulSet и DaemonSet стал RollingUpdate, а выборка по умолчанию spec.selector для всех Workload API (из-за несовместимости с kubectl apply и strategic merge patch [19]) отключена и теперь требует явного определения пользователем в манифесте. Обобщающий тикет с подробностями — #353 [20].

Другое

Среди прочих (и весьма многочисленных!) изменений в релизе Kubernetes 1.8 отмечу:

  • управление доступом на основе ролей (RBAC [21]), использующее группу API rbac.authorization.k8s.io для возможности конфигурации динамических политик, переведено в стабильный статус (GA), а также получило бета-версию нового API (SelfSubjectRulesReview) для просмотра действий, которые пользователь может выполнить с пространством имён;
  • представлена альфа-версия механизма для хранения ключей шифрования ресурсов в сторонних системах (Key Management Systems, KMS), и одновременно с этим появился плагин Google Cloud KMS (#48522 [22]);
  • в PodSecurityPolicies добавлена поддержка белого списка разрешённых путей для томов хоста;
  • поддержка CRI-O (Container Runtime Interface) на базе стандарта от Open Container Initiative объявлена стабильной (прошла все тесты e2e) [CRI-O — связующее звено между kubelet и исполняемыми средами, совместимыми с OCI, такими как runc; подробнее см. в GitHub [23]], а также проект cri-containerd [24] достиг статуса альфа-версии;
  • поддержка 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) для них см. здесь [25]. В том же документе, озаглавленном как «Introduction to v1.8.0 [26]», можно найти и более полный список всех крупных изменений.

Сами мы затянули с обновлением обслуживаемых кластеров Kubernetes с релиза 1.6 до 1.7 и провели основную миграцию только 2 недели назад (на данный момент осталось несколько инсталляций с версией 1.6). Повсеместное обновление до нового релиза — 1.8 — планируем уже в октябре.

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

Автор: distol

Источник [31]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/264631

Ссылки в тексте:

[1] запланирован: https://github.com/kubernetes/features/blob/master/release-1.8/release-1.8.md#18-release-schedule-key-dates

[2] изменение в CHANGELOG: https://github.com/kubernetes/kubernetes/commit/ca712680c768c6914566e1fef9925323fd96f189#diff-4ac32a78649ca5bdd8e0ba38b7006a1e

[3] IPVS: https://en.wikipedia.org/wiki/IP_Virtual_Server

[4] следит: https://github.com/Lion-Wei/kubernetes.github.io/blob/fd67d74be85312613f0162759565be76a0b67e14/docs/concepts/services-networking/service.md#proxy-mode-ipvs

[5] часто запрашивали: https://github.com/kubernetes/kubernetes/issues/44063#issuecomment-292209684

[6] документации по архитектуре: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-api.md

[7] см. документацию: https://kubernetes.io/docs/concepts/architecture/nodes/#condition

[8] Taints Node by Condition: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/taint-node-by-condition.md

[9] annotations: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/

[10] PersistentVolume: https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/

[11] текущей документации: https://github.com/jingxu97/community/blob/14c53fc18238fed19313707847556acc4714e8df/contributors/design-proposals/local-ephemeral-storage.md

[12] внешний репозиторий: https://github.com/kubernetes-incubator/external-storage/tree/master/snapshot

[13] документации: https://github.com/ConnorDoyle/community/blob/ae38e21049b82f5da6a84553c0675c3b37fea873/contributors/design-proposals/cpu-manager.md

[14] metrics-server: https://github.com/kubernetes-incubator/metrics-server

[15] Heapster: https://github.com/kubernetes/heapster

[16] Cluster Autoscaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

[17] Kops HTTP API Server: https://github.com/kubernetes/kops/blob/master/docs/api-server/README.md

[18] группу: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/api-group.md

[19] strategic merge patch: https://github.com/kubernetes/community/blob/master/contributors/devel/strategic-merge-patch.md

[20] #353: https://github.com/kubernetes/features/issues/353

[21] RBAC: https://kubernetes.io/docs/admin/authorization/rbac/

[22] #48522: https://github.com/kubernetes/kubernetes/issues/48522

[23] GitHub: https://github.com/kubernetes-incubator/cri-o

[24] cri-containerd: https://github.com/kubernetes-incubator/cri-containerd

[25] здесь: https://github.com/kubernetes/features/blob/master/release-1.8/release-notes-draft.md#external-dependencies

[26] Introduction to v1.8.0: https://github.com/kubernetes/features/blob/master/release-1.8/release-notes-draft.md

[27] Docker 17.06 и Kubernetes 1.7: ключевые новшества: https://habrahabr.ru/company/flant/blog/332160/

[28] Наш опыт с Kubernetes в небольших проектах: https://habrahabr.ru/company/flant/blog/331188/

[29] Зачем нужен Kubernetes и почему он больше, чем PaaS?: https://habrahabr.ru/company/flant/blog/327338/

[30] Как на самом деле работает планировщик Kubernetes?: https://habrahabr.ru/company/flant/blog/335552/

[31] Источник: https://habrahabr.ru/post/338230/