Kubernetes upgrade: различия между версиями

Материал из ALT Linux Wiki
(Новая страница: «= Описание скриптов обновления kubernetes с версии 1.26 = == Скрипты обновления rootless kubernetes == === Подготовка архивов для разворачивания rootless kubernetes без доступа в Интернет ===»)
 
 
(не показано 17 промежуточных версий этого же участника)
Строка 3: Строка 3:
== Скрипты обновления rootless kubernetes ==
== Скрипты обновления rootless kubernetes ==


=== Подготовка архивов для разворачивания rootless kubernetes без доступа в Интернет ===
Механизм обновления kubernetes-кластера не позволяет проводить обновление узлов кластера с пропуском промежуточных версий. Например, чтобы обновить узлы кластера с минорной версии <code>1.26</code> до минорной версии <code>1.31</code> необходимо последовательно и синхронизировано обновить узлы через промежуточные версии
<code>1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31</code>.
Причем при обновлении необходимо, чтобы минорные версии всех обновляемых узлов были соседними. Не допускается, например, обновление программного обеспечения узла с версии <code>1.27</code> до версии <code>1.28</code>, если в кластере есть узлы с версией <code>1.26</code>.
 
Таким образом для обновления узлов кластера с версии <code>1.26</code> до версии <code>1.28</code> узла кластера должны в рамках локальной сети иметь доступ как к промежуточным версиям <code>RPM-пакетам kubernetes</code>, так и к промежуточным версиям <code>docker-образов kuberbetes</code>.
 
Промежуточные версии <code>RPM-пакетов kubernetes</code> размещаются на узле с внутренним доменным именем <code>sigstore.local</code>.
Промежуточные версии <code>docker-образов kuberbetes</code> размещаются на узле с внутренним доменным именем <code>registry.local</code>.
Обычно при стандартном разворачивании это один и тот же узел, с которого начиналось разворачивание кластера.
 
=== Подготовка узлов кластера без доступа в Интернет для обновления rootless kubernetes ===
 
Для обновления kubernetes в сети без доступа в Интернет необходимо наличие следующих архивов:
* <code>amd64_27-31_tar.xz</code> - архив docker-образов всех промежуточных версий;
* <code>kuberRPMS_1.27-1.31.tgz</code>rpm-пакетов kubelet, kubeadm, cri-o и зависимых пакетов всех промежуточных версий.
 
==== Добавление в локальный регистратор registry.local промежуточных docker образов kubernetes  ====
 
Файл архива <code>amd64_27-31_tar.xz</code> необходимо разместить на узле с доменом  <code>sigstore.local</code> в домашнем каталоге пользователя входящим в группу<code>podman_dev</code> (обычно это пользователь <code>imagemaker</code>).
 
Для выкатывания промежуточных docker-образов в локальный регистратор <code>registry.local</code> необходимо зайти в пользователя <code>imagemaker</code> (вход через <code>su- imagemaker</code> недопускается) и набрать команду разворачивания архива, подписи образов и передачи их в регистратор:
<pre>
$ podsec-load-sign-oci ./amd64_27-31_tar.xz amd64 <E-mail_подписанта> registry.local/k8s-c10f2
</pre>
 
После завершения команды (это может составить несколько минут) проверить наличие добавленных образов на регистраторе можно командой
<pre>
curl -s  http://registry.local/v2/_catalog | jq .
{
  "repositories": [
    "k8s-c10f1/...,
    "k8s-c10f2/coredns",
    "k8s-c10f2/etcd",
    "k8s-c10f2/flannel",
    "k8s-c10f2/flannel-cni-plugin",
    "k8s-c10f2/kube-apiserver",
    "k8s-c10f2/kube-controller-manager",
    "k8s-c10f2/kube-proxy",
    "k8s-c10f2/kube-scheduler",
    "k8s-c10f2/pause"
  ]
}
</pre>
В списке должны присутствовать вышеперечисленные образы с префиксом <code>k8s-c10f2/...</code>.
 
Получить список тегов (kubernetes-версий) образов образов можно командой:
<pre>
curl -s  http://registry.local/v2/k8s-c10f2/<имя_образа>/tags/list | jq '.tags | sort'
</pre>
Например список версий образа <code>kube-apiserver</code> выглядит следующим образом:
<pre>
$ curl -s  http://registry.local/v2/k8s-c10f2/kube-apiserver/tags/list | jq '.tags | sort'
[
  "v1.27.16",
  "v1.28.14",
  "v1.29.9",
  "v1.30.5",
  "v1.31.1"
]
</pre>
 
