# Створення кластера за допомогою kubeadm
LLMS index: [llms.txt](/llms.txt)
---
За допомогою `kubeadm` ви можете створити мінімальний кластер Kubernetes, який відповідає найкращим практикам. Фактично, ви можете використовувати `kubeadm` для налаштування кластера, який успішно пройде [тести відповідності Kubernetes](/blog/2017/10/software-conformance-certification/). `kubeadm` також підтримує інші функції життєвого циклу кластера, такі як [bootstrap-токени](/docs/reference/access-authn-authz/bootstrap-tokens/) та оновлення кластера.
Інструмент `kubeadm` корисний у випадках, коли вам потрібен:
- Простий спосіб спробувати Kubernetes, можливо, вперше.
- Спосіб для поточних користувачів автоматизувати налаштування кластера та протестувати свій застосунок.
- Компонент в інших екосистемах та/або інсталяторах із більшим функціоналом.
Ви можете встановлювати та використовувати `kubeadm` на різних машинах: на вашому ноутбуці, хмарних серверах, Raspberry Pi та інших. Незалежно від того, чи ви розгортаєте у хмарі, чи на власних серверах, ви можете інтегрувати `kubeadm` у системи розгортання, такі як Ansible або Terraform.
## Перш ніж ви розпочнете
Для виконання цього керівництва вам потрібно мати:
- Одну чи кілька машин з операційною системою Linux, сумісною з deb/rpm, наприклад: Ubuntu чи CentOS.
- 2 ГБ або більше оперативної памʼяті на кожній машині — менше може призвести до обмежень для вашого застосунку.
- Принаймні 2 процесори на машині, яку ви використовуєте як вузол панелі управління.
- Повну мережеву доступність між усіма машинами в кластері. Ви можете використовувати як публічні, так і приватні мережі.
Також вам потрібно використовувати версію `kubeadm`, яка може розгортати ту версію
Kubernetes, яку ви хочете використовувати у своєму новому кластері.
[Політика підтримки версій та їх розбіжностей в Kubernetes](/docs/setup/release/version-skew-policy/#supported-versions) поширюється на `kubeadm` так само як і на Kubernetes в цілому. Перевірте цю політику, щоб дізнатися, які версії Kubernetes та `kubeadm` підтримуються. Ця сторінка написана для Kubernetes v1.36.
Загальний стан функцій інструменту `kubeadm` — Загальна Доступність (GA). Деякі підфункції ще перебувають на стадії активної розробки. Реалізація створення кластера може трохи змінитися, в міру розвитку інструменту, але загальна реалізація повинна бути досить стабільною.
Примітка:
Будь-які команди під kubeadm alpha за визначенням підтримуються на рівні альфа-версії.
## Мета {#Objectives}
- Встановити Kubernetes з одною панеллю управління
- Встановити мережу для Podʼів в кластері, так щоб вони могли спілкуватися один з одним
## Інструкції {#instructions}
### Підготовка хостів {#preparing-the-hosts}
#### Встановлення компонентів {#component-installation}
Встановіть середовище виконання контейнерів та `kubeadm` на всіх хостах. За докладними інструкціями та іншими вимогами звертайтесь до [Встановлення kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
Примітка:
Якщо ви вже встановили kubeadm, перегляньте перші два кроки документації
Оновлення вузлів Linux для отримання інструкцій щодо оновлення kubeadm.
Під час оновлення kubelet перезапускається кожні кілька секунд, очікуючи в crashloop на команди від kubeadm. Цей цикл аварійного перезавантаження є очікуваним і нормальним. Після ініціалізації панелі управління kubelet працює в нормальному режимі.
Примітка:
Якщо на хості присутні два або більше стандартних шлюзи, компонент Kubernetes буде намагатися використовувати перший, який зустрічається із відповідною глобальною унікальною IP-адресою. При здійсненні цього вибору точний порядок шлюзів може відрізнятися між різними операційними системами та версіями ядра.
Компоненти Kubernetes не приймають мережевий інтерфейс як параметр, тому потрібно передавати власну IP-адресу як прапорець для всіх екземплярів компонентів, які потребують такої конфігурації.
Примітка:
Якщо на хості відсутній стандартний шлюз і якщо не передано власну IP-адресу
компоненту Kubernetes, робота компонента може завершитися з помилкою.
Для налаштування IP-адреси оголошення API-сервера для вузлів панелі управління, створених із `init` та `join`, можна використовувати прапорець `--apiserver-advertise-address`. Переважно, варто встановлювати цю опцію в [API-інтерфейсі kubeadm](/docs/reference/config-api/kubeadm-config.v1beta4)
як `InitConfiguration.localAPIEndpoint` та `JoinConfiguration.controlPlane.localAPIEndpoint`.
Для kubelet на всіх вузлах опцію `--node-ip` можна передати в `.nodeRegistration.kubeletExtraArgs` всередині конфігураційного файлу kubeadm (`InitConfiguration` або `JoinConfiguration`).
Для роботи з двома стеками дивіться [Підтримка двох стеків із kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support).
IP-адреси, які ви призначаєте компонентам панелі управління, стають частиною полів альтернативного імені субʼєкта X.509 сертифіката. Зміна цих IP-адрес може вимагати підписання нових сертифікатів і перезапуску відповідних компонентів, щоб задіяти зміни у файлах сертифікатів. Дивіться [Ручне поновлення сертифікатів](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal) для отримання докладнішої інформації з цього питання.
Попередження:
Проєкт Kubernetes не рекомендує використовувати цей підхід (налаштування всіх екземплярів компонентів власними IP-адресами). Замість цього рекомендується встановити мережу хосту так, щоб IP-адреса стандартного шлюзу була тією, яку компоненти Kubernetes автоматично визначають і використовують. На Linux-вузлах ви можете використовувати команди, такі як ip route для налаштування мережі; ваша операційна система може також надавати засоби управління мережею вищого рівня. Якщо стандартний шлюз вашого вузла має публічну IP-адресу, слід налаштувати фільтрацію пакетів чи інші заходи безпеки, що захищають вузли та ваш кластер.
### Підготовка необхідних образів контейнерів {#preparing-the-required-container-images}
Цей крок є необовʼязковим і застосовується тільки у випадку, якщо ви бажаєте, щоб `kubeadm init` та `kubeadm join` не завантажували типові образи контейнерів, які розміщені на `registry.k8s.io`.
Kubeadm має команди, які можуть допомогти вам попередньо витягти необхідні образи
при створенні кластера без Інтернет-зʼєднання на його вузлах. Дивіться [Запуск kubeadm без Інтернет-зʼєднання](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) для отримання докладнішої інформації.
Kubeadm дозволяє вам використовувати власний репозиторій образів для необхідних образів. Дивіться [Використання власних образів](/docs/reference/setup-tools/kubeadm/kubeadm-init#custom-images) для отримання докладнішої інформації.
### Ініціалізація вузла панелі управління {#initializing-your-control-plane-node}
Вузол панелі управління — це машина, де працюють компоненти панелі управління, включаючи etcd (база даних кластера) та API Server (з яким взаємодіє інструмент командного рядка kubectl).
1. (Рекомендовано) Якщо у вас є плани оновлення цього кластера з одною панеллю управління за допомогою `kubeadm` до рівня [високої доступності](/docs/setup/production-environment/tools/kubeadm/high-availability/), ви повинні вказати `--control-plane-endpoint`, щоб встановити загальний endpoint для всіх вузлів панелі управління. Такий endpoint може бути іменем DNS або IP-адресою балансувальника навантаження.
1. Виберіть надбудову мережі Pod та перевірте, чи для її налаштування потрібно передати будь-які аргументи в `kubeadm init`. Залежно від того, якого постачальника вибрано, вам може бути потрібно встановити значення `--pod-network-cidr` в значення, специфічне для постачальника. Дивіться [Встановлення надбудови мережі Podʼів](#pod-network).
1. (Необовʼязково) `kubeadm` намагається визначити середовище виконання контейнерів, використовуючи список відомих точок входу. Щоб використовувати інше середовище виконання контейнерів або якщо встановлено більше одного на наданому вузлі, вкажіть аргумент `--cri-socket` для `kubeadm`. Дивіться [Встановлення середовища виконання](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
Щоб ініціалізувати вузол панелі управління, виконайте:
```bash
kubeadm init
```
### Міркування щодо apiserver-advertise-address та ControlPlaneEndpoint {#considerations-about-apiserver-advertise-address-and-controlplaneendpoint}
Хоча `--apiserver-advertise-address` може бути використано для встановлення оголошення адреси для API-сервера цього конкретного вузла панелі управління, `--control-plane-endpoint` може бути використано для встановлення загального endpoint для всіх вузлів управління.
`--control-plane-endpoint` дозволяє використовувати як IP-адреси, так і DNS-імена, які можуть транслюватись у IP-адреси. Будь ласка, зверніться до вашого адміністратора мережі, щоб оцінити можливі рішення щодо такого перетворення.
Ось приклад:
```none
192.168.0.102 cluster-endpoint
```
Де `192.168.0.102` — це IP-адреса цього вузла, а `cluster-endpoint` — це власне DNS-імʼя, яке повʼязується з цим IP. Це дозволить вам передавати `--control-plane-endpoint=cluster-endpoint` у `kubeadm init` і передавати те ж саме DNS-імʼя до `kubeadm join`. Пізніше ви можете змінити `cluster-endpoint`, щоб вказати адресу вашого балансувальника навантаження в сценарії високої доступності.
Перетворення кластера з однією панеллю управління, створеного без `--control-plane-endpoint`, у високодоступний кластер не підтримується kubeadm.
### Додаткова інформація {#more-information}
Для отримання додаткової інформації щодо аргументів `kubeadm init`, див. [посібник kubeadm](/docs/reference/setup-tools/kubeadm/).
Щоб налаштувати `kubeadm init` за допомогою файлу конфігурації, див. [Використання kubeadm init з файлом конфігурації](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
Для налаштування компонентів панелі управління, включаючи необовʼязкове призначення IPv6 для перевірки справності для компонентів панелі управління та сервера etcd, надайте додаткові аргументи кожному компоненту, як описано на сторінці про [додаткові аргументи](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
Щоб переналаштувати кластер, який вже був створений, див. [Переконфігурування кластера kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
Щоб знову виконати `kubeadm init`, спершу вам потрібно [розібрати кластер](#tear-down).
Якщо ви приєднуєте вузол з іншою архітектурою до вашого кластера, переконайтеся, що ваші розгорнуті DaemonSets мають підтримку образів контейнерів для цієї архітектури.
`kubeadm init` спочатку виконує серію попередніх перевірок, щоб забезпечити готовність машини до запуску Kubernetes. Ці попередні перевірки виводять попередження та виходять при помилках. Потім `kubeadm init` завантажує та встановлює компоненти управління кластером. Це може зайняти кілька хвилин. Після завершення ви повинні побачити:
```none
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a Pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join : --token --discovery-token-ca-cert-hash sha256:
```
Щоб kubectl працював для вашого користувача без прав root, виконайте ці команди, які є також частиною виводу `kubeadm init`:
```bash
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
Або, якщо ви є користувачем `root`, ви можете виконати:
```bash
export KUBECONFIG=/etc/kubernetes/admin.conf
```
Попередження:
Файл конфігурації kubeconfig admin.conf, який створює kubeadm init, містить сертифікат із Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin. Група kubeadm:cluster-admins привʼязана до вбудованої ролі кластера cluster-admin.
Не діліться файлом admin.conf будь з ким.
kubeadm init генерує інший файл kubeconfig super-admin.conf, який містить сертифікат із Subject: O = system:masters, CN = kubernetes-super-admin.
system:masters — це суперкористувацька група, яка обходить рівень авторизації (наприклад, RBAC). Не діліться файлом super-admin.conf будь з ким. Рекомендується перемістити файл в безпечне місце.
Див. Генерація файлів kubeconfig для додаткових користувачів щодо того, як використовувати kubeadm kubeconfig user для генерації файлів kubeconfig для додаткових користувачів.
Увага:
Цей розділ містить важливу інформацію щодо налаштування мережі та порядку розгортання. Уважно прочитайте всі ці поради перед продовженням.
Вам потрібно розгорнути надбудову мережі Pod на основі Container Network Interface (CNI), щоб ваші Podʼи могли взаємодіяти один з одним. Кластерний DNS (CoreDNS) не буде запущений, доки не буде встановлена мережа.
-
Пильнуйте, щоб мережа ваших Podʼів не перетиналася з будь-якою з мереж хосту. (Якщо ви знаходите колізію між вашою пропонованою мережею Podʼів та деякими мережами вашого хосту, вам слід обрати відповідний блок CIDR для використання його під час виконання kubeadm init з --pod-network-cidr та як заміну у вашому YAML-файлі налаштувань мережевого втулка.)
-
Типово kubeadm налаштовує ваш кластер на використання та забезпечення використання RBAC (контроль доступу на основі ролей). Переконайтеся, що ваш мережевий втулок для Pod підтримує RBAC, так само як і будь-які маніфести, які ви використовуєте для його розгортання.
-
Якщо ви хочете використовувати IPv6, як з подвійним стеком, так і в одностековій IPv6-мережі, для вашого кластера, переконайтеся, що ваш мережевий втулок для Podʼів підтримує IPv6. Підтримку IPv6 було додано до CNI у v0.6.0.
Примітка:
Kubeadm повинен бути агностичним до CNI, а перевірка постачальників CNI виходить за рамки наших поточних e2e-тестів. Якщо ви знайшли проблему, повʼязану з втулком CNI, вам слід створити тікет у відповідному репозиторії втулка CNI, а не у репо kubeadm чи Kubernetes.
Кілька зовнішніх проєктів надають мережі Pod Kubernetes за допомогою CNI, деякі з яких також підтримують [Network Policy](/docs/concepts/services-networking/network-policies/).
Див. список надбудов, які реалізують [Модель мережі Kubernetes](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model).
Будь ласка, звертайтеся до сторінки [Встановлення надбудов](/docs/concepts/cluster-administration/addons/#networking-and-network-policy) для списку мережевих надбудов (може бути неповним), які підтримуються в Kubernetes. Ви можете встановити надбудову мережі Pod за допомогою наступної команди на вузлі панелі управління
або вузлі, на якому є облікові дані kubeconfig:
```bash
kubectl apply -f
```
Примітка:
Лише кілька втулків CNI підтримують Windows. Більше деталей та інструкцій щодо налаштування можна знайти в розділі
Додавання Windows worker вузлів.
Увага:
Через контролер доступу NodeRestriction, ви не можете використовувати прапорець kubelet --node-labels для застосування обмежених міток (таких як node-role.kubernetes.io/*) під час ініціалізації.
Якщо ви спробуєте додати обмежені мітки за допомогою цього прапорця kubelet, вузол не зможе зареєструватися на сервері API.
Примітка:
У даному прикладі вважається, що доступ SSH увімкнено для користувача root. Якщо цього не відбувається, ви можете скопіювати файл admin.conf так, щоб його можна було отримати через обліковий запис іншого користувача, і використовувати цього користувача для scp.
Файл admin.conf надає користувачеві привілеї superuser у кластері. Його слід використовувати обережно. Для звичайних користувачів рекомендується генерувати унікальні облікові дані, до яких ви надаєте привілеї. Це можна зробити за допомогою команди kubeadm kubeconfig user --client-name <CN>. Ця команда виведе файл KubeConfig у STDOUT, який вам слід зберегти в файл та розповсюджувати поміж користувачів. Після цього надайте привілеї за допомогою kubectl create (cluster)rolebinding.