kubeadm init

Ця команда ініціалізує вузол панелі управління Kubernetes.

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує такі фази:

preflight                     Run pre-flight checks
certs                         Certificate generation
  /ca                           Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
  /apiserver                    Generate the certificate for serving the Kubernetes API
  /apiserver-kubelet-client     Generate the certificate for the API server to connect to kubelet
  /front-proxy-ca               Generate the self-signed CA to provision identities for front proxy
  /front-proxy-client           Generate the certificate for the front proxy client
  /etcd-ca                      Generate the self-signed CA to provision identities for etcd
  /etcd-server                  Generate the certificate for serving etcd
  /etcd-peer                    Generate the certificate for etcd nodes to communicate with each other
  /etcd-healthcheck-client      Generate the certificate for liveness probes to healthcheck etcd
  /apiserver-etcd-client        Generate the certificate the apiserver uses to access etcd
  /sa                           Generate a private key for signing service account tokens along with its public key
kubeconfig                    Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
  /admin                        Generate a kubeconfig file for the admin to use and for kubeadm itself
  /super-admin                  Generate a kubeconfig file for the super-admin
  /kubelet                      Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
  /controller-manager           Generate a kubeconfig file for the controller manager to use
  /scheduler                    Generate a kubeconfig file for the scheduler to use
etcd                          Generate static Pod manifest file for local etcd
  /local                        Generate the static Pod manifest file for a local, single-node local etcd instance
control-plane                 Generate all static Pod manifest files necessary to establish the control plane
  /apiserver                    Generates the kube-apiserver static Pod manifest
  /controller-manager           Generates the kube-controller-manager static Pod manifest
  /scheduler                    Generates the kube-scheduler static Pod manifest
kubelet-start                 Write kubelet settings and (re)start the kubelet
wait-control-plane            Wait for the control plane to start
upload-config                 Upload the kubeadm and kubelet configuration to a ConfigMap
  /kubeadm                      Upload the kubeadm ClusterConfiguration to a ConfigMap
  /kubelet                      Upload the kubelet component config to a ConfigMap
upload-certs                  Upload certificates to kubeadm-certs
mark-control-plane            Mark a node as a control-plane
bootstrap-token               Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize              Updates settings relevant to the kubelet after TLS bootstrap
  /enable-client-cert-rotation  Enable kubelet client certificate rotation
addon                         Install required addons for passing conformance tests
  /coredns                      Install the CoreDNS addon to a Kubernetes cluster
  /kube-proxy                   Install the kube-proxy addon to a Kubernetes cluster
show-join-command             Show the join command for control-plane and worker node

kubeadm init [flags]

Параметри

Параметри, успадковані від батьківських команд

Процес init

kubeadm init розгортає вузол панелі управління Kubernetes, виконуючи наступні кроки:

1. Виконує серію попередніх перевірок, щоб перевірити стан системи перед внесенням змін. Деякі перевірки лише видають попередження, інші вважаються помилками, і kubeadm припиняє роботу, доки проблема не буде виправлена або користувач не вкаже --ignore-preflight-errors=<list-of-errors>.

2. Генерує самопідписний CA для налаштування ідентифікаційних даних для кожного компонента в кластері. Користувач може надати свої власні сертифікат та/або ключ CA, помістивши їх у теку сертифікатів, налаштовану через --cert-dir (типово /etc/kubernetes/pki). Сертифікати API-сервера матимуть додаткові записи SAN для будь-яких аргументів --apiserver-cert-extra-sans, з приведенням до нижнього регістру за потреби.

3. Записує файли kubeconfig у /etc/kubernetes/ для kubelet, controller-manager та scheduler для підключення до API-сервера, кожен зі своїми ідентифікаційними даними. Також створюються додаткові файли kubeconfig: для kubeadm як адміністративної сутності (admin.conf) та для суперадміністратора, що може обходити RBAC (super-admin.conf).