Файл архива <code>amd64_27-31_tar.xz</code> после успешного размещения образов можно удалить.
 
==== Добавление в http-сервер sigstore.local промежуточных kubernetes rpm-пакетов ====
 
Для добавления промежуточных <code>kubernetes rpm-пакетов</code> необходимо на сервере с доменом <code>sistore.local</code> перейти в каталог <code>/var/sigstore</code> и развернуть в нем архив <code>kuberRPMS_1.27-1.31.tgz</code>:
<pre>
# cd /var/sigstore
# tar xvzf .../kuberRPMS_1.27-1.31.tgz
dr-xr-xr-x root/root        0 2024-12-22 13:22 ALTLinux/
dr-xr-xr-x root/root        0 2024-12-22 13:22 ALTLinux/base/
-r--r--r-- root/root    74808 2024-12-22 13:22 ALTLinux/base/pkglist.main
-r--r--r-- root/root    10628 2024-12-22 13:22 ALTLinux/base/pkglist.main.xz
-r--r--r-- root/root      123 2024-12-22 13:22 ALTLinux/base/release.main
-r--r--r-- root/root    13117 2024-12-22 13:22 ALTLinux/base/pkglist.main.bz2
-r--r--r-- root/root      1045 2024-12-22 13:22 ALTLinux/base/release
dr-xr-xr-x root/root        0 2024-12-22 13:22 ALTLinux/RPMS.main/
-r--r--r-- root/root      8290 2024-12-22 13:22 ALTLinux/RPMS.main/kubernetes1.27-common-1.27.16-alt1.noarch.rpm
-r--r--r-- root/root  50665903 2024-12-22 13:22 ALTLinux/RPMS.main/kubernetes1.30-master-1.30.5-alt1.x86_64.rpm
...
</pre>
 
==== Модификация настроек apt для обновления rpm-пакетов ====
 
Кроме развертывания промежуточных образов из docker-регистратора <code>registry.local</code> при обновлении кластера необходимо на всех узлах кластера добавить в <code>apt</code> доступ к репохторию пакетов промежуточных команд <code>kubelet</code>,  <code>kubeadm</code>, <code>crctl</code>, <code>cri-o</code>, <code>...</code>. 
 
Для этого На всех узлах кластера выполните нижеперечисленные операции.
 
Наберите команду
<pre>
# apt-repo
</pre>
и найдите  строку начинающуюся с <code>rpm cdrom</code>:
<pre>
rpm cdrom:[ALT SP Server 11100-01 x86_64 build 2023-05-29]/ ALTLinux main
</pre>
Если строка присутствует - удалите ее:
<pre>
apt-repo rm 'rpm cdrom:[ALT SP Server 11100-01 x86_64 build 2023-05-29]/ ALTLinux main'
</pre>
 
Добавьте описание дерева <code>RPM-пакетов</code>, развернутых на сервере с доменом <code>sigstore.local</code> и доступных через WEB-сервер на порту <code>81</code>:
<pre>
apt-repo add 'rpm http://sigstore.local:81/ALTLinux . main'
</pre>
 
Обновите локальный список пакетов:
<pre>
# apt-get update
</pre>
<pre>
Получено: 1 http://sigstore.local . release [1045B]
Получено 1045B за 0s (0B/s).
Найдено http://sigstore.local ./main pkglist
Найдено http://sigstore.local ./main release
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
</pre>
 
Проверьте наличие пакетов версий <code>1.27</code>, <code>1.28</code>, <code>...</code>, <code>1.31</code>:
<pre>
# apt-cache search kubernetes
</pre>
<pre>
kubernetes1.27-client - Kubernetes client tools
kubernetes1.27-common - Kubernetes common files
kubernetes1.27-crio - Kubernetes crio files
kubernetes1.27-kubeadm - Kubernetes tool for standing up clusters
kubernetes1.27-kubelet - Kubernetes kubelet daemon
kubernetes1.27-master - Kubernetes services for master host
kubernetes1.27-node - Kubernetes services for node host
...
kubernetes1.31-client - Kubernetes client tools
kubernetes1.31-common - Kubernetes common files
kubernetes1.31-crio - Kubernetes crio files
kubernetes1.31-kubeadm - Kubernetes tool for standing up clusters
kubernetes1.31-kubelet - Kubernetes kubelet daemon
kubernetes1.31-master - Kubernetes services for master host
kubernetes1.31-node - Kubernetes services for node host
</pre>
 
