kubeadm join

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

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
kubeadm join --discovery-file path/to/file.conf
kubeadm join --discovery-file https://url/file.conf

Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.

Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як "<тип-хешу>:<шестнадцяткове-кодоване-значення>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.

Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.

Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.

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

Команда "join [api-server-endpoint]" виконує наступні фази:

preflight              Виконати передстартові перевірки для приєднання
control-plane-prepare  Підготувати машину для обслуговування панелі управління
  /download-certs        Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                 Створити сертифікати для нових компонентів панелі управління
  /kubeconfig            Створити kubeconfig для нових компонентів панелі управління
  /control-plane         Створити маніфести для нових компонентів панелі управління
kubelet-start          Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
control-plane-join     Приєднати машину як екземпляр панелі управління
  /etcd                  Додати нового локального члена etcd
  /mark-control-plane    Позначити вузол як панель управління
wait-control-plane     Експериментально: чекати запуску панелі управління

kubeadm join [api-server-endpoint] [flags]

Параметри

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

Процес приєднання

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

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

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

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

kubeadm join phase kubelet-start --help

Подібно до команди kubeadm init phase, команда kubeadm join phase дозволяє пропустити список фаз, використовуючи прапорець --skip-phases.

Наприклад:

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

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

Визначення, якому CA кластера довіряти

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

Виявлення на основі токена з закріпленням CA

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

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

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:

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

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

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

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

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

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

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

Переваги:

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

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

Недоліки:

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

Виявлення на основі файлів або HTTPS

Це забезпечує автономний спосіб встановлення кореня довіри між вузлом панелі управління та вузлами початкового завантаження. Розгляньте використання цього режиму, якщо ви створюєте автоматизоване впровадження за допомогою kubeadm. Формат файлу для виявлення — це звичайний файл Kubernetes kubeconfig.

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

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

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

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

Переваги:

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

Недоліки:

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

Використання власних облікових даних kubelet з 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 та вимоги та Управління сертифікатами за допомогою kubeadm.

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

Ще більший захист вашого встановлення

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

Вимкнення автоматичного затвердження клієнтських сертифікатів вузла

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

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

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

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

   kubectl get csr
   

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

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

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

   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   

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

   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   

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

   kubectl get csr
   

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

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

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

Вимкнення загального доступу до ConfigMap cluster-info

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

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

  kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.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:

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

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

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

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

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

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

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

Що далі

• kubeadm init для ініціалізації вузла панелі управління Kubernetes.
• kubeadm token для управління токенами для kubeadm join.
• kubeadm reset для скасування будь-яких змін, внесених до цього хосту за допомогою kubeadm init або kubeadm join.