Мы используем куки и предполагаем, что вы согласны, если продолжите пользоваться сайтом
Понимаю и согласен
Close
Заявка на обратный звонок
Свяжемся с вами в течение рабочего дня
Нажимая кнопку, вы соглашаетесь на обработку ваших персональных данных согласно нашей политике конфиденциальности.
Блог Southbridge

Kubernetes 1.21 — неожиданно много изменений…


Новая эмблема символизирует распределение членов команды выпуска релиза по земному шару — от UTC-8 до UTC+8 (похоже, ни японцев, ни корейцев в команде нет). Эмблему нарисовал Aravind Sekar, независимый дизайнер из Индии. На мой взгляд, котики были круче.

Но давайте перейдем к чтению changelog и особенно моему любимому разделу Urgent Upgrade Notes.




CronJob


Сообщение в блоге гласит, что CronJob объявлены stable, но далее есть небольшое уточнение — стабильным объявлена версия API, то есть структура манифеста kind: cronJob, а вот с контроллером, который и отвечает за реализацию логики работы, все намного интереснее.

В версии 1.20 был добавлен CronJob контроллер версии 2. В новой версии 1.21 его перевели в стадию бета и включили по умолчанию. В версии 1.22 планируется удалить код старого CronJob контроллера. Очень, очень быстрые изменения, обычно не свойственные циклам релизов в Kubernetes.

Причем в документации все Cronjob limitations, о которых я писал на Хабре, остались без изменений.

Зачем тогда делали новый контроллер, если все проблемы с кронджобами остались нерешенными? Ответ есть в этой статье  — старый контроллер излишне нагружал API Kubernetes и не успевал создавать Job, если в кластере было больше 1000 Cronjob манифестов. Новая версия контроллера написана согласно последним гайдлайнам и намного быстрее.


Immutable Secret and ConfigMap


Добавили возможность создавать защищенные от изменений секреты и конфиг мапы. Видимо, защита от джунов, которые "pushed bad configuration". На мой взгляд, ConfigMap надо деплоить через helm чарты, а секреты хранить в Vault. Там, где есть история изменений, а ваш CI/CD не должен позволять выкатывать нерабочие конфиги на прод.


IPv4/IPv6 Dual-Stack support


Поддержка IPv6 теперь включена по умолчанию, единственная тонкость — ваш CNI также должен уметь в Dual-Stack. Calico умеет)


Graceful Node Shutdown


Kubelet научился определять ситуацию, когда узел выключается командой shutdown, и теперь посылает подам sigterm. TODO: Протестировать, не завершается ли container runtime быстрее kubelet, и что будет при простом systemctl shutdown kubelet.


PodSecurityPolicy Deprecation


Еще одна неоднозначная новость. PSP объявлены устаревшими и запланированы к удалению в версии 1.25. Но при этом PSP Replacement Policy (полиси для замены полиси) находятся в состоянии проекта, а альфа-версию обещают показать только в Kubernetes 1.22. Кратко ознакомиться, что же там проектируется, можно в KEP #2582. Самое странное из того, что там написано, на мой взгляд, — это предложение использовать namespace label, чтобы определять, по каким правилам проверять манифесты подов. Получается, что, выдав кому-либо права на редактирование неймспейса, вы даете ему и простой способ получить права администратора кластера.

Подождем и посмотрим, что же будет в итоге, а пока нам предлагают плавно переходить на использование стандартных PSP, аналоги которых в виде встроенных профилей будут захардкожены в новый admission plugin PSPv2.

Или переходить на использование сторонних решений, таких как Open Policy Agent Gatekeeper.


Urgent Upgrade Notes


По умолчанию теперь используется cgroupDriver systemd. Не забывайте проверять настройки своего containerd при установке нового кластера или добавлении узлов. Но и это еще не все. В версии 1.22 обещают принудительную смену cgroup driver в kubelet на systemd при обновлении кластера, поэтому пора уже почитать руководство по миграции и начать смену драйвера.

Много мелких изменений в районе CSI и PV: перестают использоваться старые метки, флаги и метрики. В принципе ничего страшного, скорее всего, надо будет просто обновить используемые CSI драйверы.

Команды kubeadm kubeconfig usercerts и debug переведены из экспериментальных в постоянные, и теперь их надо указывать без слова alpha.

Продолжают урезать функционал команды kubectl run. Убрали целый набор ключей для создания service и cronjob, объявили устаревшими ключи для установки реквестов и лимитов, сервис аккаунта и использования hostport. В общем активно заставляют использовать только готовые yaml-манифесты для создания объектов кластера.

К большому моему сожалению, окончательно убрали поддержку ключа kubectl --export. А как было удобно с помощью этого ключа получать из готового объекта кластера манифест для создания его копии, например, секрет с TLS сертификатом скопировать в другой namespace.

Всем, кто использует vSphere версии меньшей, чем 67u3, рекомендуют обновиться, время есть до выхода kubernetes 1.24.


Интересные мелкие новшества


В NetworkPolicy добавили поле endPort для поддержки диапазонов портов. Радуйтесь, любители запускать Asterisk в кластере.

В DaemonSets добавили поле MaxSurge, теперь во время обновления демонсета можно указать, чтобы сначала на узле создавался новый под, а после его запуска удалялся старый.

В команды kubectl exec и portforward добавили keepalive пинги, и теперь промежуточные HTTP-балансировщики не будут обрывать соединение, если в нем нет активности.

В Job добавили поле suspend и написали про это целую статью в блоге. Вот только я не понял, какой в этом смысл — имитация работы Kafka или Rabbitmq?
Появилась возможность выбирать неймспейсы по их имени. Просто в манифест неймспейса автоматически добавляют метку kubernetes.io/metadata.name.

В Service добавили поле InternalTrafficPolicy. Если указать в нем значение Local, трафик будет направляться только на поды, расположенные на том же узле кластера, что и под, отправивший запрос. Пока в альфа-статусе, для использования надо включить featureGate = ServiceInternalTrafficPolicy.

Наконец-то включили TTL Controller, который позволяет удалять манифесты завершившихся Job.

В манифест подов добавили аннотацию kubectl.kubernetes.io/default-container, с помощью которой можно указать, в какой контейнер пода делать exec, чьи логи смотреть и тому подобное, если при вызове не указан ключ -c.
Kubernetes DevOps