==== Настройка доступа к кластеру на worker-узлах ====
 
По умолчанию после развертывания worker-узла на нем не инициализируется файл `/root/.kube/config` обеспечивающий доступ к кластеру командой `kubectl`.
Для обновления кластера необходимо скопировать этот файл с одного из `controlPlane` узла.
Для этого:
 
* на одном из `controlPlane`-узле установите пароль для пользователя `u7s-admin`:
<pre>
# passwd u7s-admin
</pre>
 
* на всех `worker`-узлах скопируйте config-файл с `controlPlane` узла:
<pre>
# scp u7s-admin@<IP-адрес_controlPlane`_узла>:~u7s-admin/.kube/config /root/.kube/
</pre>
 
=== Обновление кластера ===
 
==== Обновление пакетов и образов ====
 
Для обновления кластера необходимо на все узлы кластера поставить пакет <code>podsec-upgrade</code> версии не ниже <code>1.2.3-alt1</code>.
 
После установки пакета необходимо определить имя <code>control-plane</code> узла с которого начиналось разворачивание кластера.
Это имя должно входить в список узлов, выводимый командой
<pre>
# kubectl get nodes
</pre>
 
Для обновления кластера необходимо на всех узлах кластера запустить команду:
<pre>
# podsec-k8s-upgrade-kuber <masterNodeName> [finalVersion]
</pre>
 
где:
* <code>'''masterNodeName'''</code> - имя <code>control-plane</code> узла с которого начиналось разворачивание кластера;
* <code>finalVersion</code> - минорная версия <code>kubernetes</code> до которой необходимо обновить кластер.
 
Если версия <code>finalVersion</code> не указана, обновление производится до последней доступной версией на регистраторе <code>registry.local</code>.
 
''В настоящее время (<code>9.01.2025</code>) скрипт обеспечивает устойчивое оббновление до версии <code>1.30</code>.''
 
В зависимости от типа узла скрипт обеспечивает следующий порядок обновления программного обеспечения узлов:
 
* <code>control-plane</code> узел с которого начиналось разворачивание (<code>master-узел</code>);
* остальные узлы кластера.
 
<code>Master-узел</code> перед обновлением до следующей минорной версии <code>kubernetes</code> ожидает пока на всех остальных узлах кластера  не будет развернута минорная версия <code>kubernetes</code> следующая  или равная текущей версии.
Например, если текущая развернутая версия <code>master-узла</code> равна <code>1.28</code>, обновление до версии <code>1.29</code> <code>master-узла</code> задерживается до обновлении всех узлов кластера до версий <code>1.28</code> или <code>1.29</code>.
 
Остальные узлы кластера перед обновлением до следующей минорной версии <code>kubernetes</code> ожидают пока на <code>master-узле</code> не будет развернута версия минорная версия <code>kubernetes<code> следующая  или равная текущей версии обновляемого узла.
Например, если текущая развернутая версия <code>узла</code> равна <code>1.28</code>, обновление до версии <code>1.29</code> <code>master-узла</code> задерживается до обновлении <code>master-узла</code> до версии <code>1.28</code>  или <code>1.29</code>.
 
Этот алгоритм обеспечивает синхронное обновление всех узлов кластера с соблюдением условия, что номера минорных версии узлов кластера не различаются более чем на одну версию.
 
При обновлении <code>control-plane</code> узлов обновляются как пакеты (kubelet, kubeadm, cri-o, зависимые пакеты), так и POD'ы новых kubernetes-образов (<code>kube-apiserver</code>, <code>kube-controller-manager</code>, <code>kube-scheduler</code>, <code>etcd</code>, <code>coredns</code>).
 
При обновлении <code>worker</code> узлов обновляются только пакеты (kubelet, kubeadm, cri-o, зависимые пакеты).
Обновление <code>daemon-set</code> POD'ов (<code>kube-proxy</code>, <code>flannel</code>) производится централизовано при обновлении соответствующих <code>daemon-set</code> на <code>master-узле</code>.
 
При обновлении в любой момент времени обновляться может только один узел кластера. Это достигается путем перевода узла в состояние <code>cordon</code> командой:
<pre>
kubctl cordon <nodeName>
</pre>
 
После выполнения этой команды все POD'ы типа <code>daemonset</code> или <replicaset</code> мигрируют на остальные узлы кластера. Для облегчения этого процесса на всех <code>control-plane</code> узлах кластера обеспечивается возможность запуска обычных POD'ов командой:
<pre>
kubectl taint nodes <host> node-role.kubernetes.io/control-plane:NoSchedule-
</pre>
 
