# kubeadm join

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

---

<!-- overview -->

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

<!-- body -->


	<p>Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера</p>
<h3 id="synopsis">Опис<a class="td-heading-self-link" href="#synopsis" aria-label="Heading self-link"></a></h3>
<p>Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).</p>
<p>Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go (&quot;exec&quot;), &quot;tokenFile&quot; та &quot;authProvider&quot;. Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-shell" data-lang="shell"><span class="line"><span class="cl">kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
</span></span><span class="line"><span class="cl">kubeadm join --discovery-file path/to/file.conf
</span></span><span class="line"><span class="cl">kubeadm join --discovery-file https://url/file.conf
</span></span></code></pre></div><p>Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.</p>
<p>Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як &quot;&lt;тип-хешу&gt;:&lt;шестнадцяткове-кодоване-значення&gt;&quot;, де підтримуваний тип хешу — &quot;sha256&quot;. Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних &quot;kubeadm init&quot; або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.</p>
<p>Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.</p>
<p>Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.</p>
<p>Часто той самий токен використовується для обох частин. У цьому випадку прапорець --token можна використовувати замість окремого зазначення кожного токена.</p>
<p>Команда &quot;join [api-server-endpoint]&quot; виконує наступні фази:</p>
<pre tabindex="0"><code class="language-none" data-lang="none">preflight               Виконати передстартові перевірки для приєднання
control-plane-prepare   Підготувати машину для обслуговування панелі управління
  /download-certs         Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                  Створити сертифікати для нових компонентів панелі управління
  /kubeconfig             Створити kubeconfig для нових компонентів панелі управління
  /control-plane          Створити маніфести для нових компонентів панелі управління
kubelet-start           Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
etcd-join               Приєднання etcd до вузлів панелі управління
kubelet-wait-bootstrap  Чекати, поки kubelet завантажиться
control-plane-join      Приєднати машину як екземпляр панелі управління
  /mark-control-plane     Позначити вузол як панель управління
wait-control-plane     Чекати запуску панелі управління
</code></pre><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-shell" data-lang="shell"><span class="line"><span class="cl">kubeadm join <span class="o">[</span>api-server-endpoint<span class="o">]</span> <span class="o">[</span>flags<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 буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.</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.</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>Використовуйте цей ключ для розшифрування секретів сертифікатів, завантажених за допомогою init. Ключ сертифіката — це шестнадцятковий закодований рядок, який є 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</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Створити новий екземпляр панелі управління на цьому вузлі</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">--discovery-file string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.</p></td>
        </tr>
        <tr>
            <td colspan="2">--discovery-token string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.</p></td>
        </tr>
        <tr>
            <td colspan="2">--discovery-token-ca-cert-hash strings</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "&lt;тип&gt;:&lt;значення&gt;").</p></td>
        </tr>
        <tr>
            <td colspan="2">--discovery-token-unsafe-skip-ca-verification</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.</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">-h, --help</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Довідка join</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">--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">--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">--tls-bootstrap-token string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.</p></td>
        </tr>
        <tr>
            <td colspan="2">--token string</td>
        </tr>
        <tr>
            <td></td>
            <td style="line-height: 130%; word-wrap: break-word;"><p>Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.</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>Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях</p></td>
        </tr>
    </tbody>
</table>


### Процес приєднання {#join-workflow}

`kubeadm join` ініціалізує робочий вузол Kubernetes або вузол панелі управління та додає його до кластера. Ця дія складається з наступних кроків для робочих вузлів:

1. kubeadm завантажує необхідну інформацію про кластер з сервера API. Стандартно використовується токен початкового завантаження та хеш ключа CA для перевірки достовірності цих даних. Кореневий CA також може бути виявлений безпосередньо через файл або URL.

2. Як тільки інформація про кластер відома, kubelet може почати процес TLS початкового завантаження.

   Завантажувач TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для надсилання запиту на підписання сертифіката (CSR); стандартно панель управління підписує цей CSR-запит автоматично.

3. Нарешті, kubeadm налаштовує локальний kubelet для підключення до сервера API з остаточною ідентичністю, призначеною вузлу.

Для вузлів панелі управління виконуються додаткові кроки:

1. Завантаження сертифікатів, спільних для вузлів панелі управління з кластера (якщо це явно запитано користувачем).

