# kubeadm init

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

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

<!-- body -->


	<h3 id="synopsis">Опис<a class="td-heading-self-link" href="#synopsis" aria-label="Heading self-link"></a></h3>
<p>Запустіть цю команду, щоб налаштувати панель управління Kubernetes</p>
<p>Команда &quot;init&quot; виконує наступні етапи:</p>
<pre tabindex="0"><code class="language-none" data-lang="none">preflight                     Виконання перевірок перед запуском
certs                         Генерація сертифікатів
  /ca                           Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
  /apiserver                    Генерація сертифіката для обслуговування Kubernetes API
  /apiserver-kubelet-client     Генерація сертифіката для зʼєднання API server з kubelet
  /front-proxy-ca               Генерація самопідписаного CA для забезпечення ідентифікації front proxy
  /front-proxy-client           Генерація сертифіката для клієнта front proxy
  /etcd-ca                      Генерація самопідписаного CA для забезпечення ідентифікації etcd
  /etcd-server                  Генерація сертифіката для обслуговування etcd
  /etcd-peer                    Генерація сертифіката для звʼязку між вузлами etcd
  /etcd-healthcheck-client      Генерація сертифіката для перевірки живучості etcd
  /apiserver-etcd-client        Генерація сертифіката, який використовується apiserver для доступу до etcd
  /sa                           Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig                    Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
  /admin                        Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
  /super-admin                  Генерація kubeconfig файлу для супер-адміністратора
  /kubelet                      Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
  /controller-manager           Генерація kubeconfig файлу для використання контролер-менеджером
  /scheduler                    Генерація kubeconfig файлу для використання планувальником
etcd                          Генерація маніфесту статичного Pod для локального etcd
  /local                        Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane                 Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
  /apiserver                    Генерація маніфесту статичного Pod для kube-apiserver
  /controller-manager           Генерація маніфесту статичного Pod для kube-controller-manager
  /scheduler                    Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start                 Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config                 Завантаження конфігурації kubeadm та kubelet до ConfigMap
upload-config                 Завантаження конфігурації kubeadm та kubelet у ConfigMap
  /kubeadm                      Завантаження конфігурації кластера kubeadm у ConfigMap
  /kubelet                      Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs                  Завантаження сертифікатів у kubeadm-certs
mark-control-plane            Маркування вузла як вузла панелі управління
bootstrap-token               Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize             Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
  /enable-client-cert-rotation  Ввімкнути ротацію сертифікатів клієнтів kubelet
addon                        Встановлення необхідних надбудов для проходження тестів відповідності
  /coredns                     Встановлення надбудови CoreDNS у Kubernetes кластер
  /kube-proxy                  Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command            Показати команду приєднання для вузлів керування та робочих вузлів