Перед переводом узла в состояние <code>cordon</code> проверяется наличие в кластере узлов в этом же состоянии.
Узел переводится в состояние <code>cordon</code> только в том случае, когда в кластере нет узлов с этим состоянием.
 
При обновлении до версий старше <code>1.29</code> перед обновлением основных kubernetes-пакетов и перезапуске узла удаляются все POD'ы узла.
 
После перезапуска kubernet-сервисов узла командой
<pre>
systemctl start u7s
</pre>
узел переводится в состояние <code>uncordon</code>.
 
Кроме этого на <code>master-узле</code> производятся следующие дополнительный действия:
* При обновлении до минорных версий старше <code>1.26</code> версия образа <code>flannel</code> и его <code>deploy</code> меняется до версии <code>0.25.1</code>. <code>flannel</code> запускается как <code>daemonset</code>. Так что его обновление на  <code>master-узле</code> приводит к его обновлению на всех узлах кластера.
* При обновлении проверяется значение <code>imageRepository</code> <code>configmap kubeadm-config</code> кластера. Если его значение не совпадает с  <code>registry.local/k8s-c10f2</code> устанавливается данное значение.
 
* Для минорных версий старше <code>1.30</code> версия образа <code>pause</code> меняется с <code>3.9</code> на <code>3.10</code>.
 
==== Обновление версии podsec ====

Текущая версия от 17:11, 9 января 2025

Описание скриптов обновления kubernetes с версии 1.26

Скрипты обновления rootless kubernetes

Механизм обновления kubernetes-кластера не позволяет проводить обновление узлов кластера с пропуском промежуточных версий. Например, чтобы обновить узлы кластера с минорной версии 1.26 до минорной версии 1.31 необходимо последовательно и синхронизировано обновить узлы через промежуточные версии 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31. Причем при обновлении необходимо, чтобы минорные версии всех обновляемых узлов были соседними. Не допускается, например, обновление программного обеспечения узла с версии 1.27 до версии 1.28, если в кластере есть узлы с версией 1.26.

Таким образом для обновления узлов кластера с версии 1.26 до версии 1.28 узла кластера должны в рамках локальной сети иметь доступ как к промежуточным версиям RPM-пакетам kubernetes, так и к промежуточным версиям docker-образов kuberbetes.

Промежуточные версии RPM-пакетов kubernetes размещаются на узле с внутренним доменным именем sigstore.local. Промежуточные версии docker-образов kuberbetes размещаются на узле с внутренним доменным именем registry.local. Обычно при стандартном разворачивании это один и тот же узел, с которого начиналось разворачивание кластера.

Подготовка узлов кластера без доступа в Интернет для обновления rootless kubernetes

Для обновления kubernetes в сети без доступа в Интернет необходимо наличие следующих архивов:

  • amd64_27-31_tar.xz - архив docker-образов всех промежуточных версий;
  • kuberRPMS_1.27-1.31.tgzrpm-пакетов kubelet, kubeadm, cri-o и зависимых пакетов всех промежуточных версий.

Добавление в локальный регистратор registry.local промежуточных docker образов kubernetes

Файл архива amd64_27-31_tar.xz необходимо разместить на узле с доменом sigstore.local в домашнем каталоге пользователя входящим в группуpodman_dev (обычно это пользователь imagemaker).

Для выкатывания промежуточных docker-образов в локальный регистратор registry.local необходимо зайти в пользователя imagemaker (вход через su- imagemaker недопускается) и набрать команду разворачивания архива, подписи образов и передачи их в регистратор: 

$ podsec-load-sign-oci ./amd64_27-31_tar.xz amd64 <E-mail_подписанта> registry.local/k8s-c10f2

После завершения команды (это может составить несколько минут) проверить наличие добавленных образов на регистраторе можно командой 

curl -s  http://registry.local/v2/_catalog | jq .
{
  "repositories": [
    "k8s-c10f1/...,
    "k8s-c10f2/coredns",
    "k8s-c10f2/etcd",
    "k8s-c10f2/flannel",
    "k8s-c10f2/flannel-cni-plugin",
    "k8s-c10f2/kube-apiserver",
    "k8s-c10f2/kube-controller-manager",
    "k8s-c10f2/kube-proxy",
    "k8s-c10f2/kube-scheduler",
    "k8s-c10f2/pause"
  ]
}

В списке должны присутствовать вышеперечисленные образы с префиксом k8s-c10f2/....

