Створення високодоступних кластерів за допомогою 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 -zv -w 2 <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 потребує конфігураційного файлу з точками доступу 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