4. Генерує маніфести статичних Podʼів для API-сервера, controller-manager та scheduler. Якщо зовнішній etcd не надано, створюється додатковий маніфест статичного Podʼа для etcd.

   Маніфести статичних Podʼів записуються у /etc/kubernetes/manifests; kubelet стежить за цією текою, щоб створити Podʼи під час запуску.

   Щойно Podʼи панелі управління будуть запущені та працюватимуть, процес kubeadm init може продовжитися.

5. Додає мітки та taint на вузол панелі управління, щоб жодні додаткові робочі навантаження не запускалися там.

6. Генерує токен, який додаткові вузли зможуть використовувати в майбутньому для реєстрації в панелі управління. За бажанням користувач може надати токен через --token, як описано в документації kubeadm token.

7. Виконує всі необхідні налаштування, щоб дозволити приєднання вузлів за допомогою механізму токенів bootstrap та TLS Bootstrap:

   • Записує ConfigMap, що надає всю необхідну для приєднання інформацію, та налаштовує відповідні правила доступу RBAC.

   • Надає токенам bootstrap доступ до API підписання CSR.

   • Налаштовує автоматичне схвалення нових запитів CSR.

   Див. kubeadm join для додаткової інформації.

8. Встановлює DNS-сервер (CoreDNS) та компоненти надбудови kube-proxy через API-сервер. Зверніть увагу, що хоча DNS-сервер розгорнуто, він не буде запланований до встановлення CNI.

Використання фаз init з kubeadm

kubeadm дозволяє створювати вузол панелі управління поетапно, використовуючи команду kubeadm init phase.

Щоб переглянути впорядкований список фаз та підфаз, можна викликати kubeadm init --help. Список буде розташований на початку екрана довідки, і кожна фаза матиме опис поруч із нею. Зверніть увагу, що під час виклику kubeadm init всі фази та підфази будуть виконані саме в такому порядку.

Деякі фази мають унікальні прапорці, тому, якщо ви хочете переглянути список доступних опцій, додайте --help, наприклад:

sudo kubeadm init phase control-plane controller-manager --help

Ви також можете використовувати --help, щоб побачити список підфаз для певної батьківської фази:

sudo kubeadm init phase control-plane --help

kubeadm init також має прапорець --skip-phases, який можна використовувати для пропуску певних фаз. Прапорець приймає список назв фаз, які можна взяти з вищезгаданого впорядкованого списку.

Приклад:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# тепер ви можете змінити файли маніфестів панелі управління та etcd
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

Цей приклад записує файли маніфестів для панелі управління та etcd у /etc/kubernetes/manifests на основі конфігурації в configfile.yaml. Це дозволяє вам змінити файли, а потім пропустити ці фази, використовуючи --skip-phases. Викликом останньої команди ви створите вузол панелі управління з власними файлами маніфестів.

Як альтернативу, ви можете використовувати поле skipPhases у InitConfiguration.

Використання kubeadm init з конфігураційним файлом

Можна налаштувати kubeadm init за допомогою конфігураційного файлу замість прапорців командного рядка, а деякі розширені функції можуть бути доступні лише як опції конфігураційного файлу. Цей файл передається за допомогою прапорця --config, і він повинен містити структуру ClusterConfiguration і, за бажанням, інші структури, розділені ---\n. Поєднання --config з іншими прапорцями в деяких випадках може бути недозволеним.

Типову конфігурацію можна вивести за допомогою команди kubeadm config print.

Якщо ваша конфігурація не використовує останню версію, рекомендується мігрувати її за допомогою команди kubeadm config migrate.

Для отримання додаткової інформації про поля та використання конфігурації ви можете перейти на нашу сторінку довідки API.

Використання kubeadm init з функціональними можливостями

kubeadm підтримує набір функціональних можливостей (feature gates), які унікальні для kubeadm і можуть бути застосовані лише під час створення кластера за допомогою kubeadm init. Ці функції можуть керувати поведінкою кластера. Функціональні можливості видаляються після того, як функція переходить до стадії GA.

Щоб передати функціональну можливість, можна використати прапорець --feature-gates для kubeadm init або додати елементи до поля featureGates, коли ви передаєте конфігураційний файл за допомогою --config.