2. Генерація маніфестів компонентів панелі управління, сертифікатів та kubeconfig.

3. Додавання нового локального члена etcd.

### Використання фаз приєднання з kubeadm {#join-phases}

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

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

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

```shell
kubeadm join phase kubelet-start --help
```

Подібно до команди [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases), команда `kubeadm join phase` дозволяє пропустити список фаз, використовуючи прапорець `--skip-phases`.

Наприклад:

```shell
sudo kubeadm join --skip-phases=preflight --config=config.yaml
```








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



Крім того, ви можете використовувати поле `skipPhases` в `JoinConfiguration`.

### Визначення, якому CA кластера довіряти {#discovering-whats-cluster-ca-to-trust}

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

#### Виявлення на основі токена з закріпленням CA {#token-based-discovery-with-ca-pinning}

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

Хеш ключа CA має формат `sha256:<hex_encoded_hash>`. Стандартне значення хешу друкується в кінці команди `kubeadm init` або у виведенні команди `kubeadm token create --print-join-command`. Воно знаходиться в стандартному форматі (див. [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) і може бути також обчислено сторонніми інструментами або системами забезпечення. Наприклад, використовуючи OpenSSL CLI:

```shell
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
```

**Приклади команд `kubeadm join`:**

Для робочих вузлів:

```shell
kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443
```

Для вузлів панелі управління:

```shell
kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443
```

Ви також можете викликати `join` для вузла панелі управління з прапорцем `--certificate-key` для копіювання сертифікатів на цей вузол, якщо команда `kubeadm init` була викликана з прапорцем `--upload-certs`.

**Переваги:**

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

- Зручно виконувати вручну, оскільки вся необхідна інформація вміщується в одну команду `kubeadm join`.

**Недоліки:**

- Хеш CA зазвичай не відомий до тих пір, поки вузол панелі управління не буде впроваджений, що може ускладнити створення автоматизованих інструментів впровадження, які використовують kubeadm. Генеруючи свій CA заздалегідь, ви можете обійти це обмеження.

#### Виявлення на основі токена без закріплення CA {#token-based-discovery-without-ca-pinning}

Цей режим покладається лише на симетричний токен для підпису (HMAC-SHA256) інформації про виявлення, що встановлює корінь довіри для панелі управління. Щоб використовувати цей режим, вузли, що приєднуються, повинні пропустити перевірку хешу публічного ключа CA, використовуючи `--discovery-token-unsafe-skip-ca-verification`. Якщо можливо, слід розглянути використання одного з інших режимів.

**Приклад команди `kubeadm join`:**

```shell
kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443
```

**Переваги:**

- Все ще захищає від багатьох атак на рівні мережі.

- Токен можна створити заздалегідь і поділитися з вузлом панелі управління та робочими вузлами, які потім можуть початково завантажуватися паралельно без координації. Це дозволяє використовувати його в багатьох сценаріях розгортання.

**Недоліки:**

- Якщо зловмисник зможе вкрасти токен початкового завантаження через якусь уразливість, вони можуть використовувати цей токен (разом з доступом на рівні мережі) для видавання себе за вузол панелі управління для інших вузлів початкового завантаження. Це може бути або не бути відповідним компромісом у вашому середовищі.

#### Виявлення на основі файлів або HTTPS {#file-or-https-based-discovery}

Це забезпечує автономний спосіб встановлення кореня довіри між вузлом панелі управління та вузлами початкового завантаження. Розгляньте використання цього режиму, якщо ви створюєте автоматизоване впровадження за допомогою kubeadm. Формат файлу для виявлення — це звичайний файл Kubernetes [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).

У разі, якщо файл для виявлення не містить облікових даних, буде використовуватися токен TLS.

**Приклади команд `kubeadm join`:**

- `kubeadm join --discovery-file path/to/file.conf` (локальний файл)

- `kubeadm join --discovery-file https://url/file.conf` (віддалений HTTPS URL)

**Переваги:**

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

**Недоліки:**

- Вимагає, щоб у вас був спосіб перенести інформацію про виявлення від вузла панелі управління до вузлів початкового завантаження. Якщо файл для виявлення містить облікові дані, ви повинні тримати його в секреті та передавати через безпечний канал. Це може бути можливо з вашим постачальником хмарних послуг або інструментом забезпечення розгортання.

#### Використання власних облікових даних kubelet з `kubeadm join` {#using-custom-kubelet-credentials-with-kubeadm-join}

Щоб дозволити `kubeadm join` використовувати заздалегідь визначені облікові дані kubelet і пропустити клієнтське початкове завантаження TLS та затвердження CSR для нового вузла:

1. На робочому вузлі панелі управління в кластері, який має `/etc/kubernetes/pki/ca.key`, виконайте `kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`. `$NODE` має бути встановлено на імʼя нового вузла.
2. Відредагуйте отриманий `kubelet.conf` вручну, щоб налаштувати імʼя кластера та точку доступу сервера, або запустіть `kubeadm kubeconfig user --config` (приймає `InitConfiguration`).

Якщо у вашому кластері немає файлу `ca.key`, вам потрібно підписати вбудовані сертифікати в `kubelet.conf` зовнішнім чином. Для додаткової інформації дивіться [Сертифікати PKI та вимоги](/docs/setup/best-practices/certificates/) та [Управління сертифікатами за допомогою kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode).

1. Скопіюйте отриманий `kubelet.conf` до `/etc/kubernetes/kubelet.conf` на новому вузлі.
2. Виконайте `kubeadm join` з прапорцем `--ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf` на новому вузлі.

### Ще більший захист вашого встановлення {#securing-more}

Типові налаштування kubeadm можуть не підходити для всіх. Цей розділ показує, як посилити захист kubeadm коштом зручності користування.

#### Вимкнення автоматичного затвердження клієнтських сертифікатів вузла {#turning-off-auto-approval-of-node-client-certificates}

Стандартно увімкнено автоматичне затвердження запитів на клієнтські сертифікати CSR, коли використовується токен Bootstrap під час автентифікації. Якщо ви не бажаєте, щоб кластер автоматично затверджував клієнтські сертифікати kubelet, ви можете вимкнути цю функцію виконавши наступну команду:

```shell
kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap
```

Після цього команда `kubeadm join` буде блокуватися до тих пір, поки адміністратор не затвердить CSR вручну:

1. За допомогою `kubectl get csr` ви можете переглянути, що оригінальний CSR знаходиться в стані Pending.

   ```shell
   kubectl get csr
   ```

   Результат буде подібним до такого:

   ```none
   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
   ```

2. `kubectl certificate approve` дозволяє адміністратору затвердити CSR. Ця дія наказує контролеру підпису сертифікатів видати сертифікат запитувачеві з властивостями, зазначеними у CSR.

   ```shell
   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   ```

   Результат буде подібний до такого:

   ```none
   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   ```

3. Це змінить ресурс CSR на стан Active.

   ```shell
   kubectl get csr
   ```

   Результат буде подібний до такого:

   ```none
   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
   ```

Це змушує процес `kubeadm join` працювати тільки у випадку, коли була виконана команда `kubectl certificate approve`.

#### Вимкнення загального доступу до ConfigMap `cluster-info` {#turning-off-public-access-to-cluster-info-configmap}

Для того, щоб досягти потоку приєднання, використовуючи токен як єдину частину інформації про перевірку, необхідно викласти у відкритий доступ ConfigMap з деякими даними, необхідними для перевірки ідентичності вузла панелі управління, стандартно публікується у відкритому доступі. Хоча в цьому ConfigMap немає приватних даних, деякі користувачі можуть бажати вимкнути цю можливість. Це дія призведе до відключення можливості використання прапорця `--discovery-token` в потоці `kubeadm join`. Ось кроки для вимкнення цієї функції:

- Отримайте файл `cluster-info` з API сервера:

  ```shell
  kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml
  ```

  Вивід буде подібний до такого:

  ```yaml
  apiVersion: v1
  kind: Config
  clusters:
  - cluster:
      certificate-authority-data: <ca-cert>
      server: https://<ip>:<port>
    name: ""
  contexts: []
  current-context: ""
  preferences: {}
  users: []
  ```

- Використовуйте файл `cluster-info.yaml` як аргумент для `kubeadm join --discovery-file`.

- Вимкніть загальний доступ до ConfigMap `cluster-info`:

  ```shell
  kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo
  ```

Ці команди слід виконати після `kubeadm init`, але перед `kubeadm join`.

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

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


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

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

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

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

## Що далі

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