Примітка:
TLS-запуск для вузлів можна налаштувати за допомогою команди
kubeadm init phase bootstrap-token, виконуючи всі кроки налаштування, описані в наступних розділаї; альтернативно, кожен крок може бути викликаний окремо.
Примітка:
Доступ до ConfigMap cluster-info не обмежується за швидкістю. Це може бути проблемою, якщо ваш API-сервер кластера відкритий для інтернету; у найгіршому випадку може виникнути атака типу DoS, коли атакуючий використовує всі вхідні запити, які може обробити kube-apiserver, щоб обслуговувати ConfigMap cluster-info.
### Встановлення надбудов {#installing-addons}
Kubeadm встановлює внутрішній DNS-сервер і компоненти надбудов kube-proxy через API-сервер.
#### proxy
Для `kube-proxy` створюється обліковий запис ServiceAccount у просторі імен `kube-system`, після чого `kube-proxy` розгортається як DaemonSet:
- Облікові дані (`ca.crt` та `token`) до панелі управління отримуються з облікового запису ServiceAccount.
- Місцезнаходження (URL) API-сервера отримується з ConfigMap.
- Обліковий запис ServiceAccount `kube-proxy` повʼязується з правами у рольовому доступі ClusterRole `system:node-proxier`.
#### DNS
- Сервіс CoreDNS називається `kube-dns` для сумісності з застарілою надбудовою `kube-dns`.
- У просторі імен `kube-system` створюється обліковий запис ServiceAccount для CoreDNS.
- Обліковий запис `coredns` привʼязаний до привілеїв у ClusterRole `system:coredns`.
У версії Kubernetes 1.21 була видалена підтримка використання `kube-dns` з kubeadm. Ви можете використовувати CoreDNS з kubeadm, навіть якщо повʼязаний сервіс називається `kube-dns`.
## Внутрішній дизайн фаз `kubeadm join` {#kubeadm-join-phases-internal-design}
Подібно до `kubeadm init`, внутрішній робочий процес `kubeadm join` також складається з послідовності атомарних завдань, що виконуються.
Вони поділені на дві частини: виявлення (щоб вузол довіряв Kubernetes API Server) та початкове завантаження TLS (щоб Kubernetes API Server довіряв вузлу).
Дивіться [Автентифікація за допомогою Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) або відповідну [пропозицію дизайну](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md).
### Попередні перевірки {#preflight-checks}
`kubeadm` виконує набір попередніх перевірок перед початком приєднання, з метою перевірити попередні умови та уникнути поширених проблем запуску кластера.
Зверніть увагу на наступне:
1. Попередні перевірки `kubeadm join` є, по суті, підмножиною попередніх перевірок `kubeadm init`.
2. Якщо ви приєднуєтеся до вузла Windows, специфічні для Linux елементи керування пропускаються.
3. У будь-якому випадку користувач може пропустити певні попередні перевірки (або, врешті-решт, усі попередні перевірки) за допомогою опції `--ignore-preflight-errors`.
### Виявлення інформації про кластер {#discovery-cluster-info}
Є дві основні схеми для виявлення. Перша полягає у використанні спільного токена разом з IP-адресою сервера API. Друга — наданні файлу (який є підмножиною стандартного файлу kubeconfig).
#### Виявлення спільного токена {#shared-token-discovery}
Якщо `kubeadm join` викликається з параметром `--discovery-token`, використовується виявлення за допомогою токена; у цьому випадку вузол основному отримує сертифікати CA кластера з ConfigMap `cluster-info` у просторі імен `kube-public`.
Щоб запобігти атакам типу "особа посередині", вживаються кілька заходів:
- Спочатку сертифікат CA отримується через небезпечне зʼєднання (це можливо, тому що `kubeadm init` надає доступ користувачам `cluster-info` для `system:unauthenticated`)
- Потім сертифікат CA проходить наступні кроки перевірки:
- Базова перевірка: використовуючи ID токена через підпис JWT
- Перевірка публічного ключа: використовуючи наданий `--discovery-token-ca-cert-hash`. Це значення доступне у виводі `kubeadm init` або може бути обчислене за допомогою стандартних інструментів (хеш обчислюється над байтами обʼєкта Subject Public Key Info (SPKI) відповідно до RFC7469). Прапор `--discovery-token-ca-cert-hash` може бути повторений кілька разів, щоб дозволити більше одного публічного ключа.
- Як додаткова перевірка, сертифікат CA отримується через безпечне зʼєднання і порівнюється з сертифікатом CA, отриманим спочатку
Примітка:
Ви можете пропустити перевірку CA, передавши в командному рядку прапорець --discovery-token-unsafe-skip-ca-verification. Це послаблює модель безпеки kubeadm, оскільки інші потенційно можуть видавати себе за сервер API Kubernetes.
#### Виявлення файлу/HTTPS {#file-https-discovery}
Якщо `kubeadm join` викликається з параметром `--discovery-file`, використовується виявлення за допомогою файлу; цей файл може бути локальним файлом або завантаженим через HTTPS URL; у випадку HTTPS, використовується встановлений на хості пакет сертифікатів CA для перевірки зʼєднання.
При виявленні файлу сертифікат CA кластера надається у самому файлі; фактично, файл для виявлення є файлом kubeconfig з встановленими тільки атрибутами `server` і `certificate-authority-data`, як описано у референс-документації [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/#file-or-https-based-discovery); коли зʼєднання з кластером встановлено, kubeadm намагається отримати доступ до ConfigMap `cluster-info`, і якщо він доступний, використовує його.
## TLS Bootstrap
Після того, як інформація про кластер відома, записується файл `bootstrap-kubelet.conf`, що дозволяє kubelet виконати початкове завантаження TLS.
Механізм початкового завантаження TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів.
Запит автоматично затверджується, і операція завершується збереженням файлів `ca.crt` і `kubelet.conf`, які використовуються kubelet для приєднання до кластера, тоді як `bootstrap-kubelet.conf` видаляється.
Примітка:
- Тимчасова автентифікація перевіряється через токен, збережений під час процесу
kubeadm init (або за допомогою додаткових токенів, створених командою kubeadm token)
- Тимчасова автентифікація відноситься до користувача, який є членом групи
system:bootstrappers:kubeadm:default-node-token, якій було надано доступ до API CSR під час процесу kubeadm init
- Автоматичне затвердження CSR управляється контролером csrapprover відповідно до конфігурації, присутньої в процесі
kubeadm init