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

Вчера, 9 декабря, состоялся ^[1] очередной релиз Kubernetes — 1.17. По сложившейся для нашего блога традиции, мы рассказываем о наиболее значимых изменениях в новой версии.

Информация, использованная для подготовки этого материала, взята из официального анонса, таблицы Kubernetes enhancements tracking ^[2], CHANGELOG-1.17 ^[3] и соответствующих issues, pull requests, а также Kubernetes Enhancement Proposals (KEP). Итак, что нового?..

Маршрутизация с учётом топологии

Вот уже долгое время в сообществе Kubernetes ждали этой фичи — Topology-aware service routing. Если KEP ^[4] по ней берёт своё начало в октябре 2018-го, а официальный enhancement ^[5] — 2 года назад, то обычные issues (вроде этого ^[6]) — и вовсе старше ещё на несколько лет…

Общая идея сводится к тому, чтобы предоставить возможность реализовывать «локальную» маршрутизацию для сервисов, находящихся в Kubernetes. «Локальность» в данном случае означает «тот же самый топологический уровень» (topology level), коим может являться:

• одинаковый для сервисов узел,
• та же самая серверная стойка,
• тот же самый регион,
• тот же самый облачный провайдер,
• …

Примеры использования такой фичи:

• экономия на трафике в облачных инсталляциях со множеством зон доступности (multi-AZ) — см. свежую иллюстрацию ^[7] на примере трафика одного региона, но разных AZ в AWS;
• меньшие задержки в производительности/лучшая пропускная способность;
• шардированный сервис, имеющий локальную информацию об узле в каждом шарде;
• размещение fluentd (или аналогов) на один узел с приложениями, логи которых собираются;
• …

Такую маршрутизацию, «знающую» о топологии, ещё называют подобием network affinity — по аналогии с node affinity ^[8], pod affinity/anti-affinity ^[9] или появившимся не так давно ^[10] Topology-Aware Volume Scheduling ^[11] (или Volume Provisioning ^[12]). Текущий уровень реализации ServiceTopology в Kubernetes — альфа-версия.

Подробности о том, как фича устроена и как ей уже можно воспользоваться, читайте в этой статье ^[13] от одного из авторов.

Поддержка двойного стека IPv4/IPv6

Значительный прогресс зафиксирован ^[14] в другой сетевой фиче: одновременной поддержке двух IP-стеков, что была впервые представлена в K8s 1.16 ^[15]. В частности, новый релиз принёс следующие изменения:

• в kube-proxy реализована ^[16] возможность одновременной работы в обоих режимах (IPv4 и IPv6);
• в Pod.Status.PodIPs появилась ^[17] поддержка downward API (одновременно с этим в /etc/hosts теперь требуют для хоста добавлять и IPv6-адрес);
• поддержка двух стеков в KIND ^[18] (Kubernetes IN Docker), kubeadm ^[19];
• обновлённые e2e-тесты.

Иллюстрация ^[20] использования двойного стека IPV4/IPv6 в KIND

Прогресс по CSI

Объявлена стабильной поддержка топологий ^[21] для хранилищ на базе CSI, впервые представленная в K8s 1.12 ^[21].

Инициатива по миграции плагинов томов на CSI — CSI Migration ^[22] — достигла бета-версии. Эта фича критична для того, чтобы перевести существующие плагины хранилищ (in-tree) на современный интерфейс (CSI, out-of-tree) незаметно для конечных пользователей Kubernetes. Администраторам кластеров будет достаточно активировать CSI Migration, после чего существующие stateful-инсталляции и рабочие нагрузки будут по-прежнему «просто работать», но уже с использованием актуальных CSI-драйверов вместо устаревших, входящих в ядро Kubernetes.

На данный момент в статусе бета-версии готова миграция для драйверов AWS EBS (kubernetes.io/aws-ebs) и GCE PD (kubernetes.io/gce-pd). Прогнозы по другим хранилищам таковы:

О том, как «традиционная» поддержка хранилищ в K8s пришла к CSI, мы рассказывали в этой статье ^[23]. А переходу миграции CSI в статус бета-версии посвящена отдельная публикация ^[24] в блоге проекта.

Кроме того, статуса бета-версии (т.е. включения по умолчанию) в релизе Kubernetes 1.17 достигла другая значимая функциональность в контексте CSI, берущая своё начало (альфа-реализацию) в K8s 1.12, — создание снапшотов ^[25] и восстановление из них. Среди изменений, произведённых в Kubernetes Volume Snapshot на пути к бета-релизу: разбивка sidecar'а CSI external-snapshotter на два контроллера, добавлен секрет на удаление (deletion secret) как аннотация к содержимому снапшота тома, новый финализатор (finalizer) для предотвращения удаления API-объекта снапшота при наличии оставшихся связей.

