Поздравляем с выходом версии 1.20. Третий релиз в 2020 году, в котором 11 фич объявили stable, 15 перевели в beta и добавили 16 новых в alpha-стадии.
Судя по Release Logo, котики уже захватили мир и даже не скрывают этого. Давайте посмотрим, какие блюдца с молоком они заботливо положили нам под ноги.
Конечно же, начать придется с громкой новости об отказе от dockershim. С одной стороны, дело это не быстрое, и есть еще целый год перед окончательным выпиливанием кода, но, с другой стороны, можно ожидать, что баги при взаимодействии с docker будут исправляться с меньшим приоритетом, чем раньше.
Второе важное изменение, которое может сломать ваш продакшен, заключается в том, что в версии 1.20 починили баг с таймаутами для Probe типа exec.
В описании контейнеров в манифесте подов есть специальный раздел, описывающий каким образом можно узнать, что приложение живое и готово обрабатывать входящие запросы. С помощью HTTP/TCP-запроса или запуска (exec probe) какого-либо процесса внутри контейнера (например, rabbitmqctl status) и анализа кода завершения.
Суть проблемы в следующем:
В манифесте есть поле timeoutSeconds:
, которое задает максимальное время ожидания ответа на запрос или время выполнения процесса внутри контейнера. Ошибка была в том, что при выполнении exec probe этот параметр не учитывался и процесс внутри контейнера мог работать бесконечно долгое время, пока сам не завершится.
Ошибку исправили, и в версии 1.20 все стало прекрасно. Но не для всех.
Если вы используете exec probe и указывали timeoutSeconds:
в своих манифестах — самое время проверить, укладывается ли время выполнения вашей пробы в таймаут.
А вот если вы не указывали timeoutSeconds:
, то у меня для вас не очень хорошая новость. Значение по умолчанию для этого параметра — 1 секунда, если ваша проба выполняется дольше, то успешной она явно не будет.
И как всегда — вишенка на торте. Если вы используете docker, то при наступлении таймаута процесс внутри контейнера может остаться работать дальше. И если это readinessProbe, то со временем количество таких процессов может превзойти все ваши смелые ожидания.
И к другим новостям:
Если вы пользовались alpha feature API Priority and Fairness (APF) в своем мульти-мастер кластере 1.19 — выключайте ее перед обновлением. В 1.20 она переведена в статус beta, но в процессе перевода отломали совместимость с alpha. После обновления она будет включена по умолчанию.
Мастеров больше не будет! Метка node-role.kubernetes.io/master
и taint node-role.kubernetes.io/master:NoSchedule
, которые по умолчанию ставил kubeadm на узлы с запущенными компонентами control-plane, объявлены deprecated и скоро будут убраны. Вместо них будут использоваться метка node-role.kubernetes.io/control-plane
и taint node-role.kubernetes.io/control-plane:NoSchedule
.
В kubeadm усилили проверки входящих параметров serviceSubnet и podSubnet.
Сеть для сервисов теперь имеет ограничение на размер и не должна аллоцировать более 20 бит. В переводе на человеческий это означает, что размер сети для IPv4 должен быть /12 или меньше (/13, /14 и т.п.), а для IPv6 — /108, но лучше будет использовать /112.
Сеть для подов теперь проверяется на совместимость с параметром --node-cidr-mask-size
, размер сетей, выделяемых на узел должен быть меньше, чем сеть для подов.
Из API сервера убрали возможность беспарольного входа. Теперь не получится восстановить потерянный доступ к кластеру, просто зайдя на мастер и добавив в ключи запуска API сервера ключ --insecure-port 8080
IPv4/IPv6 dual stack был немножко переписан в части реализации сервисов. Один сервис теперь может иметь как IPv4, так и IPv6 адрес (при включении "IPv6DualStack" feature gate). Но это привело к несовместимым изменениям в API. Изменился манифест Kind: Service
— вместо одного поля ipFamily
теперь будет целых три: ipFamilyPolicy
, ipFamilies
, clusterIPs
. Пишут, что большинству пользователей ничего не надо будет делать, сервисы останутся только IPv4, пока не включен соответствующий feature gate. TODO: Посмотреть, что там с Headless Service, которым в манифесте указываем clusterIP: None
Команда для работы с сертификатам (проверки, генерации или продления kubeadm alpha certs
переименована в kubeadm certs
. Старый вариант вызова еще работает, но в следующих релизах его уберут.
Анонсировали фичу GracefulNodeShutdown
— при ее включении kubelet будет самостоятельно завершать все запущенные поды, при выключении узла. Соблюдая все обычные gracefulShutdown таймауты и вызывая preStop хуки.
Команда kubectl debug
повышена до беты, и в ее описании появилось много различных возможностей. Запуск дополнительных эфемерных дебаг контейнеров в поде, создание копий пода и замена команды запуска. Единственная тонкость — новое название команды конфликтует с плагином debug
, и теперь вместо плагина будет выполнятся встроенная команда. Если вы хотите продолжать пользоваться плагином, то его придется переименовать.
В процессе починки CVE-2020-8559 немножко усилили безопасность, что может привести к поломке работы бэкендов расширения API, таких как metrics-server или prometheus adapter.
Выпущен новый CronJob controller v2. Видимо, чинить баги старого контроллера больше не могут, и решили выпустить новый, с новыми багами. Пока в стадии альфа, так что включать его надо с помощью специального feature gate.
powerman
Жуть какая. А напомните, почему софтом который настолько наплевательски относится к обратной совместимости, всё ещё продолжают активно пользоваться? </sarcasm>
unwrecker
Иппотека? :)
TomskDiver
Предположу так: Потому что после установки кубов их не обновляют, вернее ОЧЕНЬ редко обновляют до более свежей версии. Потому что такое обновление это Боль.
LuckySB Автор
Обновляют. Регулярно. Все проблемы возникают не в самом процессе обновления, а когда к новому кластеру обращаются устаревшими методами.
На работу продакшена, который был задеплоен в кластере обычно это не влияет.
Хотя в этот раз с exec probe получилось не очень хорошо )
gecube
Можно еще обновлять пересозданием кластера рядом и миграцией в него всех нагрузок. Все довольны ) И котики не страдают. Главное, чтобы стейтфул не было
ProFfeSsoRr
powerman
Если оно до сих пор (с Ваших слов) нормальным инструментом не стало, и, более того, в случае более вменяемого отношения к обратной совместимости оно им станет не раньше 2120 — похоже что в ближайшие лет 30 нормальным инструментом оно не станет при любых раскладах. :)
gecube
не станет, но им пользуется уже большинство смузи разработчиков.
Что хуже — люди не идут работать там, где нет смузевого кубернетса… УЖАС.
Никто не хочет те же рпмки руками устанавливать на прод сервера
ProFfeSsoRr