Получить список тегов (kubernetes-версий) образов образов можно командой: 

curl -s  http://registry.local/v2/k8s-c10f2/<имя_образа>/tags/list | jq '.tags | sort'

Например список версий образа kube-apiserver выглядит следующим образом: 

$ curl -s  http://registry.local/v2/k8s-c10f2/kube-apiserver/tags/list | jq '.tags | sort'
[
  "v1.27.16",
  "v1.28.14",
  "v1.29.9",
  "v1.30.5",
  "v1.31.1"
]

Файл архива amd64_27-31_tar.xz после успешного размещения образов можно удалить.

Добавление в http-сервер sigstore.local промежуточных kubernetes rpm-пакетов

Для добавления промежуточных kubernetes rpm-пакетов необходимо на сервере с доменом sistore.local перейти в каталог /var/sigstore и развернуть в нем архив kuberRPMS_1.27-1.31.tgz: 

# cd /var/sigstore
# tar xvzf .../kuberRPMS_1.27-1.31.tgz
dr-xr-xr-x root/root         0 2024-12-22 13:22 ALTLinux/
dr-xr-xr-x root/root         0 2024-12-22 13:22 ALTLinux/base/
-r--r--r-- root/root     74808 2024-12-22 13:22 ALTLinux/base/pkglist.main
-r--r--r-- root/root     10628 2024-12-22 13:22 ALTLinux/base/pkglist.main.xz
-r--r--r-- root/root       123 2024-12-22 13:22 ALTLinux/base/release.main
-r--r--r-- root/root     13117 2024-12-22 13:22 ALTLinux/base/pkglist.main.bz2
-r--r--r-- root/root      1045 2024-12-22 13:22 ALTLinux/base/release
dr-xr-xr-x root/root         0 2024-12-22 13:22 ALTLinux/RPMS.main/
-r--r--r-- root/root      8290 2024-12-22 13:22 ALTLinux/RPMS.main/kubernetes1.27-common-1.27.16-alt1.noarch.rpm
-r--r--r-- root/root  50665903 2024-12-22 13:22 ALTLinux/RPMS.main/kubernetes1.30-master-1.30.5-alt1.x86_64.rpm
...

Модификация настроек apt для обновления rpm-пакетов

Кроме развертывания промежуточных образов из docker-регистратора registry.local при обновлении кластера необходимо на всех узлах кластера добавить в apt доступ к репохторию пакетов промежуточных команд kubelet, kubeadm, crctl, cri-o, ....

Для этого На всех узлах кластера выполните нижеперечисленные операции.

Наберите команду 

# apt-repo

и найдите строку начинающуюся с rpm cdrom: 

rpm cdrom:[ALT SP Server 11100-01 x86_64 build 2023-05-29]/ ALTLinux main

Если строка присутствует - удалите ее: 

apt-repo rm 'rpm cdrom:[ALT SP Server 11100-01 x86_64 build 2023-05-29]/ ALTLinux main'

Добавьте описание дерева RPM-пакетов, развернутых на сервере с доменом sigstore.local и доступных через WEB-сервер на порту 81: 

apt-repo add 'rpm http://sigstore.local:81/ALTLinux . main'

Обновите локальный список пакетов: 

# apt-get update

Получено: 1 http://sigstore.local . release [1045B]
Получено 1045B за 0s (0B/s).
Найдено http://sigstore.local ./main pkglist
Найдено http://sigstore.local ./main release
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено

Проверьте наличие пакетов версий 1.27, 1.28, ..., 1.31: 

# apt-cache search kubernetes

kubernetes1.27-client - Kubernetes client tools
kubernetes1.27-common - Kubernetes common files
kubernetes1.27-crio - Kubernetes crio files
kubernetes1.27-kubeadm - Kubernetes tool for standing up clusters
kubernetes1.27-kubelet - Kubernetes kubelet daemon
kubernetes1.27-master - Kubernetes services for master host
kubernetes1.27-node - Kubernetes services for node host
...
kubernetes1.31-client - Kubernetes client tools
kubernetes1.31-common - Kubernetes common files
kubernetes1.31-crio - Kubernetes crio files
kubernetes1.31-kubeadm - Kubernetes tool for standing up clusters
kubernetes1.31-kubelet - Kubernetes kubelet daemon
kubernetes1.31-master - Kubernetes services for master host
kubernetes1.31-node - Kubernetes services for node host

Настройка доступа к кластеру на worker-узлах

