Что нового в Kubernetes v1.23?

Kubernetes v1.23 — последний крупный выпуск 2021 года. Последнее обновление ведущей платформы оркестрации контейнеров переводит 11 функций в стабильный канал, помечая их как пригодные для общего использования. Вот что вам нужно знать перед обновлением.

Сеть с двойным стеком IPv4/IPv6

Сеть с двойным стеком IPv4/IPv6 обычно доступна в версии 1.23. Эта функция позволяет назначать поду или сервису как IPv4, так и IPv6-адреса. Для этого вам потребуются сетевые интерфейсы с двойным стеком на ваших узлах и поддерживающий сетевой плагин CNI.

Поле .spec.ipFamilyPolicy определяет, получает ли модуль или служба интерфейс с одним или двумя стеками. Установите для него значение PreferDualStack или RequireDualStack, чтобы активировать поддержку двойного стека. По умолчанию используется SingleStack.

spec:
    ipFamilyPolicy: RequireDualStack

В режимах двойного стека IP-адреса сервисного кластера будут выделяться как из адресного пространства IPv4, так и из адресного пространства IPv6. Вы можете установить порядок предпочтения стека с помощью поля .spec.ipFamilies. Это также позволяет указать IPv4 или IPv6 в качестве семейства для режима SingleStack.

Эфемерные тома

Эфемерные тома — еще один переход к статусу GA. Эфемерный том привязан к поду и удаляется при завершении пода. Он работает со всеми существующими драйверами системы хранения, которые поддерживают динамическое выделение ресурсов.

Эфемерные тома создаются путем вложения volumeClaimTemplate в новое поле ephemeral в разделе volumes спецификации Pod. volumeClaimTemplate должен напоминать обычный PersistentVolumeClaim.

spec:
  volumes:
    - name: ephemeral-volume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: example-volume-type
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: example-storage-class
            resources:
              requests:
                storage: 1Gi

Хотя поначалу «эфемерный» том может показаться странным, существует несколько вариантов использования этой функции. Тома часто используются для предоставления процессу пода значений конфигурации первого запуска, доступ к которым осуществляется только один раз. В этом сценарии эфемерный модуль идеален, так как он будет удален, когда модуль остановится, вместо того, чтобы повторно подключаться к будущим модулям, которые никогда не будут использовать данные. Другой возможный случай — это процессы, которые кэшируют большие объемы данных, но не нуждаются в их сохранении между отдельными завершениями Pod.

Горизонтальное автомасштабирование Pod v2

Спустя пять лет версия 2 API Horizontal Pod Autoscaler стала стабильной. Автомасштабирование позволяет Kubernetes автоматически корректировать количество реплик ваших Deployments, ReplicaSets и StatefulSets, чтобы реагировать на изменения метрик в реальном времени.

Это продвижение в настоящее время не влияет на исходную реализацию автомасштабирования. API v1 остается пригодным для использования и не устаревает. Новый API autoscaling/v2 заменяет autoscaling/v2beta2 предыдущих выпусков Kubernetes.

Использование v2 API выгодно, так как вы можете определять решения по автомасштабированию на основе пользовательских метрик. Контроллер автомасштабирования будет делать произвольные запросы API, чтобы информировать об изменениях реплики, вместо того, чтобы ограничивать вас условиями ЦП и памяти узла.

Пропуск изменений владельца тома при запуске модуля

Использование поля fsGroup на томе для определения его владельца в настоящее время заставляет Kubernetes рекурсивно выполнять chown() и chmod() на содержимом тома каждый раз. время, когда он установлен в Pod. Это может быть существенной проблемой производительности при работе с большими томами, состоящими в основном из небольших файлов. Pod не запустится, пока разрешения не будут изменены.

Kubernetes поддерживает поле fsGroupChangePolicy, позволяющее переопределить это поведение. Теперь он обычно доступен через поле securityContext модуля. Установка политики изменения на OnRootMismatch вызовет chown() только в том случае, если у корня тома неправильные разрешения. Это ускоряет запуск модуля, когда разрешения уже совместимы с объявлением fsGroup.

securityContext:
  fsGroupChangePolicy: OnRootMismatch

Другие особенности

Есть несколько заслуживающих внимания дополнений к альфа- и бета-интерфейсам API. Бета-канал теперь включает в себя:

Структурированное ведение журнала. Дополнительные компоненты поддерживают формат структурированного текстового ведения журнала, который создает выходные данные JSON. Структурированные журналы легче анализировать внешними инструментами, что упрощает процессы загрузки журналов и запросов.
PodSecurity API. PodSecurity заменяет старый контроллер допуска PodSecurityPolicy, который позволяет применять правила безопасности на уровне пространства имен. PodSecurity предоставляет механизм для определения того, что поды не могут существовать в пространстве имен, если им не хватает определенной защиты контекста безопасности.
Поддержка миграции CSI. Эта функция обеспечивает простой способ перехода с драйвера хранилища в дереве, который является частью API Kubernetes, например kubernetes.io/aws-ebs в драйвер CSI, поставляемый поставщиком. Пользователи не должны замечать никаких изменений в своем хранилище после завершения миграции. Сейчас эта функция доступна в бета-версии для AWS EBS, Azure Disk и GCE PD. Он помечен как альфа-версия для Ceph RBD и Portworx.

В альфа-канале дебютируют некоторые дополнительные возможности:

Проверка полей на стороне сервера. Проверка полей на стороне сервера отправляет предупреждения с сервера, когда клиент пытается создать ресурсы, содержащие неизвестные или повторяющиеся поля. Kubernetes исторически удалял эти поля, что могло привести к запутанному поведению. Включение функционального шлюза ServerSideFeatureValidation позволяет решить эту проблему.
Проверка языка выражений для CRD. Новый встроенный язык выражений упрощает проверку определений пользовательских ресурсов (CRD). Это помогает решить проблему абстрактного характера CRD, когда в настоящее время нельзя гарантировать соответствие определяемых пользователем ресурсов требованиям существующих контроллеров и клиентских приложений.
Поддержка OpenAPI v3 — OpenAPI v3 был добавлен за функциональными воротами (OpenAPIV3). Когда эта функция включена, вы можете запросить спецификацию OpenAPI версии 3.0 для любого типа объектов Kubernetes, предоставляя способ программного обнаружения и обхода ресурсов с помощью открытых стандартов API.

Заключение

Kubernetes v1.23 стабилизирует несколько важных функций, включая сеть с двумя стеками, новый настраиваемый инструмент горизонтального автомасштабирования Pod и эфемерные тома для работы с некритическими данными. Есть также десятки других изменений, а также два устаревших: интерфейс драйвера хранилища FlexVolume, предшествующий CSI, и несколько флагов ведения журнала, которые будут удалены в будущем.

В общей сложности 11 существующих функций были повышены до статуса GA. Еще 17 возможностей теперь помечены как бета-версия, а еще 19 — совершенно новые возможности, находящиеся в стадии альфа-тестирования. Стратегия выпуска Kubernetes фокусируется на ранней доставке функциональности, позволяет сообществу направлять разработку и помогает оптимизировать реализацию API. Хотя альфа- или бета-версии обычно переходят в стабильную версию, это не гарантируется. API-интерфейсы могут значительно измениться или быть полностью удалены в процессе разработки.

Вы можете прочитать полные примечания к выпуску v1.23 на GitHub. Загрузки доступны на странице релизов. Вы можете обновить существующий кластер, созданный с помощью Kubeadm, следуя инструкциям в документации. Процесс будет отличаться для пользователей управляемых облачных предложений и сторонних дистрибутивов Kubernetes.