</code></pre><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-shell" data-lang="shell"><span class="line"><span class="cl">kubeadm init <span class="o">[</span>прапорці<span class="o">]</span>
</span></span></code></pre></div><h3 id="options">Параметри<a class="td-heading-self-link" href="#options" aria-label="Heading self-link"></a></h3>
<table style="width: 100%; table-layout: fixed;">
    <colgroup>
        <col span="1" style="width: 10px;" />
        <col span="1" />
    </colgroup>
    <tbody>
        <tr>
            <td colspan="2">--apiserver-advertise-address string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.</p></td>
        </tr>
        <tr>
            <td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: 6443</td>
        </tr>
        <tr>
            <td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Порт, до якого буде привʼязаний API Server.</p></td>
        </tr>
        <tr>
            <td colspan="2">--apiserver-cert-extra-sans strings</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.</p></td>
        </tr>
        <tr>
            <td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: "/etc/kubernetes/pki"</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Шлях для збереження та зберігання сертифікатів.</p></td>
        </tr>
        <tr>
            <td colspan="2">--certificate-key string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти</p></td>
        </tr>
        <tr>
            <td colspan="2">--config string</td>
        </tr>
        <tr>
            <td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Шлях до файлу конфігурації kubeadm.</p></td>
        </tr>
        <tr>
            <td colspan="2">--control-plane-endpoint string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Вкажіть стабільну IP адресу або DNS імʼя для панелі управління.</p></td>
        </tr>
        <tr>
            <td colspan="2">--cri-socket string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Шлях до сокета CRI для підключення. Якщо не заповнено, kubeadm спробує автоматично визначити це значення; використовуйте цю опцію тільки якщо у вас встановлено більше одного CRI або якщо у вас нестандартний сокет CRI.</p></td>
        </tr>
        <tr>
            <td colspan="2">--dry-run</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Не застосовувати жодних змін; просто вивести, що буде зроблено.</p></td>
        </tr>
        <tr>
            <td colspan="2">--feature-gates string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:<br/>
                NodeLocalCRISocket=true|false (default=true)<br/>
                PublicKeysECDSA=true|false (DEPRECATED - default=false)<br/>
                RootlessControlPlane=true|false (ALPHA - default=false)</p></td>
        </tr>
        <tr>
            <td colspan="2">-h, --help</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>довідка init</p></td>
        </tr>
        <tr>
            <td colspan="2">--ignore-preflight-errors strings</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.</p></td>
        </tr>
        <tr>
            <td colspan="2">--image-repository string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: "registry.k8s.io"</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Виберіть реєстр контейнерів для завантаження образів панелі управління</p></td>
        </tr>
        <tr>
            <td colspan="2">--kubernetes-version string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: "stable-1"</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Виберіть конкретну версію Kubernetes для панелі управління.</p></td>
        </tr>
        <tr>
            <td colspan="2">--node-name string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Вкажіть імʼя вузла.</p></td>
        </tr>
        <tr>
            <td colspan="2">--patches string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Шлях до теки, що містить файли з іменами &quot;target[suffix][+patchtype].extension&quot;. Наприклад, &quot;kube-apiserver0+merge.yaml&quot; або просто &quot;etcd.json&quot;. &quot;target&quot; може бути одним з &quot;kube-apiserver&quot;, &quot;kube-controller-manager&quot;, &quot;kube-scheduler&quot;, &quot;etcd&quot;, &quot;kubeletconfiguration&quot;, &quot;corednsdeployment&quot;. &quot;patchtype&quot; може бути одним з &quot;strategic&quot;, &quot;merge&quot; або &quot;json&quot;, і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно &quot;patchtype&quot; є &quot;strategic&quot;. &quot;extension&quot; повинно бути або &quot;json&quot;, або &quot;yaml&quot;. &quot;suffix&quot; є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.</p></td>
        </tr>
        <tr>
            <td colspan="2">--pod-network-cidr string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Вкажіть діапазон IP-адрес для мережі Podʼів. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.</p></td>
        </tr>
        <tr>
            <td colspan="2">--service-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: "10.96.0.0/12"</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Використовуйте альтернативний діапазон IP-адрес для VIP сервісів.</p></td>
        </tr>
        <tr>
            <td colspan="2">--service-dns-domain string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: "cluster.local"</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Використовуйте альтернативний домен для сервісів, наприклад &quot;myorg.internal&quot;.</p></td>
        </tr>
        <tr>
            <td colspan="2">--skip-certificate-key-print</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.</p></td>
        </tr>
        <tr>
            <td colspan="2">--skip-phases strings</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Список етапів, які потрібно оминути</p></td>
        </tr>
        <tr>
            <td colspan="2">--skip-token-print</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.</p></td>
        </tr>
        <tr>
            <td colspan="2">--token string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Токен для встановлення двосторонньої довіри між вузлами та вузлами панелі управління. Формат [a-z0-9]{6}.[a-z0-9]{16} — наприклад, abcdef.0123456789abcdef</p></td>
        </tr>
        <tr>
            <td colspan="2">--token-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Типово: 24h0m0s</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Час перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться</p></td>
        </tr>
        <tr>
            <td colspan="2">--upload-certs</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Завантажити сертифікати панелі управління у Secret kubeadm-certs.</p></td>
        </tr>
    </tbody>
