Операційне середовище

• 1: Середовище виконання контейнерів
• 2: Встановлення Kubernetes за допомогою інструментів розгортання
• 2.1: Запуск кластерів з kubeadm
• 2.1.1: Встановлення kubeadm
• 2.1.2: Розвʼязання проблем kubeadm
• 2.1.3: Створення кластера за допомогою kubeadm
• 2.1.4: Налаштування компонентів за допомогою kubeadm API
• 2.1.5: Варіанти топології високої доступності (HA)
• 2.1.6: Створення високодоступних кластерів за допомогою kubeadm
• 2.1.7: Налаштування високодоступного кластера etcd за допомогою kubeadm
• 2.1.8: Налаштування кожного kubelet у кластері за допомогою kubeadm
• 2.1.9: Підтримка подвійного стека за допомогою kubeadm
• 3: Хмарні рішення під ключ

1 - Середовище виконання контейнерів

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

Kubernetes 1.31 вимагає використання runtime, який відповідає специфікації Container Runtime Interface (CRI).

Дивіться Підтримка версій CRI для отримання додаткової інформації.

Ця сторінка містить огляд того, як використовувати кілька поширених середовищ виконання контейнерів з Kubernetes.

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

Встановлення та налаштування передумов

Конфігурація мережі

Стандартно ядро Linux не дозволяє маршрутизувати пакети IPv4 між інтерфейсами. Більшість реалізацій мережі кластера Kubernetes змінить це налаштування (якщо це потрібно), але деякі можуть очікувати, що адміністратор зробить це за них. (Деякі також можуть очікувати встановлення інших параметрів sysctl, завантаження модулів ядра тощо; перевірте документацію для вашої конкретної мережної реалізації.)

Увімкнення маршрутизації IPv4 пакетів

Для увімкнення вручну маршрутизації IPv4 пакетів:

# параметри sysctl, необхідні для налаштування, параметри зберігаються після перезавантаження
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Застосувати параметри sysctl без перезавантаження
sudo sysctl --system

Перевірте, що net.ipv4.ip_forward встановлено на 1 за допомогою:

sysctl net.ipv4.ip_forward

Драйвери cgroup

У Linux використовуються control groups для обмеження ресурсів, які виділяються процесам.

І kubelet, і відповідні середовища виконання контейнерів потребують взаємодії з cgroup для управління ресурсами для Podʼів та контейнерів та встановлення ресурсів, таких як обсяг памʼяті та обчислювальних ресурсів центрального процесора, а також їх обмежень. Щоб взаємодіяти з cgroup, kubelet та середовище виконання контейнерів повинні використовувати драйвер cgroup. Важливо, щоб kubelet та середовище виконання контейнерів використовували один і той самий драйвер cgroup та були налаштовані однаково.

Існують два доступні драйвери cgroup:

• cgroupfs
• systemd

Драйвер cgroupfs

Драйвер cgroupfs є стандартним драйвером cgroup в kubelet. Коли використовується драйвер cgroupfs, kubelet та середовище виконання контейнерів безпосередньо взаємодіють з файловою системою cgroup для їх налаштування.

Драйвер cgroupfs не рекомендується використовувати, коли systemd є системою ініціалізації, оскільки systemd очікує наявності єдиного менеджера cgroup в системі. Крім того, якщо використовуєте cgroup v2, використовуйте драйвер systemd cgroup замість cgroupfs.

Драйвер cgroup системи systemd

Коли systemd вибрано як систему ініціалізації в дистрибутиві Linux, процес ініціалізації створює і використовує кореневу групу cgroup (cgroup) та діє як менеджер cgroup.

systemd тісно інтегрований з cgroup та розміщує по одній cgroup на кожному юніті systemd. В результаті, якщо ви використовуєте systemd як систему ініціалізації з драйвером cgroupfs, система отримує два різних менеджери cgroup.

Наявність двох менеджерів cgroup призводить до двох видів доступних та використаних ресурсів в системі. У деяких випадках вузли, які налаштовані на використання cgroupfs для kubelet та середовище виконання контейнерів, але використовують systemd для інших процесів, стають нестійкими при зростанні тиску на ресурси.

Підхід до помʼякшення цієї нестійкості — використовувати systemd як драйвер cgroup для kubelet та середовище виконання контейнерів, коли systemd вибрано системою ініціалізації.

Щоб встановити systemd як драйвер cgroup, відредагуйте в KubeletConfiguration опцію cgroupDriver та встановіть її в systemd. Наприклад:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

Якщо ви конфігуруєте systemd як драйвер cgroup для kubelet, вам також слід налаштувати systemd як драйвер cgroup для середовища виконання контейнерів. Дивіться документацію для вашого середовища виконання контейнерів для отримання докладних інструкцій. Наприклад:

• containerd
• CRI-O

У Kubernetes 1.31, з увімкненою функціональною можливістю KubeletCgroupDriverFromCRI і середовищем виконання контейнерів, яке підтримує RuntimeConfig CRI RPC, kubelet автоматично визначає відповідний драйвер cgroup з runtime, та ігнорує налаштування cgroupDriver у конфігурації kubelet.

Міграція на драйвер systemd в кластерах, що керуються kubeadm

Якщо ви хочете мігрувати на драйвер systemd cgroup в кластерах, що керуються kubeadm, дотримуйтеся рекомендацій налаштування драйвера cgroup.

Підтримка версій CRI

Ваше середовище виконання контейнерів повинне підтримувати принаймні версію v1alpha2 інтерфейсу контейнера.

Kubernetes починаючи з v1.26 працює тільки з v1 CRI API. Попередні версії типово використовують версію v1, проте, якщо середовище виконання контейнерів не підтримує v1 API, kubelet перемкнеться на використання (застарілої) версії API v1alpha2.

Середовища виконання контейнерів

containerd

У цьому розділі описані необхідні кроки для використання containerd як середовища виконання контейнерів (CRI).

Щоб встановити containerd на вашу систему, дотримуйтеся інструкцій з Початок роботи з containerd. Поверніться до цього кроку, якщо ви створили файл конфігурації config.toml.

• Linux
• Windows

У Linux, типовий CRI-socket для containerd — /run/containerd/containerd.sock. У Windows, типова CRI-точка доступу — npipe://./pipe/containerd-containerd.

Налаштування драйвера cgroup systemd

Щоб використовувати драйвер cgroup systemd в /etc/containerd/config.toml з runc, встановіть

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
   

 SystemdCgroup = true

Драйвер cgroup systemd є рекомендованим, якщо ви використовуєте cgroup v2.

Після внесення змін в перезавантажте containerd.

sudo systemctl restart containerd

Використовуючи kubeadm, вручну налаштуйте cgroup драйвер для kubelet.

У Kubernetes v1.28 ви можете увімкнути alpha-функцію автоматичного виявлення драйвера cgroup. Дивіться systemd cgroup driver для отримання додаткової інформації.

Перевизначення образу пісочниці (pause)

У вашій конфігурації containerd ви можете перевизначити образ, встановивши наступну конфігурацію:

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.2"

Можливо, вам доведеться також перезапустити containerd, якщо ви оновили файл конфігурації: systemctl restart containerd.

CRI-O

У цьому розділі наведено необхідні кроки для встановлення CRI-O як середовища виконання контейнерів.

Для встановлення CRI-O слід дотримуватися Інструкцій з встановлення CRI-O.

Драйвер cgroup

CRI-O використовує стандартний драйвер cgroup, який ймовірно буде працювати добре для вас. Для перемикання на драйвер cgroupfs, відредагуйте /etc/crio/crio.conf або розмістіть конфігурацію у вигляді окремого файлу в /etc/crio/crio.conf.d/02-cgroup-manager.conf, наприклад:

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

Важливо відзначити змінений conmon_cgroup, який повинен бути встановлений в значення pod при використанні CRI-O з cgroupfs. Зазвичай необхідно синхронізувати конфігурацію драйвера cgroup kubelet (зазвичай встановлюється за допомогою kubeadm) та CRI-O.

У Kubernetes v1.28 можна ввімкнути автоматичне виявлення драйвера cgroup як альфа-функцію. Див. драйвер cgroup systemd докладніше.

Для CRI-O типовий сокет CRI — /var/run/crio/crio.sock.

Перевизначення образу пісочниці (pause)

У вашій конфігурації CRI-O ви можете встановити наступне значення конфігурації:

[crio.image]
pause_image="registry.k8s.io/pause:3.6"

Цей параметр конфігурації підтримує перезавантаження конфігурації в реальному часі для застосування цих змін: systemctl reload crio або відсилання сигналу SIGHUP процесу crio.

Docker Engine

1. На кожному з ваших вузлів встановіть Docker для вашого дистрибутиву Linux; дивіться Інсталяція Docker Engine.

2. Встановіть cri-dockerd, дотримуючись інструкцій у репозиторій з вихідним кодом.

Для cri-dockerd типовий сокет CRI — /run/cri-dockerd.sock.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) є комерційно доступною реалізацією середовища виконання контейнерів, яка була раніше відома як Docker Enterprise Edition.

Ви можете використовувати Mirantis Container Runtime з Kubernetes за допомогою відкритої реалізації компонента cri-dockerd, який входить до складу MCR.

Для отримання докладнішої інформації щодо встановлення Mirantis Container Runtime дивіться посібник з розгортання MCR.