На момент релиза 1.17 фича поддерживается у следующих CSI-драйверов: GCE Persistent Disk CSI Driver, Portworx CSI Driver и NetApp Trident CSI Driver. Подробнее о её реализации и использовании можно прочитать в этой публикации ^[26] в блоге.

Cloud Provider Labels

Лейблы, которые автоматически назначаются на создаваемые узлы и тома в зависимости от используемого облачного провайдера, были доступны в Kubernetes как бета-версия уже очень давно — начиная с релиза K8s 1.2 (апрель 2016 года). Учитывая их широкое применение так долго, разработчики решили ^[27], что настало время объявить фичу стабильной (GA).

Посему все они были переименованы соответствующим образом (по топологиям):

• beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
• failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… но по-прежнему доступны и по своим старым названиям (для обратной совместимости), однако всем администраторам рекомендуется переходить на актуальные лейблы. Соответствующая документация ^[28] K8s была обновлена.

Структурированный вывод kubeadm

В формате альфа-версии впервые представлен структурированный вывод для утилиты kubeadm ^[29]. Поддерживаемые форматы: JSON, YAML, Go-шаблон.

Мотивация к реализации этой фичи (согласно KEP ^[30]) такова:

Хоть Kubernetes и может быть развёрнут вручную, стандартом де-факто (если не де-юре) для этой операции является использование kubeadm. Популярные инструменты управления системами вроде Terraform опираются на kubeadm для деплоя Kubernetes. Запланированные улучшения в Cluster API включают в себя компонуемый пакет для bootstrapping'а Kubernetes с kubeadm и cloud-init.

Без структурированного вывода даже самые безобидные на первый взгляд изменения могут сломать Terraform, Cluster API и другой софт, использующий результаты работы kubeadm.

В ближайших планах значится поддержка (в виде структурированного вывода) для следующих команд:

• alpha certs
• config images list
• init
• token create
• token list
• upgrade plan
• version

Иллюстрация JSON-ответа на команду kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Стабилизация других новшеств

Вообще же, релиз Kubernetes 1.17 был выпущен под девизом «Стабильность». Тому способствовал тот факт, что очень многие фичи в нём (их общее количество — 14) получили статус GA. Среди таковых:

• «пометка» узлов по определённым условиям (TaintNodesByCondition ^[31]), появившаяся в K8s 1.8 ^[32];
• Watch Bookmarks ^[33] — новый тип событий, имеющих метку, что все объекты до определённой версии (resourceVersion) уже были обработаны watch'ем;
• значения по умолчанию ^[34] (defaulting) для Custom Resources;
• разделяемые между контейнерами ^[35] в pod'е process namespaces;
• ScheduleDaemonSetPods — планирование pod'ов в DaemonSet ^[36] с помощью kube-scheduler (вместо контроллера DaemonSet);
• динамические лимиты ^[37] на количество томов в зависимости от типа узла;
• поддержка переменных окружения ^[38] для названий директорий, монтируемых как subPath;
• перенос Kubelet heartbeats ^[39] в специализированный Lease API;
• «защита финализатора» (Finalizer Protection ^[40]) для балансировщиков нагрузки (проверка соответствующих ресурсов Service'а перед удалением ресурсов LoadBalancer'а).

Прочие изменения

Полный список новшеств в Kubernetes 1.17, конечно, не ограничивается перечисленными выше. Вот некоторые другие из них (а для более полного перечня — см. CHANGELOG ^[3]):

• до бета-версии «доросла» представленная в прошлом релизе фича RunAsUserName для Windows ^[41];
• аналогичное изменение постигло ^[42] EndpointSlice API (тоже из K8s 1.16), однако пока это решение для улучшенеия производительности/масштабируемости Endpoint API не активировано по умолчанию;
• новая опция для kubelet — --reserved-cpus ^[43] — позволяет явно определять список CPU, зарезервированных для системы;
• для kubectl logs добавлен ^[44] новый флаг --prefix, добавлящий название pod'а и контейнера источника к каждой строке лога;
• в label.Selector добавили ^[45] RequiresExactMatch;
• все контейнеры в kube-dns теперь запускаются ^[46] с меньшими привилегиями;
• hyperkube ^[47] выделен в отдельный GitHub-репозиторий и больше не будет включаться в релизы Kubernetes;
• версия CoreDNS в составе в kubeadm — 1.6.5; версия crictl обновлена до v1.16.1; последняя проверенная версия Docker повышена до 19.03.

P.S.

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

• «Kubernetes 1.16: обзор основных новшеств ^[15]»;
• «Kubernetes 1.15: обзор основных новшеств ^[48]»;
• «Kubernetes 1.14: обзор основных новшеств ^[49]»;
• «Kubernetes 1.13: обзор основных новшеств ^[50]».

Автор: Dmitry Stolyarov

Источник ^[51]