</table>
<h3 id="options-inherited-from-parent-commands">Параметри успадковані від батьківських команд<a class="td-heading-self-link" href="#options-inherited-from-parent-commands" aria-label="Heading self-link"></a></h3>
<table style="width: 100%; table-layout: fixed;">
    <colgroup>
        <col span="1" style="width: 10px;" />
        <col span="1" />
    </colgroup>
    <tbody>
        <tr>
            <td colspan="2">--rootfs string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>[ЕКСПЕРИМЕНТАЛЬНО] Шлях до 'реальної' кореневої файлової системи хоста.</p></td>
        </tr>
    </tbody>
</table>


### Процес Init {#init-workflow}

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

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

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

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

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

   Статичні манифести Pod записуються у `/etc/kubernetes/manifests`; kubelet спостерігає за цією текою для створення Podʼів при запуску.

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

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

6. Генерує токен, який додаткові вузли можуть використовувати для реєстрації у майбутньому на вузлі панелі управління. За бажанням, користувач може надати токен через `--token`, як описано в документації [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/).

7. Виконує всі необхідні налаштування для дозволу приєднання вузлів за допомогою механізмів [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) та [TLS Bootstrap](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/):

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

   - Дозволяє Bootstrap Tokens доступ до API підписання CSR.

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

   Див. [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) для додаткової інформації.

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

   <div class="alert alert-danger" role="note"><h4 class="alert-heading">Попередження:</h4>Використання kube-dns у kubeadm визнано застарілим з v1.18 і видалене у v1.21.</div>


### Використання фаз ініціалізації з kubeadm {#init-phases}

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

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

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

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

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

```shell
sudo kubeadm init phase control-plane --help
```

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

Приклад:

```shell
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`. Викликом останньої команди ви створите вузол панелі управління з власними файлами маніфестів.








  <div class="feature-state-notice feature-beta">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.22 [beta]</code>
    </div>
  



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

### Використання kubeadm init з конфігураційним файлом {#config-file}

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Увага:</h4>Конфігураційний файл все ще вважається бета-версією і може змінюватися в майбутніх версіях.</div>


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

Ви можете вивести стандартну конфігурацію за допомогою команди [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/).

Якщо ваша конфігурація не використовує останню версію, **рекомендується** перейти на нову версію за допомогою команди [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/).

Для отримання додаткової інформації про поля та використання конфігурації ви можете перейти на нашу [сторінку API-довідки](/docs/reference/config-api/kubeadm-config.v1beta4/).

### Використання kubeadm init з функціональними можливостями {#feature-gates}

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