По умолчанию после развертывания worker-узла на нем не инициализируется файл `/root/.kube/config` обеспечивающий доступ к кластеру командой `kubectl`. Для обновления кластера необходимо скопировать этот файл с одного из `controlPlane` узла. Для этого:

  • на одном из `controlPlane`-узле установите пароль для пользователя `u7s-admin`:
# passwd u7s-admin
  • на всех `worker`-узлах скопируйте config-файл с `controlPlane` узла:
# scp u7s-admin@<IP-адрес_controlPlane`_узла>:~u7s-admin/.kube/config /root/.kube/

Обновление кластера

Обновление пакетов и образов

Для обновления кластера необходимо на все узлы кластера поставить пакет podsec-upgrade версии не ниже 1.2.3-alt1.

После установки пакета необходимо определить имя control-plane узла с которого начиналось разворачивание кластера. Это имя должно входить в список узлов, выводимый командой 

# kubectl get nodes

Для обновления кластера необходимо на всех узлах кластера запустить команду: 

# podsec-k8s-upgrade-kuber <masterNodeName> [finalVersion]

где:

  • masterNodeName - имя control-plane узла с которого начиналось разворачивание кластера;
  • finalVersion - минорная версия kubernetes до которой необходимо обновить кластер.

Если версия finalVersion не указана, обновление производится до последней доступной версией на регистраторе registry.local.

В настоящее время (9.01.2025) скрипт обеспечивает устойчивое оббновление до версии 1.30.

В зависимости от типа узла скрипт обеспечивает следующий порядок обновления программного обеспечения узлов:

  • control-plane узел с которого начиналось разворачивание (master-узел);
  • остальные узлы кластера.

Master-узел перед обновлением до следующей минорной версии kubernetes ожидает пока на всех остальных узлах кластера не будет развернута минорная версия kubernetes следующая или равная текущей версии. Например, если текущая развернутая версия master-узла равна 1.28, обновление до версии 1.29 master-узла задерживается до обновлении всех узлов кластера до версий 1.28 или 1.29.

Остальные узлы кластера перед обновлением до следующей минорной версии kubernetes ожидают пока на master-узле не будет развернута версия минорная версия kubernetes следующая или равная текущей версии обновляемого узла. Например, если текущая развернутая версия узла равна 1.28, обновление до версии 1.29 master-узла задерживается до обновлении master-узла до версии 1.28 или 1.29.

Этот алгоритм обеспечивает синхронное обновление всех узлов кластера с соблюдением условия, что номера минорных версии узлов кластера не различаются более чем на одну версию.

При обновлении control-plane узлов обновляются как пакеты (kubelet, kubeadm, cri-o, зависимые пакеты), так и POD'ы новых kubernetes-образов (kube-apiserver, kube-controller-manager, kube-scheduler, etcd, coredns).

При обновлении worker узлов обновляются только пакеты (kubelet, kubeadm, cri-o, зависимые пакеты). Обновление daemon-set POD'ов (kube-proxy, flannel) производится централизовано при обновлении соответствующих daemon-set на master-узле.

При обновлении в любой момент времени обновляться может только один узел кластера. Это достигается путем перевода узла в состояние cordon командой: 

kubctl cordon <nodeName>

После выполнения этой команды все POD'ы типа daemonset или <replicaset мигрируют на остальные узлы кластера. Для облегчения этого процесса на всех control-plane узлах кластера обеспечивается возможность запуска обычных POD'ов командой: 

kubectl taint nodes <host> node-role.kubernetes.io/control-plane:NoSchedule-

Перед переводом узла в состояние cordon проверяется наличие в кластере узлов в этом же состоянии. Узел переводится в состояние cordon только в том случае, когда в кластере нет узлов с этим состоянием.

При обновлении до версий старше 1.29 перед обновлением основных kubernetes-пакетов и перезапуске узла удаляются все POD'ы узла.

После перезапуска kubernet-сервисов узла командой 

systemctl start u7s

узел переводится в состояние uncordon.

Кроме этого на master-узле производятся следующие дополнительный действия:

  • При обновлении до минорных версий старше 1.26 версия образа flannel и его deploy меняется до версии 0.25.1. flannel запускается как daemonset. Так что его обновление на master-узле приводит к его обновлению на всех узлах кластера.
  • При обновлении проверяется значение imageRepository configmap kubeadm-config кластера. Если его значение не совпадает с registry.local/k8s-c10f2 устанавливается данное значение.
  • Для минорных версий старше 1.30 версия образа pause меняется с 3.9 на 3.10.

Обновление версии podsec