Передача функціональних можливостей для основних компонентів Kubernetes безпосередньо в kubeadm не підтримується. Натомість їх можна передати за допомогою налаштування компонентів за допомогою API kubeadm.

Список функціональних можливостей:

Опис функціональних можливостей:

RootlessControlPlane

Встановлення цього прапорця налаштовує контейнери статичних Podʼів компонентів панелі управління, розгорнутих kubeadm, для kube-apiserver, kube-controller-manager, kube-scheduler та etcd так, щоб вони запускалися від імені користувачів без прав root. Якщо прапорець не встановлено, ці компоненти запускаються з правами root. Ви можете змінити значення цієї функціональної можливості перед оновленням до новішої версії Kubernetes.

Список видалених функціональних можливостей:

Опис функціональних можливостей:

ControlPlaneKubeletLocalMode

З увімкненою функціональною можливістю під час приєднання нового вузла панелі управління kubeadm налаштовуватиме kubelet для підключення до локального kube-apiserver. Це гарантує, що під час поступових оновлень (rolling upgrades) не буде порушено політику розбіжності версій.

EtcdLearnerMode

Під час приєднання нового вузла панелі управління новий член etcd буде створений як учень (learner) і підвищений до члена з правом голосу лише після того, як дані etcd будуть повністю узгоджені.

IPv6DualStack

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

NodeLocalCRISocket

З увімкненою функціональною можливістю kubeadm читатиме/записуватиме CRI-сокет для кожного вузла з/до файлу /var/lib/kubelet/instance-config.yaml замість того, щоб читати/записувати його з/до анотації kubeadm.alpha.kubernetes.io/cri-socket в обʼєкті Node. Новий файл застосовується як патч конфігурації екземпляра перед застосуванням будь-яких інших патчів, керованих користувачем, коли використовується прапорець --patches. Він містить єдине поле containerRuntimeEndpoint з формату файлу KubeletConfiguration. Якщо функціональну можливість увімкнено під час оновлення, але файл /var/lib/kubelet/instance-config.yaml ще не існує, kubeadm спробує прочитати значення CRI-сокета з файлу /var/lib/kubelet/kubeadm-flags.env.

PublicKeysECDSA

Можна використовувати для створення кластера, який використовує сертифікати ECDSA замість типового алгоритму RSA. Поновлення наявних сертифікатів ECDSA також підтримується за допомогою kubeadm certs renew, але ви не можете перемикатися між алгоритмами RSA і ECDSA на льоту або під час оновлень. У версіях Kubernetes до v1.31 була помилка, через яку ключі у згенерованих файлах kubeconfig використовували RSA, навіть якщо ви увімкнули функціональну можливість PublicKeysECDSA. Ця функціональна можливість застаріла на користь функціональності encryptionAlgorithm, доступної у kubeadm v1beta4.

UnversionedKubeletConfigMap

Цей прапорець керує назвою ConfigMap, в якому kubeadm зберігає дані конфігурації kubelet. Якщо цей прапорець не вказано або встановлено в true, ConfigMap називається kubelet-config. Якщо ви встановите цей прапорець у false, назва ConfigMap міститиме мажорну та мінорну версію Kubernetes (наприклад: kubelet-config-1.37). kubeadm забезпечує, що правила RBAC для читання та запису цього ConfigMap відповідають значенню, яке ви встановили. Коли kubeadm записує цей ConfigMap (під час kubeadm init або kubeadm upgrade apply), kubeadm враховує значення UnversionedKubeletConfigMap. Під час читання цього ConfigMap (під час kubeadm join, kubeadm reset, kubeadm upgrade...) kubeadm спочатку намагається використати назву ConfigMap без версії. Якщо це не вдається, kubeadm повертається до використання застарілої (версійної) назви для цього ConfigMap.

UpgradeAddonsBeforeControlPlane

Цю функціональну можливість було видалено. Її було представлено у v1.28 як застарілу функцію, а потім видалено у v1.31. Для документації щодо старіших версій, будь ласка, перейдіть на відповідну версію вебсайту.