Перевірте юніт systemd із назвою cri-docker.socket, щоб дізнатися шлях до сокета CRI.

Перевизначення образу пісочниці (pause)

Адаптер cri-dockerd приймає аргумент командного рядка для зазначення образу контейнера, який слід використовувати як інфраструктурний контейнер для Podʼа («pause image»). Аргумент командного рядка, який слід використовувати — --pod-infra-container-image.

Що далі

Так само як і середовище виконання контейнерів, вашому кластеру знадобиться втулок мережі.

2 - Встановлення Kubernetes за допомогою інструментів розгортання

Існує багато методів та інструментів для встановлення власного промислового кластера Kubernetes. Наприклад:

• kubeadm
• Cluster API: Підпроєкт Kubernetes зосереджений на наданні декларативних API та інструментарію для спрощення створення, оновлення та експлуатації кількох кластерів Kubernetes.
• kops: автоматизований інструмент для розгортання кластера. За навчальними матеріалами, найкращими практиками, параметрами конфігурації та інформацією про спільноту звертайтесь до вебсайту kOps.
• kubespray: набір плейбуків Ansible, інвентарю, інструментів керування та знання про загальні завдання з конфігурації OS/Kubernetes. Ви можете звертатися до спільноти на каналі Slack #kubespray.

2.1 - Запуск кластерів з kubeadm

2.1.1 - Встановлення kubeadm

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

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

• У вас має бути сумісний хост на основі Linux. Проєкт Kubernetes надає загальні інструкції для дистрибутивів Linux, зокрема на базі Debian та Red Hat, а також для дистрибутивів без менеджера пакетів.
• 2 ГБ або більше оперативної памʼяті на кожній машині (менше може залишити мало місця для ваших застосунків).
• 2 процесори або більше для машин панелі управління.
• Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа підходить).
• Унікальні імена хостів, MAC-адреси та product_uuid для кожного вузла. Див. тут для отримання докладнішої інформації.
• Відкриті певні порти на ваших машинах. Див. тут для отримання докладнішої інформації.

Перевірка унікальності MAC-адрес та product_uuid для кожного вузла

• Ви можете отримати MAC-адресу мережевих інтерфейсів за допомогою команди ip link або ifconfig -a.
• product_uuid можна перевірити за допомогою команди sudo cat /sys/class/dmi/id/product_uuid.

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

Перевірка мережевих адаптерів

Якщо у вас є більше одного мережевого адаптера і компоненти Kubernetes недоступні за стандартним маршрутом, ми рекомендуємо додати IP-маршрут(и), щоб адреси кластера Kubernetes відповідали конкретному адаптеру.

Перевірка необхідних портів

Ці необхідні порти повинні бути відкриті для взаємодії компонентів Kubernetes між собою. Ви можете використовувати інструменти, такі як netcat, щоб перевірити, чи відкритий порт. Наприклад:

nc 127.0.0.1 6443 -v

Мережевий втулок Podʼа, який ви використовуєте, також може вимагати, щоб певні порти були відкриті. Оскільки це відрізняється для кожного мережевого втулка, будь ласка, перегляньте їх документацію про те, які порти їм потрібні.

Конфігурація swap

Стандартно kubelet не запускається, якщо на вузлі виявлено swap-памʼять. Це означає, що swap слід або вимкнути, або дозволити його використання kubelet.

• Щоб дозволити swap, додайте failSwapOn: false до конфігурації kubelet або як аргумент командного рядка. Примітка: навіть якщо вказано failSwapOn: false, робочі навантаження не матимуть стандартно доступу до swap. Це можна змінити, встановивши параметр swapBehavior, знову ж таки в конфігураційному файлі kubelet. Для використання swap, встановіть значення swapBehavior інше ніж стандартне налаштування NoSwap. Докладніше дивіться у розділі Управління памʼяттю swap.
• Щоб вимкнути swap, можна використовувати команду sudo swapoff -a для тимчасового відключення swap. Щоб зробити цю зміну постійною після перезавантаження, переконайтеся, що swap вимкнено у конфігураційних файлах, таких як /etc/fstab, systemd.swap, залежно від того, як це налаштовано у вашій системі.

Встановлення середовища виконання контейнерів

Для запуску контейнерів у Pod, Kubernetes використовує середовище виконання контейнерів.

Стандартно Kubernetes використовує Container Runtime Interface (CRI), щоб взаємодіяти з обраним середовищем.

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

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

Дивіться середовища виконання контейнерів для отримання додаткової інформації.

Наведені нижче таблиці містять відомі точки доступу для підтримуваних операційних систем:

• Linux
• Windows

Встановлення kubeadm, kubelet та kubectl

Ви повинні встановити ці пакунки на всіх своїх машинах:

• kubeadm: команда для ініціалізації кластера.

• kubelet: компонент, який працює на всіх машинах у вашому кластері та виконує такі дії, як запуск підсистем та контейнерів.

• kubectl: утиліта командного рядка для взаємодії з вашим кластером.

kubeadm не буде встановлювати або керувати kubelet або kubectl за вас, тому вам потрібно забезпечити відповідність їх версії панелі управління Kubernetes, яку ви хочете, щоб kubeadm встановив для вас. Якщо цього не зробити, існує ризик змішування версій, що може призвести до непередбачуваної та неправильної роботи. Однак одина невелика розбіжність між kubelet та панеллю управління підтримується, але версія kubelet ніколи не повинна перевищувати версію API сервера. Наприклад, kubelet версії 1.7.0 буде повністю сумісний з API-сервером версії 1.8.0, але не навпаки.

Щодо інформації про встановлення kubectl, див. Встановлення та налаштування kubectl.

Докладніше про відмінності версій:

• Політика версій та відмінностей Kubernetes
• Політика відмінностей версій для kubeadm

• Debian-подібні дистрибутиви
• Red Hat-подібні дистрибутиви
• Без менеджера пакунків

CNI_PLUGINS_VERSION="v1.3.0"
ARCH="amd64"
DEST="/opt/cni/bin"
sudo mkdir -p "$DEST"
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz

DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"

CRICTL_VERSION="v1.31.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}

RELEASE_VERSION="v0.16.2"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service
sudo mkdir -p /usr/lib/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

sudo systemctl enable --now kubelet

Kubelet тепер перезавантажується кожні кілька секунд, чекаючи в циклі crashloop на вказівки від kubeadm.

Налаштування драйвера cgroup

Як середовище виконання контейнерів, так і kubelet мають властивість, відому як "cgroup driver", яка є важливою для управління cgroup на машинах з операційною системою Linux.

Розвʼязання проблем

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

Що далі

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

2.1.2 - Розвʼязання проблем kubeadm

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

Якщо вашої проблеми немає в переліку нижче, будь ласка, скористайтесь настпуним:

• Ви вважаєте, що це помилка в kubeadm:

  • Відвідайте github.com/kubernetes/kubeadm, пошукайте в списку наявних повідомлень.
  • Якщо ви не знайшли свою проблему, створіть нове повідомлення про проблему використовуючи готовий шаблон.

• Ви не впевнені, що це проблема в роботі kubeadm, ви можете запитати в Slack в каналі #kubeadm, або поставити питання на Stack Overflow. Будь ласка, додайте теґи #kubeadm та #kubernetes.

Неможливо приєднати вузол v1.18 до кластера v1.17 через відсутність RBAC

У версії v1.18 kubeadm додав запобігання приєднання вузла до кластера, якщо вузол з таким самим імʼям вже існує. Це вимагало додавання RBAC для користувача bootstrap-token для можливості виконання операції GET обʼєкта Node.

Однак це викликає проблему, коли kubeadm join з v1.18 не може приєднатися до кластера, створеного за допомогою kubeadm v1.17.

Для того, щоб оминути цю проблему у вас є два варіанти:

Виконайте kubeadm init phase bootstrap-token на вузлі панелі управління за допомогою kubeadm v1.18. Зауважте, що це дозволяє інші дозволи bootstrap-token.

або

Застосуйте наступний RBAC вручну за допомогою kubectl apply -f ...:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubeadm:get-nodes
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubeadm:get-nodes
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubeadm:get-nodes
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:bootstrappers:kubeadm:default-node-token

ebtables або подібний виконавчий файл не знайдений під час встановлення

Якщо ви бачите наступні попередження під час виконання kubeadm init:

[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path

Тоді вам може бракувати ebtables, ethtool або подібного виконавчого файлу на вашому вузлі. Ви можете встановити їх за допомогою наступних команд:

• Для користувачів Ubuntu/Debian виконайте apt install ebtables ethtool.
• Для користувачів CentOS/Fedora виконайте yum install ebtables ethtool.

kubeadm блокується під час очікування на панель управління під час встановлення

Якщо ви помічаєте, що kubeadm init зупиняється після виведення наступного рядка:

[apiclient] Created API client, waiting for the control plane to become ready

Це може бути спричинено кількома проблемами. Найбільш поширеними є:

• проблеми з мережевим підключенням. Перш ніж продовжувати, перевірте, чи ваша машина має повне підключення до мережі.
• драйвер cgroup контейнера відрізняється від драйвера kubelet cgroup. Щоб зрозуміти, як правильно налаштувати це, див. Налаштування драйвера cgroup.
• контейнери панелі управління впадають в цикл або зупиняються. Ви можете перевірити це, використовуючи docker ps та вивчаючи кожен контейнер за допомогою docker logs. Для інших середовищ виконання контейнерів, див. Налагодження вузлів Kubernetes за допомогою crictl.

kubeadm блокується під час видалення керованих контейнерів

Наступне може трапитися, якщо середовище виконання контейнерів зупиняється і не видаляє жодних керованих контейнерів Kubernetes:

sudo kubeadm reset

[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)

Можливий варіант вирішення — перезапустити середовище виконання контейнерів, а потім знову запустити kubeadm reset. Ви також можете використовувати crictl для налагодження стану середовища виконання контейнерів. Див. Налагодження вузлів Kubernetes за допомогою crictl.

Podʼи у стані RunContainerError, CrashLoopBackOff або Error

Відразу після виконання kubeadm init не повинно бути жодних контейнерів у таких станах.

• Якщо є контейнери в одному з цих станів відразу після kubeadm init, будь ласка, створіть тікет в репозиторії kubeadm. coredns (або kube-dns) повинен перебувати у стані Pending до моменту розгортання додатка для мережі.
• Якщо ви бачите контейнери у стані RunContainerError, CrashLoopBackOff або Error після розгортання додатка для мережі та нічого не відбувається з coredns (або kube-dns), дуже ймовірно, що додаток Pod Network, який ви встановили, є пошкодженим. Можливо, вам потрібно надати йому більше привілеїв RBAC або використовувати новішу версію. Будь ласка, створіть тікет в системі відстеження проблем постачальника Pod Network та очікуйте розвʼязання проблеми там.

coredns застрягає у стані Pending

Це очікувано і є частиною дизайну. kubeadm є агностичним до мережі, тому адміністратор повинен встановити вибраний додаток для мережі за власним вибором. Вам потрібно встановити Pod Network, перш ніж coredns може бути повністю розгорнутим. Таким чином, стан Pending перед налаштуванням мережі є нормальним.

Сервіси HostPort не працюють

Функціональність HostPort та HostIP доступна залежно від вашого провайдера Pod Network. Будь ласка, звʼяжіться з автором додатка Pod Network, щоб дізнатися, чи функціональність HostPort та HostIP доступна.

Перевірено, що Calico, Canal та Flannel CNI підтримують HostPort.

Для отримання додаткової інформації перегляньте документацію CNI portmap.

Якщо ваш постачальник мережі не підтримує втулок CNI portmap, можливо, вам доведеться використовувати функцію NodePort для сервісів або використовуйте HostNetwork=true.

До Podʼів неможливо отримати доступ за їх Service IP

• Багато додатків для мережі ще не увімкнули режим hairpin, який дозволяє Podʼам звертатися до себе за їх Service IP. Це повʼязано з CNI. Будь ласка, звʼяжіться з постачальником додатка для мережі, щоб дізнатися про останній статус підтримки режиму hairpin.

• Якщо ви використовуєте VirtualBox (безпосередньо, або через Vagrant), вам слід переконатися, що hostname -i повертає маршрутизовану IP-адресу. Типово перший інтерфейс підключений до немаршрутизованої мережі тільки для хосту. Як тимчасовий варіант, ви можете змінити /etc/hosts, подивіться цей Vagrantfile для прикладу.

Помилки сертифіката TLS

Наступна помилка вказує на можливу несумісність сертифікатів.

# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

• Перевірте, що файл $HOME/.kube/config містить дійсний сертифікат, та перегенеруйте сертифікат за необхідності. Сертифікати у файлі конфігурації kubeconfig закодовані у форматі base64. Команда base64 --decode може бути використана для декодування сертифіката, а openssl x509 -text -noout може бути використано для перегляду інформації про сертифікат.

• Скасуйте змінну середовища KUBECONFIG за допомогою:

  unset KUBECONFIG
  

  Або встановіть його в типове розташування KUBECONFIG:

  export KUBECONFIG=/etc/kubernetes/admin.conf
  

• Іншим обхідним методом є перезапис наявного kubeconfig для користувача "admin":

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

Помилка ротації сертифіката клієнта Kubelet

Стандартно kubeadm налаштовує kubelet на автоматичну ротацію сертифікатів клієнта за допомогою символічного посилання /var/lib/kubelet/pki/kubelet-client-current.pem, вказаного в /etc/kubernetes/kubelet.conf. Якщо цей процес ротації завершиться невдачею, ви можете побачити помилки, такі як x509: certificate has expired or is not yet valid в журналах kube-apiserver. Щоб виправити цю проблему, слід виконати наступні кроки:

1. Зробіть резервну копію та видаліть файли /etc/kubernetes/kubelet.conf та /var/lib/kubelet/pki/kubelet-client* з несправного вузла.

2. З робочого вузла контрольної площини кластера, де є /etc/kubernetes/pki/ca.key, виконайте kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE повинно бути встановлено на імʼя наявного несправного вузла в кластері. Вручну змініть отриманий kubelet.conf, щоб відкоригувати імʼя та endpoint сервера, або передайте kubeconfig user --config (див. see Створення файлів kubeconfig для додаткових користувачів). Якщо в у вашому кластері немає ca.key, ви повинні вручну підписати вбудовані сертифікати в kubelet.conf.

3. Скопіюйте цей отриманий kubelet.conf в /etc/kubernetes/kubelet.conf на несправному вузлі.

4. Перезапустіть kubelet (systemctl restart kubelet) на несправному вузлі та зачекайте, доки /var/lib/kubelet/pki/kubelet-client-current.pem буде відновлено.

5. Вручну відредагуйте kubelet.conf, щоб вказати на обертані сертифікати клієнта kubelet, замінивши client-certificate-data та client-key-data на:

   client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
   client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
   

6. Перезапустіть kubelet.

7. Переконайтеся, що вузол стає Ready.

Типовий мережевий інтерфейс NIC при використанні Flannel як мережі для Podʼів у Vagrant

Наступна помилка може свідчити про те, що щось пішло не так у мережі Podʼів:

Error from server (NotFound): the server could not find the requested resource

• Якщо ви використовуєте Flannel як мережу для Podʼів у Vagrant, тоді вам доведеться вказати типове імʼя інтерфейсу для Flannel.

  Зазвичай Vagrant призначає два інтерфейси всім віртуальним машинам. Перший, для якого всі хости мають IP-адресу 10.0.2.15, призначено для зовнішнього трафіку, який проходить через NAT.

  Це може призвести до проблем із Flannel, яка стандартно він обирає перший інтерфейс на хості. Це призводить до того, що всі хости вважають, що у них однакова публічна IP-адреса. Щоб цього уникнути, передайте прапорець --iface eth1 для Flannel, щоб обрати другий інтерфейс.

Непублічні IP-адреси для контейнерів

У деяких ситуаціях команди kubectl logs та kubectl run можуть повертати помилки на функціональному кластері:

Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host

• Це може бути викликано використанням Kubernetes IP-адреси, яка не може взаємодіяти з іншими IP-адресами на одній підмережі, можливо, через політику провайдера машин.

• DigitalOcean призначає публічний IP для eth0, а також приватний IP для внутрішнього використання як анкера для їхньої функції змінного IP. Однак, kubelet вибере останній як InternalIP вузла замість першого.

  Використовуйте ip addr show для перевірки цього сценарію, а не ifconfig, оскільки ifconfig не показує обрану адресу IP для аліаса. Альтернативно, API-точка, специфічна для DigitalOcean, дозволяє запитувати анкер IP-адресу з машини:

  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
  

  Обхідним рішенням є повідомлення kubelet, яку IP використовувати за допомогою --node-ip. Коли використовується DigitalOcean, це може бути публічний IP (призначений eth0) або приватний IP (призначений eth1), якщо ви хочете використовувати додаткову приватну мережу. Розділ kubeletExtraArgs структури kubeadm NodeRegistrationOptions може бути використаний для цього.

  Потім перезапустіть kubelet:

  systemctl daemon-reload
  systemctl restart kubelet
  

Podʼи coredns перебувають у стані CrashLoopBackOff або Error

Якщо у вас є вузли, які працюють із SELinux та старішою версією Docker, ви можете стикнутися зі сценарієм, де Podʼи coredns не запускаються. Щоб вирішити це, ви можете спробувати один з наступних варіантів:

• Оновіться до новішої версії Docker.

• Вимкніть SELinux.

• Змініть розгортання coredns, встановивши allowPrivilegeEscalation в true:

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

Іншою причиною того, що CoreDNS має CrashLoopBackOff, є те, що Pod CoreDNS, розгорнутий в Kubernetes, виявляє цикл. Існують різні обхідні варіанти, щоб уникнути спроб перезапуску Podʼа CoreDNS кожного разу, коли CoreDNS виявляє цикл та виходить.

Podʼі etcd постійно перезапускаються

Якщо ви стикаєтеся з такою помилкою:

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""

Ця проблема виникає, якщо ви використовуєте CentOS 7 з Docker 1.13.1.84. Ця версія Docker може завадити kubelet виконуватися в контейнері etcd.

Для усунення цієї проблеми виберіть один з наступних варіантів:

• Поверніться до попередньої версії Docker, наприклад, 1.13.1-75

  yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
  

• Встановіть одну з новіших рекомендованих версій, наприклад 18.06:

  sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
  yum install docker-ce-18.06.1.ce-3.el7.x86_64
  

Неможливо передати розділений комою список значень аргументів під прапорцем --component-extra-args

Прапорці kubeadm init, такі як --component-extra-args, дозволяють передавати власні аргументи компоненту панелі управління, наприклад, kube-apiserver. Однак цей механізм обмежений через тип, який використовується для розбору значень (mapStringString).

Якщо ви вирішите передати аргумент, який підтримує кілька значень, розділених комами, такий як --apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists", цей прапорець видасть помилку flag: malformed pair, expect string=string. Це відбувається через те, що список аргументів для --apiserver-extra-args очікує пари key=value, і в цьому випадку NamespacesExists розглядається як ключ, якому не вистачає значення.

У іншому випадку ви можете спробувати розділити пари key=value так: --apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists", але це призведе до того, що ключ enable-admission-plugins матиме лише значення NamespaceExists.

Відомий обхід цього — використання файлу конфігурації kubeadm.

kube-proxy плануєтья до того, як вузол ініціалізовано cloud-controller-manager

У сценаріях хмарних провайдерів kube-proxy може виявитися запланованим на нових робочих вузлах до того, як cloud-controller-manager ініціалізує адреси вузла. Це призводить до того, що kube-proxy не може належним чином отримати IP-адресу вузла, і це має негативний вплив на функцію проксі, що керує балансуванням навантаження.

У kube-proxy Pods можна побачити наступну помилку:

server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP

Відомий варіант рішення — виправлення DaemonSet kube-proxy, щоб дозволити його планування на вузлах панелі управління незалежно від їхніх умов, утримуючи його подальше від інших вузлів, доки їхні початкові умови зберігаються:

kubectl -n kube-system patch ds kube-proxy -p='{
  "spec": {
    "template": {
      "spec": {
        "tolerations": [
          {
            "key": "CriticalAddonsOnly",
            "operator": "Exists"
          },
          {
            "effect": "NoSchedule",
            "key": "node-role.kubernetes.io/control-plane"
          }
        ]
      }
    }
  }
}'

Тікет, що відстежує цю проблему, розташовано тут.

/usr монтується тільки для читання на вузлах

У дистрибутивах Linux, таких як Fedora CoreOS або Flatcar Container Linux, тека /usr монтується як файлова система тільки для читання. Для підтримки flex-volume компоненти Kubernetes, такі як kubelet і kube-controller-manager, використовують типовий шлях /usr/libexec/kubernetes/kubelet-plugins/volume/exec/, проте тека flex-volume має бути доступною для запису, щоб ця функція працювала.

Для усунення цієї проблеми ви можете налаштувати теку flex-volume, використовуючи файл конфігурації kubeadm.

На основному вузлі панелі управління (створеному за допомогою kubeadm init) передайте наступний файл, використовуючи параметр --config:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "flex-volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

При долученні вузлів:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

Альтернативно ви можете змінити файл /etc/fstab, щоб зробити монтування /usr доступним для запису, проте будьте обізнані, що це змінює принцип дизайну дистрибутиву Linux.

kubeadm upgrade plan виводить повідомлення про помилку context deadline exceeded

Це повідомлення про помилку виводиться при оновленні кластера Kubernetes за допомогою kubeadm у випадку використання зовнішнього etcd. Це не критична помилка і виникає через те, що старі версії kubeadm виконують перевірку версії зовнішнього кластера etcd. Ви можете продовжити з kubeadm upgrade apply ....

Цю проблему виправлено у версії 1.19.

kubeadm reset відмонтовує /var/lib/kubelet

Якщо /var/lib/kubelet має точку монтування, виконання kubeadm reset фактично відмонтує його.

Для уникнення цієї проблеми повторно замонтуйте каталог /var/lib/kubelet після виконання операції kubeadm reset.

Це вдосконалення було введено в kubeadm 1.15. Проблема виправлена в 1.20.

Неможливо безпечно використовувати metrics-server в кластері kubeadm

У кластері kubeadm metrics-server може бути використаний в небезпечний спосіб, передаючи йому параметр --kubelet-insecure-tls. Це не рекомендується для промислових кластерів.

Якщо ви хочете використовувати TLS між metrics-server та kubelet, виникає проблема, оскільки kubeadm розгортає самопідписний службовий сертифікат для kubelet. Це може призвести до наступних помилок з боку metrics-server:

x509: certificate signed by unknown authority
x509: certificate is valid for IP-foo not IP-bar

Дивіться Увімкнення підписаних службових сертифікатів kubelet, щоб зрозуміти, як налаштувати kubelet в кластері kubeadm для отримання належно підписаних службових сертифікатів.

Також перегляньте Як запустити metrics-server безпечно.

Оновлення не вдається через незмінність хешу etcd

Це стосується лише оновлення вузла панелі управління за допомогою бінарного файлу kubeadm v1.28.3 або пізніше, при умові, що вузол в цей час керується версіями kubeadm v1.28.0, v1.28.1 або v1.28.2.

Ось повідомлення про помилку, яке може виникнути:

