Створення кластера за допомогою kubeadm

За допомогою kubeadm ви можете створити мінімальний кластер Kubernetes, який відповідає найкращим практикам. Фактично, ви можете використовувати kubeadm для налаштування кластерf, який успішно пройде тести відповідності Kubernetes. kubeadm також підтримує інші функції життєвого циклу кластера, такі як bootstrap-токени nf оновлення кластера.

Інструмент kubeadm корисний у випадках, коли вам потрібен:

  • Простий спосіб спробувати Kubernetes, можливо, вперше.
  • Спосіб для поточних користувачів автоматизувати налаштування кластера та протестувати свій застосунок.
  • Компонент в інших екосистемах та/або інсталяторах із більшим функціоналом.

Ви можете встановлювати та використовувати kubeadm на різних машинах: на вашому ноутбуці, хмарних серверах, Raspberry Pi та інших. Незалежно від того, чи ви розгортаєте у хмарі, чи на власних серверах, ви можете інтегрувати kubeadm у системи постачання, такі як Ansible або Terraform.

Перш ніж ви розпочнете

Для виконання цього керівництва вам потрібно мати:

  • Одну чи кілька машин з операційною системою, сумісною з deb/rpm, наприклад: Ubuntu чи CentOS.
  • 2 ГБ або більше оперативної памʼяті на кожній машині — менше може призвести до обмежень для вашого застосунку.
  • Принаймні 2 процесори на машині, яку ви використовуєте як вузол панелі управління.
  • Повну мережеву доступність між усіма машинами в кластері. Ви можете використовувати як публічні, так і приватні мережі.

Також вам потрібно використовувати версію kubeadm, яка може розгортати ту версію Kubernetes, яку ви хочете використовувати у своєму новому кластері.

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

Загальний стан функцій інструменту kubeadm — Загальна Доступність (GA). Деякі підфункції ще перебувають на стадії активної розробки. Реалізація створення кластера може трохи змінитися, в міру розвитку інструменту, але загальна реалізація повинна бути досить стабільною.

Мета

  • Встановити Kubernetes з одною панеллю управління
  • Встановити мережу для Podʼів в кластері, так щоб вони могли спілкуватися один з одним

Інструкції

Підготовка хостів

Встановлення компонентів

Встановіть середовище виконання контейнерів та kubeadm на всіх хостах. За докладними інструкціями та іншими вимогами звертайтесь до Встановлення kubeadm.

Налаштування мережі

kubeadm, подібно до інших компонентів Kubernetes, намагається знайти доступну IP-адресу на мережевих інтерфейсах, повʼязаних із вказаним типовим шлюзом на хості. Ця IP-адреса використовується для оголошення та/або прослуховування, яке виконується компонентом.

Щоб дізнатися, яка це IP-адреса на Linux-хості, ви можете використовувати:

ip route show # Перегляньте рядок, який починається з "default via"

Компоненти Kubernetes не приймають мережевий інтерфейс як параметр, тому потрібно передавати власну IP-адресу як прапорець для всіх екземплярів компонентів, які потребують такої конфігурації.

Для налаштування IP-адреси оголошення API-сервера для вузлів панелі управління, створених із init та join, можна використовувати прапорець --apiserver-advertise-address. Переважно, варто встановлювати цю опцію в API-інтерфейсі kubeadm як InitConfiguration.localAPIEndpoint та JoinConfiguration.controlPlane.localAPIEndpoint.

Для kubelet на всіх вузлах опцію --node-ip можна передати в .nodeRegistration.kubeletExtraArgs всередині конфігураційного файлу kubeadm (InitConfiguration або JoinConfiguration).

Для роботи з двома стеками дивіться Підтримка двох стеків із kubeadm.

IP-адреси, які ви призначаєте компонентам панелі управління, стають частиною полів імені альтернативного підлеглого X.509 сертифікату. Зміна цих IP-адрес може вимагати підписання нових сертифікатів і перезапуску відповідних компонентів, щоб задіяти зміни у файлах сертифікатів. Дивіться Ручне поновлення сертифікатів для отримання докладнішої інформації з цього питання.

