Переконфігурація кластера за допомогою kubeadm

kubeadm не підтримує автоматизованих способів переконфігурації компонентів, що були розгорнуті на керованих вузлах. Один зі способів автоматизації цього — використання власного оператора.

Для зміни конфігурації компонентів вам потрібно вручну редагувати повʼязані обʼєкти кластера та файли на диску.

Цей посібник показує правильну послідовність кроків, які потрібно виконати для досягнення переконфігурації кластера kubeadm.

Перш ніж ви розпочнете

  • Вам потрібен кластер, що був розгорнутий за допомогою kubeadm.
  • У вас мають бути адміністративні облікові дані (/etc/kubernetes/admin.conf) та мережеве зʼєднання з робочим kube-apiserver у кластері з хосту, на якому встановлено kubectl.
  • Мати текстовий редактор встановлений на всіх хостах.

Переконфігурація кластера

kubeadm записує набір параметрів конфігурації компонентів на рівні кластера у ConfigMaps та в інших обʼєктах. Ці обʼєкти потрібно редагувати вручну. Команда kubectl edit може бути використана для цього.

Команда kubectl edit відкриє текстовий редактор, в якому ви можете редагувати та зберегти обʼєкт безпосередньо.

Ви можете використовувати змінні середовища KUBECONFIG та KUBE_EDITOR для вказівки розташування файлу kubeconfig, який використовується kubectl, та обраного текстового редактора.

Наприклад:

KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <параметри>

Примітка:

Після збереження будь-яких змін у цих обʼєктах кластера, компоненти, що працюють на вузлах, можуть не оновлюватись автоматично. У нижченаведених кроках вказано, як це зробити вручну.

Попередження:

Конфігурація компонентів у ConfigMaps зберігається як неструктуровані дані (рядки YAML). Це означає, що перевірка правильності не буде проводитися при оновленні вмісту ConfigMap. Вам потрібно бути обережними та слідувати документованому формату API для певної конфігурації компонента, а також уникати друкарських помилок та помилок у відступах в YAML.

Застосування змін у конфігурації кластера

Оновлення ClusterConfiguration

Під час створення кластера та його оновлення, kubeadm записує ClusterConfiguration у ConfigMap, з назвою kubeadm-config у просторі імен kube-system.

Щоб змінити певну опцію у ClusterConfiguration, ви можете редагувати ConfigMap за допомогою цієї команди:

kubectl edit cm -n kube-system kubeadm-config

Конфігурація знаходиться в ключі data.ClusterConfiguration.

Примітка:

ClusterConfiguration включає різноманітні параметри, які впливають на конфігурацію окремих компонентів, таких як kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd та kube-proxy. Зміни в конфігурації повинні бути віддзеркалені в компонентах вузла вручну.

Віддзеркалення змін ClusterConfiguration на вузлах панелі управління

kubeadm керує компонентами панелі управління як статичними маніфестами Pod, які розташовані в теці /etc/kubernetes/manifests. Будь-які зміни у ClusterConfiguration в ключах apiServer, controllerManager, scheduler або etcd повинні віддзеркалюватись у відповідних файлах у теці маніфестів на вузлі панелі управління.

Такі зміни можуть включати:

  • extraArgs — потребує оновлення списку прапорців, які передаються контейнеру компонента
  • extraVolumes — потребує оновлення точок монтування для контейнера компонента
  • *SANs — потребує написання нових сертифікатів з Subject Alternative Names.

Перед продовженням цих змін переконайтеся, що ви зробили резервну копію теки /etc/kubernetes/.

Для написання нових сертифікатів ви можете використовувати:

kubeadm init phase certs <component-name> --config <config-file>

Для написання нових файлів маніфестів у теці /etc/kubernetes/manifests ви можете використовувати:

# Для компонентів панелі управління Kubernetes
kubeadm init phase control-plane <component-name> --config <config-file>
# Для локального etcd
kubeadm init phase etcd local --config <config-file>

Зміст <config-file> повинен відповідати оновленням в ClusterConfiguration. Значення <component-name> повинно бути імʼям компонента панелі управління Kubernetes (apiserver, controller-manager або scheduler).

Примітка:

Оновлення файлу у /etc/kubernetes/manifests призведе до перезапуску статичного Podʼа для відповідного компонента. Спробуйте робити ці зміни один за одним на вузлі, щоб не переривати роботу кластера.

Застосування змін конфігурації kubelet

Оновлення KubeletConfiguration

Під час створення кластера та оновлення, kubeadm записує KubeletConfiguration у ConfigMap з назвою kubelet-config в просторі імен kube-system.

Ви можете редагувати цей ConfigMap за допомогою такої команди:

kubectl edit cm -n kube-system kubelet-config

Конфігурація розташована в ключі data.kubelet.

Віддзеркалення змін в kubelet

Щоб віддзеркалити зміни на вузлах kubeadm, вам потрібно виконати наступне:

  • Увійдіть на вузол kubeadm.
  • Виконайте команду kubeadm upgrade node phase kubelet-config, щоб завантажити свіжий вміст kubelet-config ConfigMap в локальний файл /var/lib/kubelet/config.yaml.
  • Відредагуйте файл /var/lib/kubelet/kubeadm-flags.env, щоб застосувати додаткову конфігурацію за допомогою прапорців.
  • Перезапустіть службу kubelet за допомогою systemctl restart kubelet.