[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
[upgrade/etcd] Waiting for previous etcd to become available
I0907 10:10:09.109104    3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10
[upgrade/etcd] Etcd was rolled back and is now available
static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests
	cmd/kubeadm/app/phases/upgrade/staticpods.go:525
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent
	cmd/kubeadm/app/phases/upgrade/staticpods.go:254
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade
	cmd/kubeadm/app/phases/upgrade/staticpods.go:338
...

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

Є два способи обійти цю проблему, якщо ви бачите її у своєму кластері:

• Оновлення etcd може бути пропущено між пошкодженими версіями та v1.28.3 (або пізніше) за допомогою:

  kubeadm upgrade {apply|node} [version] --etcd-upgrade=false
  

  Це не рекомендується у випадку, якщо пізніше патч-версії v1.28 вводять нову версію etcd.

• Перед оновленням виправте маніфест для статичного Pod etcd, щоб видалити стандартні проблемні атрибути:

  diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml
  index d807ccbe0aa..46b35f00e15 100644
  --- a/etc/kubernetes/manifests/etcd_defaults.yaml
  +++ b/etc/kubernetes/manifests/etcd_origin.yaml
  @@ -43,7 +43,6 @@ spec:
         scheme: HTTP
       initialDelaySeconds: 10
       periodSeconds: 10
  -      successThreshold: 1
       timeoutSeconds: 15
     name: etcd
     resources:
  @@ -59,26 +58,18 @@ spec:
         scheme: HTTP
       initialDelaySeconds: 10
       periodSeconds: 10
  -      successThreshold: 1
       timeoutSeconds: 15
  -    terminationMessagePath: /dev/termination-log
  -    terminationMessagePolicy: File
     volumeMounts:
     - mountPath: /var/lib/etcd
       name: etcd-data
     - mountPath: /etc/kubernetes/pki/etcd
       name: etcd-certs
  -  dnsPolicy: ClusterFirst
  -  enableServiceLinks: true
   hostNetwork: true
   priority: 2000001000
   priorityClassName: system-node-critical
  -  restartPolicy: Always
  -  schedulerName: default-scheduler
   securityContext:
     seccompProfile:
       type: RuntimeDefault
  -  terminationGracePeriodSeconds: 30
   volumes:
   - hostPath:
       path: /etc/kubernetes/pki/etcd
  

Більше інформації можна знайти в тікеті для цієї помилки.

2.1.3 - Створення кластера за допомогою 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.31.

Загальний стан функцій інструменту 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-

Додавання додаткових вузлів панелі управління

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

Додавання робочих вузлів

Робочі вузли — це місце, де запускаються ваші робочі навантаження.

Наступні сторінки показують, як додати Linux та Windows робочі вузли до кластеру за допомогою команди kubeadm join:

• Додавання Linux робочих вузлів
• Додавання Windows робочих вузлів

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

Щоб отримати доступ до кластера з іншого компʼютера (наприклад, з ноутбука), вам потрібно скопіювати файл 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.31
• kubernetesVersion повинна бути 1.31 або 1.30

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

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

Приклад:

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

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

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

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

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

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

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

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

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

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

Обмеження

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

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

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

• Регулярно робіть резервні копії etcd. Тека даних etcd, налаштована за допомогою kubeadm, розташована за адресою /var/lib/etcd на вузлі панелі управління.

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

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

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

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

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

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

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

Що далі

• Перевірте, що ваш кластер працює належним чином за допомогою Sonobuoy.
• Дивіться Оновлення кластерів за допомогою kubeadm для отримання деталей щодо оновлення кластеру з використанням kubeadm.
• Дізнайтесь про розширене використання kubeadm у довідковій документації кubeadm.
• Дізнайтеся більше про концепції Kubernetes тут та kubectl.
• Дивіться сторінку мережі кластера для отримання великого списку додаткових надбудов Pod network.
• Дивіться список надбудов для вивчення інших надбудов, включаючи інструменти для ведення логів, моніторингу, мережевої політики, візуалізації та управління вашим кластером Kubernetes.
• Налаштуйте спосіб обробки вашим кластером логів подій кластера та застосунків, які працюють у Pod. Дивіться Архітектура ведення логів для отримання огляду того, що включено в цей процес.

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

• Для ознайомлення з повідомленями про помилки відвідайте трекер проблем kubeadm на GitHub
• Для отримання підтримки відвідайте канал Slack #kubeadm
• Загальний канал розробки SIG Cluster Lifecycle на Slack: #sig-cluster-lifecycle
• Інформація про SIG Cluster Lifecycle
• Розсилка SIG Cluster Lifecycle: kubernetes-sig-cluster-lifecycle

2.1.4 - Налаштування компонентів за допомогою kubeadm API

Ця сторінка охоплює способи налаштування компонентів, які розгортаються за допомогою kubeadm. Для компонентів панелі управління можна використовувати прапорці у структурі ClusterConfiguration або патчі на рівні вузла. Для kubelet і kube-proxy ви можете використовувати KubeletConfiguration та KubeProxyConfiguration, відповідно.

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

Налаштовування панелі управління за допомогою прапорців у ClusterConfiguration

Обʼєкт конфігурації панелі управління kubeadm надає можливість користувачам перевизначати типові прапорці, що передаються компонентам панелі управління, таким як APIServer, ControllerManager, Scheduler та Etcd. Компоненти визначаються за допомогою наступних структур:

• apiServer
• controllerManager
• scheduler
• etcd

Ці структури містять спільне поле extraArgs, яке складається з пар name / value. Щоб перевизначити прапорець для компонента панелі управління:

1. Додайте відповідні extraArgs до вашої конфігурації.
2. Додайте прапорці до поля extraArgs.
3. Запустіть kubeadm init з --config <ВАШ КОНФІГ YAML>.

Прапорці APIServer

Докладну інформацію див. у довідковій документації для kube-apiserver.

Приклад використання:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
  extraArgs:
  - name: "enable-admission-plugins"
    value: "AlwaysPullImages,DefaultStorageClass"
  - name: "audit-log-path"
    value: "/home/johndoe/audit.log"

Прапорці ControllerManager

Докладну інформацію див. у довідковій документації для kube-controller-manager.

Приклад використання:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
  extraArgs:
  - name: "cluster-signing-key-file"
    value: "/home/johndoe/keys/ca.key"
  - name: "deployment-controller-sync-period"
    value: "50"

Прапорці планувальника

Докладну інформацію див. у довідковій документації для kube-scheduler.

Приклад використання:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
  extraArgs:
  - name: "config"
    value: "/etc/kubernetes/scheduler-config.yaml"
  extraVolumes:
    - name: schedulerconfig
      hostPath: /home/johndoe/schedconfig.yaml
      mountPath: /etc/kubernetes/scheduler-config.yaml
      readOnly: true
      pathType: "File"

Прапорці etcd

Докладну інформацію див. у документації сервера etcd.

Приклад використання:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
    - name: "election-timeout"
      value: 1000

Налаштування за допомогою патчів

Kubeadm дозволяє передавати теку з файлами патчів в InitConfiguration та JoinConfiguration на окремих вузлах. Ці патчі можна використовувати як останній крок налаштування перед записом конфігурації компонента на диск.

Ви можете передати цей файл в kubeadm init за допомогою --config <ВАШ КОНФІГ YAML>:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
patches:
  directory: /home/user/somedir

Ви можете передати цей файл в kubeadm join за допомогою --config <ВАШ КОНФІГ YAML>:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
patches:
  directory: /home/user/somedir

Тека має містити файли з назвами target[suffix][+patchtype].extension. Наприклад, kube-apiserver0+merge.yaml або просто etcd.json.

• target може бути одним із kube-apiserver, kube-controller-manager, kube-scheduler, etcd та kubeletconfiguration.
• suffix — це необовʼязковий рядок, який можна використовувати для визначення порядку застосування патчів за алфавітною послідовністю.
• patchtype може бути одним із strategic, merge або json і вони повинні відповідати форматам патчів, підтримуваним kubectl. Типово patchtype — strategic.
• extension повинен бути або json, або yaml.

Налаштування kubelet

Щоб налаштувати kubelet, ви можете додати KubeletConfiguration поруч із ClusterConfiguration або InitConfiguration, розділеними --- у тому самому файлі конфігурації. Цей файл потім можна передати до kubeadm init, і kubeadm застосує ту ж саму базову KubeletConfiguration для всіх вузлів у кластері.

Для застосування конфігурації, специфічної для екземпляра, понад базовою KubeletConfiguration, ви можете використовувати ціль патчу kubeletconfiguration.

Також ви можете використовувати прапорці kubelet як перевизначення, передаючи їх у поле nodeRegistration.kubeletExtraArgs, яке підтримується як InitConfiguration, так і JoinConfiguration. Деякі прапорці kubelet є застарілими, тому перевірте їх статус у довідковій документації kubelet, перш ніж їх використовувати.

Додаткові деталі дивіться в розділі Налаштування кожного kubelet у вашому кластері за допомогою kubeadm

Налаштування kube-proxy

Щоб налаштувати kube-proxy, ви можете передати KubeProxyConfiguration поруч з ClusterConfiguration або InitConfiguration до kubeadm init, розділені ---.

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

2.1.5 - Варіанти топології високої доступності (HA)

Ця сторінка пояснює два варіанти конфігурації топології ваших високо доступних (HA) кластерів Kubernetes.

Ви можете налаштувати стійкий кластер:

• З вузлами панелі управління, де вузли etcd розташовані разом із вузлами панелі управління.
• З зовнішніми вузлами etcd, де etcd працює на окремих вузлах від вузлів панелі управління.

Перед налаштуванням стійкого кластера слід ретельно розглянути переваги та недоліки кожної топології.

Топологія etcd зі спільним розміщенням

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

Кожен вузол панелі управління запускає екземпляр kube-apiserver, kube-scheduler та kube-controller-manager. kube-apiserver доступний для робочих вузлів за допомогою балансувальника навантаження.

Кожен вузол панелі управління створює локального члена etcd, і цей член etcd спілкується лише з kube-apiserver цього вузла. Те ж саме стосується локальних екземплярів kube-controller-manager та kube-scheduler.

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

Проте такий кластер має ризик втрати зʼєднання. Якщо один вузол вийде з ладу, втратиться як член etcd, так і екземпляр панелі управління, і резервні можливості будуть скомпрометовані. Цей ризик можна зменшити, додавши більше вузлів панелі управління.

Отже, слід запускати мінімум три вузли панелі управління зі стековим розміщенням для високодоступного кластера.

Це типова топологія в kubeadm. Локальний член etcd створюється автоматично на вузлах панелі управління при використанні kubeadm init та kubeadm join --control-plane.

Топологія зовнішнього розміщення etcd

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

Подібно до топології зі стековими etcd, кожен вузол панелі управління в топології зі зовнішньою etcd запускає екземпляр kube-apiserver, kube-scheduler та kube-controller-manager. І kube-apiserver доступний для робочих вузлів за допомогою балансувальника навантаження. Однак члени etcd працюють на окремих хостах, і кожен хост etcd спілкується з kube-apiserver кожного вузла панелі управління.

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

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

Що далі

• Встановлення високодоступного кластера з kubeadm

2.1.6 - Створення високодоступних кластерів за допомогою kubeadm

На цій сторінці пояснюється два різних підходи до налаштування високодоступного кластера Kubernetes з використанням інструменту kubeadm:

• Зі стековими вузлами панелі управління. Цей підхід вимагає менше інфраструктури. Члени etcd та вузли панелі управління розташовані разом.
• Зовнішній кластер etcd. Цей підхід вимагає більше інфраструктури. Вузли панелі управління та члени etcd розділені.

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

У випадку виникнення проблем з налаштуванням HA-кластера, будь ласка, повідомте про це в системі відстеження проблем kubeadm.

Також дивіться документацію з оновлення.

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

Передумови залежать від топології, яку ви обрали для панелі управління кластера:

• Стековий etcd
• Зовнішній etcd

Образи контейнерів

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

Інтерфейс командного рядка

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

Перші кроки для обох методів

Створення балансувальника навантаження для kube-apiserver

1. Створіть балансувальник навантаження kube-apiserver з імʼям, яке розпізнається DNS.

   • У хмарному середовищі ви повинні розмістити вузли панелі управління за TCP балансувальником навантаження, який виконує переспрямовування трафіку. Цей балансувальник розподіляє трафік до всіх справних вузлів панелі управління у своєму списку цілей. Перевірка доступності apiserver — це перевірка TCP порту, на якому слухає kube-apiserver (типове значення порту :6443).

   • Не рекомендується використовувати IP-адресу безпосередньо у хмарному середовищі.

   • Балансувальник навантаження повинен мати можливість взаємодіяти з усіма вузлами панелі управління на порті apiserver. Також він повинен дозволяти вхідний трафік на його порту прослуховування.

   • Переконайтеся, що адреса балансувальника завжди відповідає адресі ControlPlaneEndpoint kubeadm.

   • Прочитайте Параметри для програмного балансування навантаження для отримання додаткових відомостей.

2. Додайте перший вузол панелі управління до балансувальника та перевірте зʼєднання:

   nc -v <LOAD_BALANCER_IP> <PORT>
   

   Помилка "connection refused" є очікуваною, оскільки API-сервер ще не запущено. Проте тайм-аут означає, що балансувальник не може взаємодіяти з вузлом панелі управління. Якщо виникає тайм-аут, повторно налаштуйте балансувальник для взаємодії з вузлом панелі управління.

3. Додайте решту вузлів панелі управління до цільової групи балансувальника.

Панель управління та вузли etcd зі стековою архітектурою

Кроки для першого вузла панелі управління

1. Ініціалізуйте панель управління:

   sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
   

   • Ви можете використовувати прапорець --kubernetes-version, щоб встановити версію Kubernetes, яку слід використовувати. Рекомендується, щоб версії kubeadm, kubelet, kubectl та Kubernetes відповідали одна одній.

   • Прапорець --control-plane-endpoint повинен бути встановлений на адресу або DNS та порт балансувальника.

   • Прапорець --upload-certs використовується для завантаження сертифікатів, які слід використовувати на всіх екземплярах панелі управління. Якщо натомість ви віддаєте перевагу копіюванню сертифікатів між вузлами панелі управління вручну або за допомогою засобів автоматизації, видаліть цей прапорець та зверніться до розділу Розподіл сертифікатів вручну нижче.

   Примітка:

   Прапорці kubeadm init --config та --certificate-key не можна змішувати, тому якщо ви хочете використовувати конфігурацію kubeadm вам слід додати поле certificateKey у відповідні місця конфігурації (під InitConfiguration та JoinConfiguration: controlPlane).

   Примітка:

   Деякі мережеві втулки CNI вимагають додаткової конфігурації, наприклад вказівки IP для Podʼа в форматі CIDR, тоді як інші — ні. Див. документацію мережі CNI. Щоб додати CIDR Podʼу, скористайтесь прапорцем --pod-network-cidr, або якщо ви використовуєте файл конфігурації kubeadm встановіть поле podSubnet в обʼєкті networking конфігурації ClusterConfiguration.

   Вивід виглядатиме десь так:

   ...
   You can now join any number of control-plane node by running the following command on each as a root:
       kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
   
   Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
   As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
   
   Then you can join any number of worker nodes by running the following on each as root:
       kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
   

   • Скопіюйте цей вивід у текстовий файл. Ви будете потребувати його пізніше для приєднання вузлів панелі управління та робочих вузлів до кластера.

   • Коли використовується --upload-certs з kubeadm init, сертифікати основної панелі управління шифруються та завантажуються у kubeadm-certs Secret.

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

     sudo kubeadm init phase upload-certs --upload-certs
     

   • Ви також можете вказати власний --certificate-key під час init, який пізніше може бути використаний з join. Щоб згенерувати такий ключ, використовуйте наступну команду:

     kubeadm certs certificate-key
     

   Ключ сертифіката — це рядок, закодований у шістнадцятковій формі, який є ключем AES розміром 32 байти.

   Примітка:

   Секрет kubeadm-certs та ключ розшифрування діють впродовж двох годин.

   Увага:

   Як зазначено у виводі команди, ключ сертифіката надає доступ до чутливих даних кластера, тримайте його в таємниці!

2. Застосуйте обраний вами мережеву втулок CNI: Дотримуйтеся цих інструкцій для встановлення постачальника CNI. Переконайтеся, що конфігурація відповідає CIDR IP для Podʼа, вказаному в файлі конфігурації kubeadm (якщо застосовується).

   Примітка:

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

3. Введіть наступну команду та спостерігайте, як запускаються екземпляри компонентів панелі управління:

   kubectl get pod -n kube-system -w
   

Кроки для інших вузлів панелі управління

Для кожного додаткового вузла панелі управління:

1. Виконайте команду приєднання, яка вам була надана раніше виводом kubeadm init на першому вузлі. Вона повинна виглядати приблизно так:

   sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
   

   • Прапорець --control-plane повідомляє kubeadm join створити новий вузол панелі управління.
   • Прапорець --certificate-key ... призведе до того, що сертифікати вузлів панелі управління будуть завантажені з секрету kubeadm-certs в кластері та розшифровані за допомогою вказаного ключа.

Ви можете приєднувати кілька вузлів панелі управління паралельно.

Зовнішні вузли etcd

Налаштування кластера з зовнішніми вузлами etcd подібно до процедури, використовуваної для стекових вузлів etcd, з винятком того, що ви повинні налаштувати etcd спочатку, і ви повинні передавати інформацію про etcd у конфігураційному файлі kubeadm.

Налаштуйте кластер etcd

1. Слідуйте цим інструкціям для налаштування кластера etcd.

2. Налаштуйте SSH, як описано тут.

3. Скопіюйте наступні файли з будь-якого вузла etcd в кластері на перший вузол панелі управління:

   export CONTROL_PLANE="ubuntu@10.0.0.7"
   scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
   

   • Замініть значення CONTROL_PLANE на user@host першого вузла панелі управління.

Налаштуйте перший вузол панелі управління

1. Створіть файл із назвою kubeadm-config.yaml із наступним змістом:

   ---
   apiVersion: kubeadm.k8s.io/v1beta4
   kind: ClusterConfiguration
   kubernetesVersion: stable
   controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # змініть це (див. нижче)
   etcd:
     external:
       endpoints:
         - https://ETCD_0_IP:2379 # змініть ETCD_0_IP відповідно
         - https://ETCD_1_IP:2379 # змініть ETCD_1_IP відповідно
         - https://ETCD_2_IP:2379 # змініть ETCD_2_IP відповідно
       caFile: /etc/kubernetes/pki/etcd/ca.crt
       certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
       keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
   

   Примітка:

   Різниця між stacked etcd та external etcd полягає в тому, що налаштування external etcd потребує конфігураційного файлу з endpointʼами etcd в обʼєкті external для etcd. У випадку топології stacked etcd це вирішується автоматично.

   • Замініть наступні змінні в шаблоні конфігурації на відповідні значення для вашого кластера:

     • LOAD_BALANCER_DNS
     • LOAD_BALANCER_PORT
     • ETCD_0_IP
     • ETCD_1_IP
     • ETCD_2_IP

Наступні кроки схожі на налаштування stacked etcd:

1. Виконайте команду sudo kubeadm init --config kubeadm-config.yaml --upload-certs на цьому вузлі.

2. Запишіть вихідні команди для приєднання, які повертаються, у текстовий файл для подальшого використання.

3. Застосуйте обраний вами втулок CNI.

   Примітка:

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

Кроки для інших вузлів панелі управління

Кроки аналогічні налаштуванню для stacked etcd:

• Переконайтеся, що перший вузол панелі управління повністю ініціалізований.
• Приєднайте кожен вузол панелі управління за допомогою команди приєднання, яку ви зберегли в текстовий файл. Рекомендується приєднувати вузли панелі управління по одному.
• Не забудьте, що ключ розшифрування з параметром --certificate-key діє дві години.

Загальні завдання після налаштування панелі управління

Встановлення робочих вузлів

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

sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

Ручне поширення сертифікатів

Якщо ви вирішили не використовувати kubeadm init з параметром --upload-certs, це означає, що вам доведеться вручну скопіювати сертифікати з первинного вузла панелі управління до приєднуваних вузлів панелі.

Є багато способів це зробити. У наступному прикладі використовуються ssh та scp:

SSH потрібен, якщо ви хочете керувати всіма вузлами з одного пристрою.

1. Активуйте ssh-agent на своєму основному пристрої, який має доступ до всіх інших вузлів в системі:

   eval $(ssh-agent)
   

2. Додайте свій SSH-ідентифікатор до сеансу:

   ssh-add ~/.ssh/path_to_private_key
   

3. Перемикайтесь між вузлами, щоб перевірити, чи зʼєднання правильно працює.

   • Коли ви входите в будь-який вузол через SSH, додайте прапорець -A. Цей прапорець дозволяє вузлу, на який ви увійшли за допомогою SSH, отримувати доступ до агента SSH на вашому ПК. Розгляньте альтернативні методи, якщо ви не повністю довіряєте безпеці вашої сесії користувача на вузлі.

     ssh -A 10.0.0.7
     

   • Коли використовуєте sudo на будь-якому вузлі, обовʼязково зберігайте середовище, щоб SSH forwarding працював:

     sudo -E -s
     

4. Після налаштування SSH на всіх вузлах ви повинні запустити наступний скрипт на першому вузлі панелі управління після запуску kubeadm init. Цей скрипт скопіює сертифікати з першого вузла панелі управління на інші вузли панелі:

   У наступному прикладі замініть CONTROL_PLANE_IPS на IP-адреси інших вузлів панелі управління.

   USER=ubuntu # налаштовується
   CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
   for host in ${CONTROL_PLANE_IPS}; do
       scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
       # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd
       scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
   done
   

   Увага:

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

5. Потім на кожному приєднуваному вузлі панелі управління вам слід виконати наступний скрипт перед виконанням kubeadm join. Цей скрипт перемістить раніше скопійовані сертифікати з домашньої теки в /etc/kubernetes/pki:

   USER=ubuntu # налаштовується
   mkdir -p /etc/kubernetes/pki/etcd
   mv /home/${USER}/ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/ca.key /etc/kubernetes/pki/
   mv /home/${USER}/sa.pub /etc/kubernetes/pki/
   mv /home/${USER}/sa.key /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
   mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
   # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd
   mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
   

2.1.7 - Налаштування високодоступного кластера etcd за допомогою kubeadm

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

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

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

• Три хости, які можуть взаємодіяти між собою через TCP-порти 2379 та 2380. Цей документ вважає, що це стандартні порти. Однак їх можна налаштувати через файл конфігурації kubeadm.
• На кожному хості повинен бути встановлений systemd та сумісна з bash оболонка.
• На кожному хості повинно бути встановлене середовище виконання контейнерів, kubelet та kubeadm.
• Кожен хост повинен мати доступ до реєстру образів контейнерів Kubernetes (registry.k8s.io) або ви можете отримати перелік та/або витягти необхідний образ etcd, використовуючи kubeadm config images list/pull. У цьому посібнику екземпляри etcd налаштовані як статичні Podʼи, керовані kubelet.
• Є якась інфраструктура для копіювання файлів між хостами. Наприклад, ssh та scp можуть відповідати цьому вимогу.

Налаштування кластера

Загальний підхід — генерувати всі сертифікати на одному вузлі та розповсюджувати лише необхідні файли на інші вузли.

1. Налаштуйте kubelet як менеджер служб для etcd.

   Примітка:

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

   cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
   # Замініть "systemd" на драйвер cgroup вашого середовища виконання контейнерів. Стандартне значення в kubelet - "cgroupfs".
   # Замініть значення "containerRuntimeEndpoint" на інше середовище виконання контейнерів за потреби.
   #
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   authentication:
     anonymous:
       enabled: false
     webhook:
       enabled: false
   authorization:
     mode: AlwaysAllow
   cgroupDriver: systemd
   address: 127.0.0.1
   containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
   staticPodPath: /etc/kubernetes/manifests
   EOF
   
   cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
   [Service]
   ExecStart=
   ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
   Restart=always
   EOF
   
   systemctl daemon-reload
   systemctl restart kubelet
   

   Перевірте статус kubelet, щоб переконатися, що він працює.

   systemctl status kubelet
   

2. Створіть конфігураційні файли для kubeadm.

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

   # Оновіть HOST0, HOST1 та HOST2 IP ваших хостів
   export HOST0=10.0.0.6
   export HOST1=10.0.0.7
   export HOST2=10.0.0.8
   
   # Оновіть NAME0, NAME1 та NAME2 іменами хостів
   export NAME0="infra0"
   export NAME1="infra1"
   export NAME2="infra2"
   
   # Створіть тимчасові теки для зберігання файлів, які потраплять на інші хости
   mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
   
   HOSTS=(${HOST0} ${HOST1} ${HOST2})
   NAMES=(${NAME0} ${NAME1} ${NAME2})
   
   for i in "${!HOSTS[@]}"; do
   HOST=${HOSTS[$i]}
   NAME=${NAMES[$i]}
   cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: InitConfiguration
   nodeRegistration:
       name: ${NAME}
   localAPIEndpoint:
       advertiseAddress: ${HOST}
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: ClusterConfiguration
   etcd:
       local:
           serverCertSANs:
           - "${HOST}"
           peerCertSANs:
           - "${HOST}"
           extraArgs:
           - name: initial-cluster
             value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
           - name: initial-cluster-state
             value: new
           - name: name
             value: ${NAME}
           - name: listen-peer-urls
             value: https://${HOST}:2380
           - name: listen-client-urls
             value: https://${HOST}:2379
           - name: advertise-client-urls
             value: https://${HOST}:2379
           - name: initial-advertise-peer-urls
             value: https://${HOST}:2380
   EOF
   done
   

3. Згенеруйте центр сертифікації.

   Якщо у вас вже є ЦС, то єдине що треба зробити — скопіювати файли crt та key ЦС у /etc/kubernetes/pki/etcd/ca.crt та /etc/kubernetes/pki/etcd/ca.key. Після копіювання цих файлів перейдіть до наступного кроку — "Створення сертифікатів для кожного учасника".

   Якщо у вас ще немає ЦС, то виконайте цю команду на $HOST0 (де ви згенерували файли конфігурації для kubeadm).

   kubeadm init phase certs etcd-ca
   

   Це створює два файли:

   • /etc/kubernetes/pki/etcd/ca.crt
   • /etc/kubernetes/pki/etcd/ca.key

4. Створення сертифікатів для кожного учасника.

   kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST2}/
   # очистити одноразові сертифікати
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST1}/
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   # Немає потреби переміщувати сертифікати, оскільки вони призначені для HOST0
   
   # приберемо сертифікати, які не повинні бути скопійовані з цього хоста
   find /tmp/${HOST2} -name ca.key -type f -delete
   find /tmp/${HOST1} -name ca.key -type f -delete
   