Підготовка необхідних образів контейнерів

Цей крок є необовʼязковим і застосовується тільки у випадку, якщо ви бажаєте, щоб kubeadm init та kubeadm join не завантажували типові образи контейнерів, які розміщені на registry.k8s.io.

Kubeadm має команди, які можуть допомогти вам попередньо витягти необхідні образи при створенні кластера без Інтернет-зʼєднання на його вузлах. Дивіться Запуск kubeadm без Інтернет-зʼєднання для отримання докладнішої інформації.

Kubeadm дозволяє вам використовувати власний репозиторій образів для необхідних образів. Дивіться Використання власних образів для отримання більше інформації.

Ініціалізація вузла панелі управління

Вузол панелі управління — це машина, де працюють компоненти панелі управління, включаючи etcd (база даних кластера) та API Server (з яким взаємодіє інструмент командного рядка kubectl).

  1. (Рекомендовано) Якщо у вас є плани оновлення цього кластера з одною панеллю управління за допомогою kubeadm до рівня високої доступності, ви повинні вказати --control-plane-endpoint, щоб встановити загальний endpoint для всіх вузлів панелі управління. Такий endpoint може бути іменем DNS або IP-адресою балансувальника навантаження.
  2. Виберіть надбудову мережі Pod та перевірте, чи для його налаштування потрібно передати будь-які аргументи в kubeadm init. Залежно від того, якого постачальника вибрано, вам може бути потрібно встановити значення --pod-network-cidr в значення, специфічне для постачальника. Дивіться Встановлення надбудови мережі Podʼів.
  3. (Необовʼязково) kubeadm намагається визначити середовище виконання контейнерів, використовуючи список відомих точок входу. Щоб використовувати інше середовище виконання контейнерів або якщо встановлено більше одного на наданому вузлі, вкажіть аргумент --cri-socket для kubeadm. Дивіться Встановлення середовища виконання.

Щоб ініціалізувати вузол панелі управління, виконайте:

kubeadm init <args>

Міркування щодо apiserver-advertise-address та ControlPlaneEndpoint

Хоча --apiserver-advertise-address може бути використано для встановлення оголошення адреси для API-сервера цього конкретного вузла панелі управління, --control-plane-endpoint може бути використано для встановлення загальної endpoint для всіх вузлів управління.

--control-plane-endpoint дозволяє використовувати як IP-адреси, так і DNS-імена, які можуть транслюватись у IP-адреси. Будь ласка, зверніться до вашого адміністратора мережі, щоб оцінити можливі рішення щодо такого перетворення.

Ось приклад:

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.

Додаткова інформація

Для отримання додаткової інформації щодо аргументів kubeadm init, див. посібник kubeadm.

Щоб налаштувати kubeadm init за допомогою файлу конфігурації, див. Використання kubeadm init з файлом конфігурації.

Для налаштування компонентів панелі управління, включаючи необовʼязкове призначення IPv6 для перевірки наявності для компонентів панелі управління та сервера etcd, надайте додаткові аргументи кожному компоненту, як описано на сторінці про додаткові аргументи.

Щоб переналаштувати кластер, який вже був створений, див. Переконфігурування кластера kubeadm.

Щоб знову виконати kubeadm init, спершу вам потрібно розібрати кластер.

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

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

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 <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Щоб кubectl працював для вашого користувача без прав root, виконайте ці команди, які є також частиною виводу kubeadm init:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Або, якщо ви є користувачем root, ви можете виконати:

export KUBECONFIG=/etc/kubernetes/admin.conf

Запишіть команду kubeadm join, яку виводить kubeadm init. Вам потрібна ця команда для приєднання вузлів до вашого кластера.

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

Встановлення надбудови для мережі Pod

Кілька зовнішніх проєктів надають мережі Pod Kubernetes за допомогою CNI, деякі з яких також підтримують Network Policy.

Див. список надбудов, які реалізують Модель мережі Kubernetes.

Будь ласка, звертайтеся до сторінки Встановлення надбудов для списку мережевих надбудов (може бути неповним), які підтримуються в Kubernetes. Ви можете встановити надбудову мережі Pod за допомогою наступної команди на вузлі панелі управління або вузлі, на якому є облікові дані kubeconfig:

kubectl apply -f <add-on.yaml>

Ви можете встановити лише одну мережу Pod на кластер.

Як тільки мережу Pod буде створено, ви можете підтвердити, що вона працює, перевіривши, що Pod CoreDNS у стані Running у виводі kubectl get pods --all-namespaces. І як тільки Pod CoreDNS запущено і він працює, ви можете продовжити приєднувати ваші вузли.

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

Керовані мітки вузлів

Типово kubeadm вмикає контролер доступу NodeRestriction, що обмежує, які мітки можуть бути самостійно застосовані kubelet під час реєстрації вузла. Документація контролера доступу описує, які мітки можна використовувати з параметром kubelet --node-labels. Мітка node-role.kubernetes.io/control-plane є такою обмеженою міткою, і kubeadm вручну застосовує її, використовуючи привілейований клієнт після створення вузла. Щоб зробити це вручну, ви можете використовувати kubectl label та переконатися, що використовується привілейований kubeconfig, такий як керований kubeadm /etc/kubernetes/admin.conf.

Ізоляція вузла панелі управління

Типово у вашому кластері не буде планувати розміщення Podʼів на вузлі панелі управління з міркувань безпеки. Якщо ви хочете мати можливість планувати Podʼи на вузлах панелі управління, наприклад, для кластера Kubernetes на одній машині, виконайте команду:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Вивід буде схожим на:

node "test-01" untainted
...

Це видалить позначку node-role.kubernetes.io/control-plane:NoSchedule з будь-яких вузлів, які мають її, включаючи вузли панелі управління, що означає, що планувальник зможе розміщувати Podʼи всюди.

Додатково ви можете виконати наступну команду, щоб видалити мітку node.kubernetes.io/exclude-from-external-load-balancers з вузла панелі управління, що виключає його зі списку бекенд-серверів:

kubectl label nodes --all node.kubernetes.io/exclude-from-external-load-balancers-

Приєднання вузлів

Вузли — це місця, де виконуються ваші завдання (контейнери та Podʼи, тощо). Щоб додати нові вузли до кластера, виконайте наступне для кожної машини:

  • Приєднайтеся за допомогою SSH до машини

  • Станьте користувачем root (наприклад, sudo su -)

  • Встановіть середовище виконання, якщо потрібно

  • Запустіть команду, з виводу kubeadm init. Наприклад:

    kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Якщо у вас немає токена, ви можете отримати його, виконавши наступну команду на вузлі панелі управління:

kubeadm token list

Вивід буде схожий на це:

TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
                                                                    'kubeadm init'.        kubeadm:
                                                                                           default-node-token

Типово дія токенів закінчуються через 24 години. Якщо ви приєднуєте вузол до кластера після закінчення дії токена, ви можете створити новий токен, виконавши наступну команду на вузлі панелі управління:

kubeadm token create

Вивід буде схожий на це:

5didvk.d09sbcov8ph2amjw

Якщо у вас немає значення --discovery-token-ca-cert-hash, ви можете отримати його, виконавши наступний ланцюжок команд на вузлі панелі управління:

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

Вивід буде схожий на:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

Вивід повинен виглядати приблизно так:

[preflight] Running pre-flight checks

... (журнал виводу процесу приєднання) ...

Node join complete:
* Certificate signing request sent to control-plane and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on control-plane to see this machine join.

Через кілька секунд ви повинні помітити цей вузол у виводі з kubectl get nodes, якщо ви його запустите на вузлі панелі управління.

(Необовʼязково) Керування кластером з інших машин, крім вузла панелі управління

Щоб отримати доступ до кластера з іншого компʼютера (наприклад, з ноутбука), вам потрібно скопіювати файл kubeconfig з вузла панелі управління на ваш робочий компʼютер так:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

(Необовʼязково) Проксі-доступ до API Server на localhost