WaitForAllControlPlaneComponents

З увімкненою функціональною можливістю kubeadm чекатиме, доки всі компоненти панелі управління (kube-apiserver, kube-controller-manager, kube-scheduler) на вузлі панелі управління не повідомлять про стан 200 на своїх точках доступу /livez або /healthz. Ці перевірки виконуються на https://ADDRESS:PORT/ENDPOINT.

• PORT береться з --secure-port компонента.
• ADDRESS — це --advertise-address для kube-apiserver та --bind-address для kube-controller-manager та kube-scheduler.
• ENDPOINT — це лише /healthz для kube-controller-manager, доки він також не підтримуватиме /livez.

Якщо ви вкажете власні ADDRESS або PORT у конфігурації kubeadm, їх буде враховано. Без увімкненої функціональної можливості kubeadm чекатиме лише на готовність kube-apiserver на вузлі панелі управління. Процес очікування починається одразу після того, як kubeadm запустить kubelet на хості. Рекомендується увімкнути цю функціональну можливість, якщо ви бажаєте спостерігати стан готовності всіх компонентів панелі управління під час виконання команд kubeadm init або kubeadm join.

Додавання параметрів kube-proxy

Для отримання інформації про параметри kube-proxy у конфігурації kubeadm дивіться:

• Довідка kube-proxy

Для отримання інформації про увімкнення режиму IPVS за допомогою kubeadm дивіться:

• IPVS

Передача власних прапорців компонентам панелі управління

Для отримання інформації про передачу прапорців компонентам панелі управління дивіться:

• control-plane-flags

Використання kubeadm без підключення до Інтернету

Для запуску kubeadm без підключення до Інтернету необхідно попередньо завантажити потрібні образи панелі управління.

Ви можете отримати перелік та завантажити образи за допомогою підкоманди kubeadm config images:

kubeadm config images list
kubeadm config images pull

Ви можете передати --config вищенаведеним командам з файлом конфігурації kubeadm, щоб керувати полями kubernetesVersion та imageRepository.

Усі типові образи registry.k8s.io, необхідні kubeadm, підтримують кілька архітектур.

Використання власних образів

Типово kubeadm завантажує образи з registry.k8s.io. Якщо запитана версія Kubernetes є міткою CI (наприклад, ci/latest), використовується gcr.io/k8s-staging-ci-images.

Ви можете змінити цю поведінку, використовуючи kubeadm з файлом конфігурації. Дозволені налаштування:

• Вказати kubernetesVersion, що впливає на версію образів.
• Вказати альтернативний imageRepository, який буде використовуватися замість registry.k8s.io.
• Вказати конкретні imageRepository та imageTag для etcd або CoreDNS.

Шляхи образів у типовому registry.k8s.io та у власному репозиторії, вказаному за допомогою imageRepository, можуть відрізнятися з міркувань зворотної сумісності. Наприклад, образ може мати підшлях registry.k8s.io/subpath/image, але типово мати шлях my.customrepository.io/image під час використання власного репозиторію.

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

• Завантажити образи з типових шляхів у registry.k8s.io за допомогою kubeadm config images {list|pull}.
• Надіслати образи за шляхами з kubeadm config images list --config=config.yaml, де config.yaml містить власне значення imageRepository та/або imageTag для etcd та CoreDNS.
• Передати той самий config.yaml до kubeadm init.

Власні образи sandbox (pause)

Щоб встановити для них власний образ, потрібно налаштувати ваше середовище виконання контейнерів на використання цього образу. Зверніться до документації вашого середовища виконання контейнерів, щоб дізнатися, як змінити це налаштування; для деяких середовищ виконання контейнерів ви також можете знайти поради у розділі Середовища виконання контейнерів.

Завантаження сертифікатів панелі управління до кластера