Примітка:

Виконуйте ці зміни по одному вузлу за раз, щоб дозволити належне перепланування робочих навантажень.

Примітка:

Під час оновлення kubeadm, kubeadm завантажує KubeletConfiguration з ConfigMap kubelet-config і перезаписує вміст /var/lib/kubelet/config.yaml. Це означає, що локальна конфігурація вузла повинна бути застосована або за допомогою прапорців у /var/lib/kubelet/kubeadm-flags.env, або шляхом ручного оновлення вмісту /var/lib/kubelet/config.yaml після kubeadm upgrade, з подальшим перезапуском kubelet.

Застосування змін у конфігурації kube-proxy

Оновлення KubeProxyConfiguration

Під час створення кластера та оновлення, kubeadm записує KubeProxyConfiguration у ConfigMap в просторі імен kube-system з назвою kube-proxy.

Цей ConfigMap використовується DaemonSet kube-proxy в просторі імен kube-system.

Щоб змінити певну опцію в KubeProxyConfiguration, ви можете відредагувати ConfigMap за допомогою цієї команди:

kubectl edit cm -n kube-system kube-proxy

Конфігурація знаходиться в ключі data.config.conf.

Віддзеркалення змін у kube-proxy

Після оновлення ConfigMap kube-proxy, ви можете перезапустити всі Podʼи kube-proxy:

Видаліть Podʼи за допомогою:

kubectl delete po -n kube-system -l k8s-app=kube-proxy

Створюватимуться нові Podʼи, які використовують оновлений ConfigMap.

Примітка:

Оскільки kubeadm розгортає kube-proxy як DaemonSet, конфігурація, специфічна для вузла, не підтримується.

Застосування змін конфігурації CoreDNS

Оновлення розгортання CoreDNS та сервісу

kubeadm розгортає CoreDNS як Deployment з назвою coredns та Service з назвою kube-dns, обидва у просторі імен kube-system.

Для оновлення будь-яких налаштувань CoreDNS ви можете редагувати обʼєкти Deployment та Service:

kubectl edit deployment -n kube-system coredns
kubectl edit service -n kube-system kube-dns

Віддзеркалення змін у CoreDNS

Після застосування змін у CoreDNS ви можете перезапустити його deployment:

kubectl rollout restart deployment -n kube-system coredns

Примітка:

kubeadm не дозволяє налаштування CoreDNS під час створення та оновлення кластера. Це означає, що якщо ви виконаєте kubeadm upgrade apply, ваші зміни в обʼєктах CoreDNS будуть втрачені та мають бути застосовані повторно.

Збереження переконфігурації

Під час виконання команди kubeadm upgrade на керованому вузлі kubeadm може перезаписати конфігурацію, яка була застосована після створення кластера (переконфігурація).

Збереження переконфігурації обʼєкту Node

kubeadm записує Labels, Taints, сокенти CRI та іншу інформацію в обʼєкті Node для конкретного вузла Kubernetes. Для зміни будь-якого змісту цього обʼєкта Node ви можете використовувати:

kubectl edit no <імʼя-вузла>

Під час виконання kubeadm upgrade вміст такого Node може бути перезаписаний. Якщо ви бажаєте зберегти свої зміни в обʼєкті Node після оновлення, ви можете підготувати команду патча для kubectl і застосувати її до обʼєкта Node:

kubectl patch no <імʼя-вузла> --patch-file <файл-патча>

Збереження переконфігурації компонента панелі управління

Основним джерелом конфігурації панелі управління є обʼєкт ClusterConfiguration, збережений у кластері. Для розширення конфігурації статичних маніфестів Podʼів можна використовувати патчі.

Ці файли патчів повинні залишатися як файли на вузлах панелі управління, щоб забезпечити можливість їх використання командою kubeadm upgrade ... --patches <directory>.

Якщо переконфігурування виконується для ClusterConfiguration і статичних маніфестів Podʼів на диску, то набір патчів для конкретного вузла повинен бути відповідно оновлений.

Збереження переконфігурації kubelet

Будь-які зміни в KubeletConfiguration, збережені у /var/lib/kubelet/config.yaml, будуть перезаписані під час виконання kubeadm upgrade, завантажуючи вміст конфігурації kubelet-config ConfigMap для всього кластера. Для збереження конфігурації kubelet для Node потрібно або вручну змінити файл /var/lib/kubelet/config.yaml після оновлення, або файл /var/lib/kubelet/kubeadm-flags.env може містити прапорці. Прапорці kubelet перевизначають відповідні параметри KubeletConfiguration, але слід зауважити, що деякі з прапорців є застарілими.

Після зміни /var/lib/kubelet/config.yaml або /var/lib/kubelet/kubeadm-flags.env потрібен перезапуск kubelet.

Що далі


Змінено March 09, 2026 at 3:31 PM PST: [uk] Ukrainian translation (all-in-one) (085108619a)