Налаштування кожного 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: