Перейти к содержанию

Этап 5: Присоединение control plane нод

Выполнять на k8scontrolplane02 и k8scontrolplane03

Все шаги этого этапа — только на второй и третьей control plane нодах.

5.1. Создание kube-vip манифеста

ВАЖНО: Делаем это ПЕРЕД kubeadm join на каждой ноде!

На k8scontrolplane02 (и потом на k8scontrolplane03):

export VIP=192.168.139.101
export INTERFACE=eth0

sudo mkdir -p /etc/kubernetes/manifests

# Генерируем манифест kube-vip
sudo ctr image pull ghcr.io/kube-vip/kube-vip:v1.0.4

# При join используем сразу admin.conf (он будет создан при join)
sudo ctr run --rm --net-host ghcr.io/kube-vip/kube-vip:v1.0.4 vip /kube-vip manifest pod \
  --interface $INTERFACE \
  --address $VIP \
  --controlplane \
  --services \
  --arp \
  --leaderElection \
  --k8sConfigPath /etc/kubernetes/admin.conf | sudo tee /etc/kubernetes/manifests/kube-vip.yaml

Почему admin.conf, а не super-admin.conf (как при init):

Разница в последовательности создания файлов

При kubeadm init (первая нода):

  1. Создается super-admin.conf (самым первым)
  2. kube-vip static pod пытается запуститься
  3. Только потом создается admin.conf
  4. ❌ Если kube-vip указывает на admin.conf - файла еще нет, pod падает
  5. ✅ Поэтому используем super-admin.conf (он уже есть), потом переключаем

При kubeadm join (дополнительные ноды):

  1. Join скачивает сертификаты из кластера
  2. Создает /etc/kubernetes/admin.conf и другие kubeconfig
  3. Генерирует static pod манифесты
  4. Только ПОСЛЕ этого kubelet запускает static pods (включая kube-vip)
  5. ✅ К моменту запуска kube-vip файл admin.conf уже существует
  6. ✅ Можем сразу использовать admin.conf, переключение не требуется

Важно: super-admin.conf создается ТОЛЬКО на ноде где был kubeadm init. На ноды при join он не копируется.

Почему это важно

  • kube-vip должен быть на всех control plane нодах для failover VIP
  • Манифест создается ДО join чтобы pod запустился автоматически после join
  • Правильный kubeconfig path избавляет от лишнего шага переключения

5.2. Join к кластеру

Используйте команду для control plane нод, которую вы получили и сохранили на Этапе 4.1 («Создание join команд»).

# Пример (используйте СВОЮ команду с актуальным токеном и certificate-key):
sudo kubeadm join kube-api.orb.local:6443 --token <TOKEN> \
--discovery-token-ca-cert-hash sha256:<HASH> \
--control-plane --certificate-key <CERT_KEY>

Что происходит при join

  1. Preflight checks
  2. Скачивание cluster-info из kube-public
  3. Скачивание сертификатов из Secret (используя certificate-key)
  4. Копирование сертификатов в /etc/kubernetes/pki
  5. Генерация kubeconfig файлов
  6. Создание static pod манифестов
  7. Добавление ноды в etcd кластер как learner
  8. Повышение до voting member
  9. Запуск control plane компонентов

Процесс займет 2-5 минут. В конце вы увидите:

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

To start administering your cluster from this node, 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

Run 'kubectl get nodes' to see this node join the cluster.

5.3. Настройка kubectl

На только что присоединенной ноде:

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

# Проверяем
kubectl get nodes

5.4. Проверка etcd кластера

На любой control plane ноде:

После добавления k8scontrolplane02:

# Health check всех членов etcd
sudo etcdctl \
  --endpoints=https://192.168.139.105:2379,https://192.168.139.152:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health --cluster -w table

# Должно показать 2 healthy endpoints

После добавления k8scontrolplane03:

# Health check всех членов etcd
sudo etcdctl \
  --endpoints=https://192.168.139.105:2379,https://192.168.139.152:2379,https://192.168.139.188:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health --cluster -w table

# Должно показать 3 healthy endpoints

Member list:

sudo etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list -w table

# Должно показать 3 члена со статусом "started"