kubeadm join

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

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

Опис

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

Існує 2 основні схеми виявлення. Перша — використовувати спільний токен разом з IP-адресою API-сервера. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через HTTPS URL. Можливі форми: 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. Значення цього прапорця задається як "<hash-type>:<hex-encoded-value>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у виводі "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash можна вказувати кілька разів, щоб дозволити більше одного публічного ключа.

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

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

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

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

preflight               Run join pre-flight checks
control-plane-prepare   Prepare the machine for serving a control plane
  /download-certs         Download certificates shared among control-plane nodes from the kubeadm-certs Secret
  /certs                  Generate the certificates for the new control plane components
  /kubeconfig             Generate the kubeconfig for the new control plane components
  /control-plane          Generate the manifests for the new control plane components
kubelet-start           Write kubelet settings, certificates and (re)start the kubelet
etcd-join               Join etcd for control plane nodes
kubelet-wait-bootstrap  Wait for the kubelet to bootstrap itself
control-plane-join      Join a machine as a control plane instance
  /mark-control-plane     Mark a node as a control-plane
wait-control-plane      Wait for the control plane to start

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

Параметри

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

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

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

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

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

   TLS bootstrap використовує спільний токен для тимчасової автентифікації в 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

Переваги:

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

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

Недоліки:

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

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

Це забезпечує спосіб встановлення кореня довіри між вузлом панелі управління та вузлами початкового завантаження поза основним каналом (out-of-band). Розгляньте використання цього режиму, якщо ви створюєте автоматизоване розгортання за допомогою 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 bootstrap та затвердження 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, яке по суті затверджує будь-який запит на клієнтський сертифікат для kubelet, якщо під час автентифікації використовувався токен 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.