Нужно ли сливать узел для обновления версии kubelet?

Question

Я планирую обновить версию кластера kubernetes с v1.7.10 до v1.8.12.но так как проблема указывает, что все контейнеры будут перезапущены из-за изменения хеш-спецификацииИтак, какова предлагаемая процедура обновления?мне нужно опустошить узел перед обновлением версии kubelet, или просто выполнить обновление на месте и разрешить перезапуск всех контейнеров?какая разница ?

Кроме того, поскольку обновление до v1.9.0 также приведет к перезапуску контейнеров, могу ли я обновить v1.7.10 напрямую до v1.10.3?Таким образом, я могу избежать двух трудоемких обновлений до v1.8 и v1.9 как минимум.Есть ли какие-либо ограничения, препятствующие мне сделать это?

Любое предложение будет оценено.

Answer 1

Это всегда хорошая идея, чтобы истощить / оцепить узел, пока вы выполняете такие рабочие задачи, как обновление.После завершения обновления отсоедините узел, а затем повторите процесс для других узлов в кластере.

Re: пропуск версий, насколько я знаю, что в обновлении нет ограничений по пропуску второстепенных версий.

Answer 2

После некоторого тестирования и исследований я прихожу к некоторому выводу:

1. Слить узел не обязательно.По крайней мере, сток не может выселять демонов.Но использование узла является рекомендуемым способом обновления kubernetes, так как это может в наибольшей степени уменьшить влияние на приложения, развернутые с использованием развертывания.

   Кроме того, иногда требуется удаление узла.Например, с kubernetes v1.10 файлы журналов всех модулей изменились с /var/log/pods/pod-id/container_id.log на /var/log/pods/pod-id/container/id.log,поэтому при обновлении до v1.10 все модули должны быть перезапущены, чтобы использовать новый файл журнала, в противном случае вы не можете получить доступ к их журналам с помощью команды «kubectl logs».В настоящее время полезно использовать сток узла, и тем модулям, которые не могут быть удалены, например, демонам, мы должны перезапустить их вручную.

2. Пропуск обновления минорной версии не поддерживаетсяособенно в установке HA с несколькими хозяевами, что может быть доказано с помощью политики 10101 * GKE .Кроме того, пропустить обновление незначительной версии иногда представляет определенный риск.

   Снова, например, обновить до v1.10.В версии 1.10 объекты в группе API приложений начали сохраняться в etcd в формате apps / v1, что очень хорошо может быть обработано в v1.9, а v1.8 - нет.Поэтому, когда вы обновляете kubernetes с v1.8 до 1.10, в настройке HA некоторые мастера были обновлены, а некоторые нет, принесут некоторые странные проблемы, такие как установка / daemonset не может быть обработана должным образом, более подробную информацию см. мой другой вопрос .Поэтому такого обновления следует избегать как можно дольше.

Answer 3

Страница обновления кластера Kubeadm не рекомендует пропускать основную версию: от 17 до 1,8, тогда от 1,8 до 1,9 по-прежнему является рекомендуемым путем.
Я думаю, это та же идея для Сам kubernetes обновляет .

. Нужно ли мне дренировать узел перед обновлением версии kubelet

Вот что рекомендует документация:

Для каждого хоста (именуемого ниже $ HOST) в кластере обновите kubelet, выполнив следующие команды:

Подготовьте хост к обслуживанию, пометив его как не подлежащий планированию и исключив рабочую нагрузку:

kubectl drain $HOST --ignore-daemonsets