Додавши прапорець --upload-certs до kubeadm init, ви можете тимчасово завантажити сертифікати панелі управління до Secret у кластері. Зверніть увагу, що термін дії цього Secret автоматично спливе через 2 години. Сертифікати шифруються за допомогою 32-байтного ключа, який можна задати за допомогою --certificate-key. Той самий ключ можна використовувати для завантаження сертифікатів під час приєднання додаткових вузлів панелі управління, передавши --control-plane та --certificate-key до kubeadm join.

Для повторного завантаження сертифікатів після закінчення їхнього терміну дії можна використовувати таку команду фази:

kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE

Якщо попередньо визначений ключ сертифіката не передано до kubeadm init і kubeadm init phase upload-certs, новий ключ буде згенеровано автоматично.

Для генерації нового ключа на вимогу можна використовувати таку команду:

kubeadm certs certificate-key

Управління сертифікатами за допомогою kubeadm

Докладну інформацію про управління сертифікатами за допомогою kubeadm дивіться в розділі Управління сертифікатами за допомогою kubeadm. Документ містить інформацію про використання зовнішнього центру сертифікації (CA), власних сертифікатів та поновлення сертифікатів.

Керування drop-in файлом kubeadm для kubelet

Пакет kubeadm постачається з файлом конфігурації для запуску kubelet через systemd. Зауважте, що CLI kubeadm ніколи не торкається цього drop-in файлу. Цей drop-in файл є частиною DEB/RPM-пакунка kubeadm.

Для отримання додаткової інформації дивіться Керування drop-in файлом kubeadm для systemd.

Використання kubeadm із середовищами виконання CRI

Типово kubeadm намагається виявити ваше середовище виконання контейнерів. Докладніше про це виявлення дивіться в посібнику зі встановлення CRI для kubeadm.

Встановлення імені вузла

Типово kubeadm призначає імʼя вузла на основі адреси хоста машини. Ви можете змінити це налаштування за допомогою прапорця --node-name. Цей прапорець передає відповідне значення --hostname-override до kubelet.

Майте на увазі, що перевизначення імені хоста може заважати роботі хмарних провайдерів.

Автоматизація kubeadm

Замість копіювання токена, який ви отримали з kubeadm init, на кожний вузол, як у базовому посібнику з kubeadm, ви можете розподіляти токен паралельно для полегшення автоматизації. Щоб реалізувати цю автоматизацію, вам потрібно знати IP-адресу, яку матиме вузол панелі управління після запуску, або використовувати DNS-імʼя чи адресу балансувальника навантаження.

1. Згенеруйте токен. Цей токен повинен мати форму <6 character string>.<16 character string>. Формально він повинен відповідати регулярному виразу: [a-z0-9]{6}\.[a-z0-9]{16}.

   kubeadm може згенерувати токен для вас:

   kubeadm token generate
   

2. Запустіть одночасно вузол панелі управління та робочі вузли з цим токеном. Під час запуску вони мають знайти один одного та сформувати кластер. Той самий аргумент --token можна використовувати як у kubeadm init, так і у kubeadm join.

3. Аналогічно можна вчинити з --certificate-key під час приєднання додаткових вузлів панелі управління. Ключ можна згенерувати за допомогою:

   kubeadm certs certificate-key
   

Щойно кластер запуститься, ви зможете використовувати файл /etc/kubernetes/admin.conf з вузла панелі управління для взаємодії з кластером з обліковими даними адміністратора або скористатися розділом Генерування файлів kubeconfig для додаткових користувачів.

Зауважте, що такий спосіб початкового розгортання має дещо послаблені гарантії безпеки, оскільки не дозволяє перевірити хеш кореневого CA за допомогою --discovery-token-ca-cert-hash (оскільки він не генерується під час підготовки вузлів). Докладніше дивіться в kubeadm join.

Що далі

• kubeadm init phase — щоб дізнатися більше про фази kubeadm init
• kubeadm join — щоб розгорнути робочий вузол Kubernetes і приєднати його до кластера
• kubeadm upgrade — щоб оновити кластер Kubernetes до новішої версії
• kubeadm reset — щоб скасувати будь-які зміни, внесені на цьому хості командами kubeadm init або kubeadm join