Якщо ви хочете підʼєднатися до API Server ззовні кластера, ви можете використовувати kubectl proxy:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

Тепер ви можете отримати доступ до API Server локально за адресою http://localhost:8001/api/v1.

Очищення

Якщо ви використовували тимчасові сервери для свого кластера для тестування, ви можете вимкнути їх і не проводити додаткового очищення. Ви можете використовувати kubectl config delete-cluster, щоб видалити ваші локальні посилання на кластер.

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

Видалення вузла

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

kubectl drain <імʼя вузла> --delete-emptydir-data --force --ignore-daemonsets

Перед видаленням вузла скиньте стан, встановлений за допомогою kubeadm:

kubeadm reset

Процес скидання не відновлює або не очищає правила iptables чи таблиці IPVS. Якщо ви хочете скинути iptables, вам слід це зробити вручну:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

Якщо ви хочете скинути таблиці IPVS, вам слід виконати наступну команду:

ipvsadm -C

Тепер видаліть вузол:

kubectl delete node <імʼя вузла>

Якщо ви хочете почати спочатку, запустіть kubeadm init або kubeadm join з відповідними аргументами.

Очищення панелі управління

Ви можете використовувати kubeadm reset на хості панелі управління для виконання очищення.

Дивіться довідкову документацію для kubeadm reset для отримання додаткової інформації щодо цієї підкоманди та її параметрів.

Політика розбіжності версій

Хоча kubeadm дозволяє розбіжність версій для деяких компонентів, якими він керує, рекомендується вирівнювати версію kubeadm із версіями компонентів панелі управління, kube-proxy та kubelet.

Відхилення версії kubeadm від версії Kubernetes

kubeadm можна використовувати із компонентами Kubernetes, які мають таку саму версію, як і kubeadm, або на одну версію застаріше. Версію Kubernetes можна вказати для kubeadm, використовуючи прапорець --kubernetes-version команди kubeadm init або поле ClusterConfiguration.kubernetesVersion при використанні --config. Ця опція буде контролювати версії kube-apiserver, kube-controller-manager, kube-scheduler та kube-proxy.

Приклад:

  • kubeadm має версію 1.30
  • kubernetesVersion повинна бути 1.30 або 1.29

Відхилення версії kubeadm від версії kubelet

Аналогічно до версії Kubernetes, kubeadm можна використовувати з версією kubelet, яка є такою ж самою версією, що й kubeadm, або на три версії старішою.

Приклад:

  • kubeadm має версію 1.30
  • kubelet на хості повинен мати версію 1.30, 1.29, 1.28 або 1.27

Відхилення версії kubeadm від kubeadm

Є певні обмеження на те, як можна використовувати команди kubeadm на існуючих вузлах або цілих кластерах, під керуванням kubeadm.

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

Приклад для kubeadm join:

  • версія kubeadm 1.30 використовувалася для створення кластера за допомогою kubeadm init
  • Приєднувані вузли повинні використовувати бінарний файл kubeadm версії 1.30

Вузли, які оновлюються, повинні використовувати версію kubeadm, яка є тією ж самою MINOR версією або на одну MINOR версію новішою, ніж версія kubeadm, яка використовувалася для управління вузлом.

Приклад для kubeadm upgrade:

  • версія kubeadm 1.29 використовувалася для створення або оновлення вузла
  • Версія kubeadm, використана для оновлення вузла, повинна бути на 1.29 або 1.30

Щоб дізнатися більше про різницю версій між різними компонентами Kubernetes, див. Політику відхилень версій.

Обмеження

Витривалість кластера

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

Обхідні шляхи:

Платформна сумісність

Пакунки та бінарники kubeadm для deb/rpm будуються для amd64, arm (32-біт), arm64, ppc64le та s390x, відповідабть пропозиції щодо багатоплатформовості.

Багатоплатформові образи контейнерів для вузла панелі управління та надбудов також підтримуються з версії 1.12.

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

Усунення несправностей

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

Що далі

Зворотній звʼязок

Змінено June 20, 2024 at 12:44 PM PST: Sync changest from andygol/k8s-website (36d05bc8a1)