Каков рекомендуемый способ обновления кластера kubernetes при выпуске новых версий?

Question

Каков рекомендуемый способ обновления кластера kubernetes при выпуске новых версий?

Я слышал here это может быть https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-push.sh. Если это так, то как kube-push.sh относится к https://github.com/GoogleCloudPlatform/kubernetes/blob/master/cluster/gce/upgrade.sh?

Я также слышал here, что вместо этого мы должны создать новый кластер, скопировать/переместить контейнеры, контроллеры репликации и службы из первого кластера в новый, а затем отключить первый кластер.

Я запускаю кластер на aws, если это актуально.

Answer 1

Второй скрипт, который вы ссылаетесь (gce/upgrade.sh), работает только в том случае, если ваш кластер работает на GCE. Для AWS еще нет эквивалентного скрипта, но вы можете посмотреть на скрипт и выполнить шаги (или записать их в скрипт), чтобы получить такое же поведение.

Основные отличия между upgrade.sh и kube-push.sh в том, что первый выполняет замену обновления (удалите узел, создайте новый узел, чтобы его заменить), в то время как позднее выполняется обновление «на месте».

Снятие и замена главного узла выполняется только в том случае, если постоянные данные (база данных etcd, серверные сертификаты, авторизованные маркеры на предъявителя и т. Д.) Находятся на постоянном диске отдельно от загрузочного диска ведущего устройства (таким образом он настроен на по умолчанию в GCE). Удаление и замена узлов должны быть в порядке на AWS (но имейте в виду, что любые модули, не находящиеся под контроллером репликации, не будут перезапущены).

Выполнение обновления на месте не требует какой-либо специальной конфигурации, но этот путь кода не так тщательно протестирован, как опция удаления и замены.

Вам не нужно полностью заменять ваш кластер при обновлении до новой версии, если только вы не используете предварительно выпущенные версии (например, альфа-версии или бета-версии), которые иногда могут прерывать изменения между ними.