Щоб передати функціональні можливості, можна використовувати прапорець `--feature-gates` для `kubeadm init`, або можна додати елементи до поля `featureGates`, коли передаєте [конфігураційний файл](/docs/reference/config-api/kubeadm-config.v1beta4/#kubeadm-k8s-io-v1beta4-ClusterConfiguration) за допомогою `--config`.

Передача [функціональних можливостей для основних компонентів Kubernetes](/docs/reference/command-line-tools-reference/feature-gates) безпосередньо в kubeadm не підтримується. Натомість це можливо зробити за допомогою [налаштування компонентів за допомогою API kubeadm](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).

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



 





<table><caption style="display: none;">Прапорці функцій kubeadm</caption>
	<thead>
			<tr>
					<th style="text-align: left">Функція</th>
					<th style="text-align: left">Стандартно</th>
					<th style="text-align: left">Alpha</th>
					<th style="text-align: left">Beta</th>
					<th style="text-align: left">GA</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left"><code>NodeLocalCRISocket</code></td>
					<td style="text-align: left"><code>true</code></td>
					<td style="text-align: left">1.32</td>
					<td style="text-align: left">1.34</td>
					<td style="text-align: left">1.36</td>
			</tr>
	</tbody>
</table>



<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Після того, як функціональна можливість переходить до стадії GA, її стандартне значення стає <code>true</code>.</div>


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

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

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



 





<table><caption style="display: none;">Застарілі функціональні можливості kubeadm</caption>
	<thead>
			<tr>
					<th style="text-align: left">Функція</th>
					<th style="text-align: left">Стандартно</th>
					<th style="text-align: left">Alpha</th>
					<th style="text-align: left">Beta</th>
					<th style="text-align: left">GA</th>
					<th style="text-align: left">Deprecated</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left"><code>PublicKeysECDSA</code></td>
					<td style="text-align: left"><code>false</code></td>
					<td style="text-align: left">1.19</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">1.31</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>RootlessControlPlane</code></td>
					<td style="text-align: left"><code>false</code></td>
					<td style="text-align: left">1.22</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">1.31</td>
			</tr>
	</tbody>
</table>


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

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

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

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



 





<table><caption style="display: none;">Видалені функціональні можливості kubeadm</caption>
	<thead>
			<tr>
					<th style="text-align: left">Елемент</th>
					<th style="text-align: left">Alpha</th>
					<th style="text-align: left">Beta</th>
					<th style="text-align: left">GA</th>
					<th style="text-align: left">Видалено</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left"><code>ControlPlaneKubeletLocalMode</code></td>
					<td style="text-align: left">1.31</td>
					<td style="text-align: left">1.33</td>
					<td style="text-align: left">1.35</td>
					<td style="text-align: left">1.36</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>EtcdLearnerMode</code></td>
					<td style="text-align: left">1.27</td>
					<td style="text-align: left">1.29</td>
					<td style="text-align: left">1.32</td>
					<td style="text-align: left">1.33</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>IPv6DualStack</code></td>
					<td style="text-align: left">1.16</td>
					<td style="text-align: left">1.21</td>
					<td style="text-align: left">1.23</td>
					<td style="text-align: left">1.24</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>UnversionedKubeletConfigMap</code></td>
					<td style="text-align: left">1.22</td>
					<td style="text-align: left">1.23</td>
					<td style="text-align: left">1.25</td>
					<td style="text-align: left">1.26</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>UpgradeAddonsBeforeControlPlane</code></td>
					<td style="text-align: left">1.28</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">-</td>
					<td style="text-align: left">1.31</td>
			</tr>
			<tr>
					<td style="text-align: left"><code>WaitForAllControlPlaneComponents</code></td>
					<td style="text-align: left">1.30</td>
					<td style="text-align: left">1.33</td>
					<td style="text-align: left">1.34</td>
					<td style="text-align: left">1.35</td>
			</tr>
	</tbody>
</table>


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

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

`EtcdLearnerMode`
: При приєднанні до нового вузла панелі управління, новий член etcd буде створений як учень і підвищений до члена з правом голосу тільки після того, як дані etcd будуть повністю вирівняні.

`IPv6DualStack`
: Цей прапорець допомагає налаштувати компоненти подвійного стека, коли функція знаходиться в процесі розробки. Для отримання більш детальної інформації про підтримку подвійного стека в Kubernetes дивіться [Підтримка подвійного стека за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/).

`UnversionedKubeletConfigMap`
: Цей прапорець контролює назву <a class='glossary-tooltip' title='Обʼєкт API, призначений для зберігання неконфіденційних даних у вигляді пар ключ-значення. Може використовуватися як змінні середовища, аргументи командного рядка чи файли конфігурації у томі.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/configuration/configmap/' target='_blank' aria-label='ConfigMap'>ConfigMap</a>, в якому kubeadm зберігає дані конфігурації kubelet. Якщо цей прапорець не вказаний або встановлений у `true`, ConfigMap називається `kubelet-config`. Якщо ви встановите цей прапорець у `false`, назва ConfigMap включатиме основну та додаткову версію для Kubernetes (наприклад: `kubelet-config-1.36`). 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 на вузлі панелі управління. Процес очікування починається одразу після запуску kubelet на хості за допомогою kubeadm. Рекомендується увімкнути цю функцію, якщо ви бажаєте спостерігати стан готовності всіх компонентів панелі управління під час виконання команд `kubeadm init` або `kubeadm join`.

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

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

- [Довідка з налаштування kube-proxy](/docs/reference/config-api/kube-proxy-config.v1alpha1/)

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

- [IPVS](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/README.md)

### Передача власних прапорців користувача до компонентів панелі управління {#control-plane-flags}

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

- [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)

### Використання kubeadm без підключення до Інтернету {#without-internet-connection}

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

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

```shell
kubeadm config images list
kubeadm config images pull
```

Ви можете використати `--config` з вищенаведеними командами з [файлом конфігурації kubeadm](#config-file) для контролю полів `kubernetesVersion` та `imageRepository`.

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

### Використання власних образів {#custom-images}

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

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

- Вказати `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) {#custom-pause-image}

Щоб встановити власний образ для цих контейнерів, потрібно налаштувати ваше <a class='glossary-tooltip' title='Середовище виконання контейнера — це програмне забезпечення, яке відповідає за запуск та виконання контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/setup/production-environment/container-runtimes' target='_blank' aria-label='середовище виконання контейнерів'>середовище виконання контейнерів</a> для використання цього образу. Зверніться до документації вашого середовища виконання контейнерів, щоб дізнатися, як змінити це налаштування; для певних середовищ виконання контейнерів ви також можете знайти поради у розділі [Середовища виконання контейнерів](/docs/setup/production-environment/container-runtimes/).

### Завантаження сертифікатів панелі управління до кластера {#uploading-control-plane-certificates-to-cluster}

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

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

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


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Попередньо визначений <code>certificateKey</code> можна вказати в <code>InitConfiguration</code> при передачі <a href="/uk/docs/reference/config-api/kubeadm-config.v1beta4/">файлу конфігурації</a> за допомогою <code>--config</code>.</div>


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

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

```shell
kubeadm certs certificate-key
```

### Управління сертифікатами за допомогою kubeadm {#certificate-management-with-kubeadm}

Для отримання докладної інформації про управління сертифікатами за допомогою kubeadm перегляньте [Управління сертифікатами за допомогою kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/). Документ містить інформацію про використання зовнішнього центру сертификації (CA), власні сертифікати
та оновлення сертифікатів.

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

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

Для отримання додаткової інформації дивіться [Керування drop-in файлом для systemd в kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd).

### Використання kubeadm з CRI runtimes {#use-kubeadm-with-cri-runtimes}

Стандартно kubeadm намагається зʼясувати яке у вас середовище виконання контейнерів. Для детальнішої інформації щодо цього, дивіться [посібник з установки CRI для kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).

### Налаштування імені вузла {#setting-the-node-name}

Типово `kubeadm` присвоює імʼя вузла на основі мережевої адреси машини. Ви можете змінити це налаштування за допомогою прапорця `--node-name`. Цей прапорець передає відповідне значення [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options) до kubelet.

Зверніть увагу, що заміна імені хосту може вплинути на роботу хмарних провайдерів,
[деталі за посиланням](https://github.com/kubernetes/website/pull/8873).

### Автоматизація kubeadm {#automating-kubeadm}

Замість копіювання токену, який ви отримали з `kubeadm init` на кожний вузол, як у [базовому посібнику з kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), ви можете паралельно розподіляти токен для полегшення автоматизації. Щоб реалізувати цю автоматизацію, вам потрібно знати IP-адресу, яку матиме вузол панелі управління після запуску, або використовувати DNS-імʼя чи адресу балансувальника навантаження.

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

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

   ```shell
   kubeadm token generate
   ```

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

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

   ```shell
   kubeadm certs certificate-key
   ```

Як тільки кластер буде запущений, ви зможете використовувати файл `/etc/kubernetes/admin.conf` з вузла панелі управління для спілкування з кластером з адміністративними правами чи [Генерація файлів kubeconfig для додаткових користувачів](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users).

Зауважте, що цей спосіб ініціалізації має деякі спрощені гарантії безпеки, оскільки не дозволяє перевіряти кореневий хеш сертифіката з `--discovery-token-ca-cert-hash` (оскільки він не генерується при проведенні вузлів). Докладні відомості дивіться в [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).

## Що далі

- [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) для отримання більш детальної інформації про фази `kubeadm init`.
- [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) для налаштування робочого вузла Kubernetes та його приєднання до кластера.
- [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) для оновлення кластера Kubernetes до новішої версії.
- [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) для скидання будь-яких змін, внесених до цього хосту за допомогою `kubeadm init` або `kubeadm join`.