5. Скопіюйте сертифікати та конфігурації kubeadm.

   Сертифікати вже були згенеровані, і тепер їх потрібно перемістити на відповідні хости.

   USER=ubuntu
   HOST=${HOST1}
   scp -r /tmp/${HOST}/* ${USER}@${HOST}:
   ssh ${USER}@${HOST}
   USER@HOST $ sudo -Es
   root@HOST $ chown -R root:root pki
   root@HOST $ mv pki /etc/kubernetes/
   

6. Переконайтеся, що всі очікувані файли існують.

   Повний перелік обовʼязкових файлів на $HOST0:

   /tmp/${HOST0}
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── ca.key
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   На $HOST1:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   На $HOST2:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

7. Створіть маніфести статичних Podʼів.

   Тепер, коли сертифікати та конфігурації на місці, прийшов час створити маніфести для etcd. На кожному хості виконайте команду kubeadm для генерації статичного маніфесту для etcd.

   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
   root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   

8. Опціонально: Перевірте стан кластера.

   Якщо etcdctl недоступний, ви можете запустити цей інструмент в середовищі контейнера. Ви можете це зробити безпосередньо з вашим середовищем виконання контейнерів за допомогою такого інструменту, як crictl run, а не через Kubernetes

   ETCDCTL_API=3 etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://${HOST0}:2379 endpoint health
   ...
   https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
   https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
   https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
   

   • Встановіть ${HOST0}на IP-адресу хосту, який ви тестуєте.

Що далі

Коли у вас є кластер etcd з 3 робочими учасниками, ви можете продовжити налаштування високодоступного вузла панелі управління, використовуючи метод зовнішнього etcd з kubeadm.

2.1.8 - Налаштування кожного kubelet у кластері за допомогою kubeadm

Життєвий цикл інструменту командного рядка kubeadm не повʼязаний з kubelet, який є службою, що працює на кожному вузлі в кластері Kubernetes. Інструмент командного рядка kubeadm запускається користувачем під час ініціалізації або оновлення Kubernetes, тоді як kubelet завжди працює в фоновому режимі.

Оскільки kubelet — це демон, його потрібно обслуговувати за допомогою якоїсь системи ініціалізації або менеджера служб. Коли kubelet встановлено за допомогою DEB або RPM-пакунків, systemd налаштовується для управління kubelet. Ви можете використовувати інший менеджер служб, але його потрібно налаштувати вручну.

Деякі деталі конфігурації kubelet повинні бути однакові для всіх kubelet, які беруть участь в кластері, тоді як інші аспекти конфігурації повинні бути встановлені для кожного kubelet окремо, щоб врахувати різні характеристики кожної машини (такі як ОС, сховище та мережа). Ви можете керувати конфігурацією kubelet вручну, але тепер kubeadm надає API-тип KubeletConfiguration дляцентралізованого управління конфігураціями kubelet.

Шаблони конфігурації kubelet

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

Поширення конфігурації на рівні кластера для кожного kubelet

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

Якщо ви хочете, щоб ваші служби використовували мережу 10.96.0.0/12, ви можете передати параметр --service-cidr в kubeadm:

kubeadm init --service-cidr 10.96.0.0/12

Віртуальні IP-адреси для служб тепер виділяються з цієї підмережі. Вам також потрібно встановити адресу DNS, яку використовує kubelet, за допомогою прапорця --cluster-dns. Це налаштування мають бути однаковим для кожного kubelet на кожному вузлі управління та вузлі в кластері. Kubelet надає структурований, версійований обʼєкт API, який може налаштовувати більшість параметрів в kubelet та розсилати цю конфігурацію кожному працюючому kubelet в кластері. Цей обʼєкт називається KubeletConfiguration. KubeletConfiguration дозволяє користувачу вказувати прапорці, такі як IP-адреси DNS кластера, у вигляді списку значень для camelCased ключа, як показано в наступному прикладі:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

Докладніше про KubeletConfiguration можна знайти у цьому розділі.

Надання конфігурації, специфічної для екземпляра

Деякі хости вимагають специфічних конфігурацій kubelet через різницю в апаратному забезпеченні, операційній системі, мережевій конфігурації чи інших параметрах, специфічних для хосту. У наступному переліку наведено кілька прикладів.

• Шлях до файлу розвʼязання DNS, як вказано прапорцем конфігурації kubelet --resolv-conf, може відрізнятися залежно від операційної системи або від того, чи використовується systemd-resolved. Якщо цей шлях вказано неправильно, розвʼязування DNS буде невдалим на вузлі, конфігурація kubelet якого налаштована неправильно.

• Обʼєкт API вузла .metadata.name типово вказує імʼя хосту машини, якщо ви не використовуєте хмарного постачальника. Ви можете використовувати прапорець --hostname-override, щоб змінити типову поведінку, якщо вам потрібно вказати імʼя вузла, відмінне від імені хосту машини.

• Зараз kubelet не може автоматично виявити драйвер cgroup, який використовується середовищем виконання контейнерів, але значення --cgroup-driver повинно відповідати драйверу cgroup, який використовується середовищем виконання контейнерів, щоб забезпечити нормальну роботу kubelet.

• Щоб вказати середовище виконання контейнерів, вам потрібно встановити його endpoint за допомогою прапорця --container-runtime-endpoint=<шлях>.

Рекомендований спосіб застосування такої конфігурації, специфічної для екземпляра, — використовувати патчі для KubeletConfiguration.

Налаштування kubelet за допомогою kubeadm

Можливо налаштувати kubelet, який запустить kubeadm, якщо вказано власний обʼєкт API KubeletConfiguration з конфігураційним файлом таким чином kubeadm ... --config some-config-file.yaml.

Викликаючи kubeadm config print init-defaults --component-configs KubeletConfiguration, ви можете переглянути всі типові значення для цієї структури.

Також можливо застосувати специфічні для екземпляра патчі до базового KubeletConfiguration. Див. Налаштування kubelet для отримання докладнішої інформації.

Послідовність дій при використанні kubeadm init

Коли ви викликаєте kubeadm init, конфігурація kubelet записується на диск в /var/lib/kubelet/config.yaml і також завантажується в ConfigMap kubelet-config в просторі імен kube-system кластера. Файл конфігурації kubelet також записується у /etc/kubernetes/kubelet.conf із базовою конфігурацією кластера для всіх kubelet в кластері. Цей файл конфігурації вказує на клієнтські сертифікати, які дозволяють kubelet взаємодіяти з сервером API. Це вирішує необхідність поширення конфігурації на рівні кластера для кожного kubelet.

Щоб вирішити другий шаблон надання конфігурації, специфічної для екземпляра, kubeadm записує файл середовища у /var/lib/kubelet/kubeadm-flags.env, який містить список прапорців, які слід передати kubelet при запуску. Прапорці виглядають у файлі наступним чином:

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

Крім прапорців, використовуваних при запуску kubelet, файл також містить динамічні параметри, такі як драйвер cgroup та використання іншого сокету контейнерного середовища (--cri-socket).

Після того як ці два файли конвертуються на диск, kubeadm намагається виконати дві команди, якщо ви використовуєте systemd:

systemctl daemon-reload && systemctl restart kubelet

Якщо перезавантаження та перезапуск вдалися, продовжується звичайний робочий процес kubeadm init.

Послідовність при використанні kubeadm join

Коли ви викликаєте kubeadm join, kubeadm використовує облікові дані Bootstrap Token, щоб виконати запуск TLS, який отримує необхідні облікові дані для завантаження kubelet-config ConfigMap та записує його в /var/lib/kubelet/config.yaml. Файл середовища генерується точно так само, як і при kubeadm init.

Далі kubeadm виконує дві команди для завантаження нової конфігурації в kubelet:

systemctl daemon-reload && systemctl restart kubelet

Після завантаження нової конфігурації kubelet, kubeadm записує /etc/kubernetes/bootstrap-kubelet.conf файл конфігурації KubeConfig, який містить сертифікат CA та Bootstrap Token. Ці дані використовуються kubelet для виконання TLS Bootstrap та отримання унікальних облікових даних, які зберігається в /etc/kubernetes/kubelet.conf.

Коли файл /etc/kubernetes/kubelet.conf записаний, kubelet завершує виконання TLS Bootstrap. Kubeadm видаляє файл /etc/kubernetes/bootstrap-kubelet.conf після завершення TLS Bootstrap.

Файл kubelet drop-in для systemd

kubeadm постачається з конфігурацією systemd для запуску kubelet. Зверніть увагу, що команда kubeadm CLI ніколи не торкається цього drop-in файлу.

Цей файл конфігурації, встановлений за допомогою пакунку kubeadm, записується в /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf та використовується systemd. Він доповнює основний kubelet.service.

Якщо ви хочете внести зміні, ви можете створити теку /etc/systemd/system/kubelet.service.d/ (зверніть увагу, не /usr/lib/systemd/system/kubelet.service.d/) та внести власні налаштування у файл там. Наприклад, ви можете додати новий локальний файл /etc/systemd/system/kubelet.service.d/local-overrides.conf для того, щоб перевизначити налаштування елементів в kubeadm.

Ось що ви, імовірно, знайдете в /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf:

[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# Це файл, який "kubeadm init" та "kubeadm join" генерують в режимі виконання, заповнюючи
# змінну KUBELET_KUBEADM_ARGS динамічно
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# Це файл, який користувач може використовувати для заміщення аргументів kubelet як останній захист. В ідеалі,
# користувач повинен використовувати обʼєкт .NodeRegistration.KubeletExtraArgs в файлах конфігурації.
# KUBELET_EXTRA_ARGS повинен бути джерелом цього файлу.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

Цей файл вказує на типове знаходження для всіх файлів, які керуються kubeadm для kubelet.

• Файл KubeConfig для TLS Bootstrap — /etc/kubernetes/bootstrap-kubelet.conf, але він використовується тільки у випадку, якщо /etc/kubernetes/kubelet.conf не існує.
• Файл KubeConfig з унікальними ідентифікаційними даними kubelet — /etc/kubernetes/kubelet.conf.
• Файл, що містить ComponentConfig kubelet — /var/lib/kubelet/config.yaml.
• Динамічний файл середовища, що містить KUBELET_KUBEADM_ARGS, взятий з /var/lib/kubelet/kubeadm-flags.env.
• Файл, що може містити перевизначення прапорців, вказаних користувачем за допомогою KUBELET_EXTRA_ARGS, береться з /etc/default/kubelet (для DEB) або /etc/sysconfig/kubelet (для RPM). KUBELET_EXTRA_ARGS останній в ланцюжку прапорців та має найвищий пріоритет у випадку конфлікту налаштувань.

Бінарні файли Kubernetes та вміст пакунків

DEB та RPM-пакети, які постачаються з випусками Kubernetes:

2.1.9 - Підтримка подвійного стека за допомогою kubeadm

Ваш кластер Kubernetes має мережу з підтримкою подвійного стека, що означає, що у кластері мережева взаємодія може використовувати обидві адресні родини. У кластері панель управління може призначити як IPv4-адреси, так і IPv6-адреси Podʼу чи Service.

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

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

Для кожного сервера, який ви хочете використовувати як вузол, переконайтеся, що на ньому увімкнено переспрямовування IPv6 трафіку (IPv6 forwarding). На Linux це можна зробити, виконавши sysctl -w net.ipv6.conf.all.forwarding=1 з правами користувача root на кожному сервері.

Вам потрібні діапазони адрес IPv4 та IPv6. Оператори кластера, як правило, використовують приватні діапазони адрес для IPv4. Щодо IPv6, оператор кластера, як правило, обирає глобальний унікальний блок адрес з області 2000::/3, використовуючи діапазон, який виділений оператору. Вам не потрібно робити маршрутизацію IP-діапазонів кластера в Інтернет.

Розмір діапазону IP-адрес повинен бути достатнім для тієї кількості Podʼів та Serviceʼів, які ви плануєте запускати.

Створення кластера з подвійним стеком

Для створення кластера з подвійним стеком за допомогою kubeadm init ви можете передати аргументи командного рядка аналогічно наступному прикладу:

# Це діапазони адрес для прикладу
kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112

Щоб зробити це більш зрозумілим, ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для основного вузла панелі управління з подвійним стеком.

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16,2001:db8:42:0::/56
  serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::2"

advertiseAddress в InitConfiguration вказує IP-адресу, яку API Server оголошує як адресу, на якій він очікує трафік. Значення advertiseAddress дорівнює значенню прапорця --apiserver-advertise-address команди kubeadm init.

Використовуйте kubeadm для ініціалізації панелі управління на вузлі з подвійним стеком:

kubeadm init --config=kubeadm-config.yaml

Прапори kube-controller-manager --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 встановлені у стандартні значення. Див. налаштування подвійного стека IPv4/IPv6.

Приєднання вузла до кластера з подвійним стеком

Перш ніж приєднати вузол, переконайтеся, що вузол має мережевий інтерфейс з можливістю маршрутизації IPv6 та дозволяє пересилання IPv6.

Ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для приєднання робочого вузла до кластера.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::3"

Також ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для приєднання іншого вузла панелі управління до кластера.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
controlPlane:
  localAPIEndpoint:
    advertiseAddress: "10.100.0.2"
    bindPort: 6443
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::4"

advertiseAddress в JoinConfiguration.controlPlane вказує IP-адресу, яку API Server оголошує як адресу, на якій він слухає. Значення advertiseAddress дорівнює прапорцю --apiserver-advertise-address команди kubeadm join.

kubeadm join --config=kubeadm-config.yaml

Створення кластера з одним стеком

Щоб зробити речі більш зрозумілими, конфігураційного файлу kubeadm kubeadm-config.yaml для панелі управління з одним стеком.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/16

Що далі

• Перевірка мережевої взаємодії в подвійному стеку IPv4/IPv6
• Дізнайтеся більше про підтримку подвійного стека
• Дізнайтеся більше про формат конфігурації kubeadm

3 - Хмарні рішення під ключ

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