From 242f6ca5fb4dcbaef31bcf32674224d8c397e470 Mon Sep 17 00:00:00 2001 From: erjemin Date: Thu, 27 Feb 2025 14:54:59 +0300 Subject: [PATCH] =?UTF-8?q?add:=20k3s=20(=D1=83=D0=B4=D0=B0=D0=BB=D1=8F?= =?UTF-8?q?=D0=B5=D0=BC=20=D0=B2=D0=BE=D1=80=D0=BA=D0=B5=D1=80-=D1=83?= =?UTF-8?q?=D0=B7=D0=B5=D0=BB=20=E2=84=963=20=D0=B8=20=D0=B4=D0=BE=D0=B1?= =?UTF-8?q?=D0=B0=D0=B2=D0=B8=D0=BC=20=D0=B5=D0=B3=D0=BE=20=D0=BA=D0=B0?= =?UTF-8?q?=D0=BA=20=D0=BC=D0=B0=D1=81=D1=82=D0=B5=D1=80)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- raspberry-and-orange-pi/k3s.md | 103 ++++++++++++++++++++++++++++++++- 1 file changed, 101 insertions(+), 2 deletions(-) diff --git a/raspberry-and-orange-pi/k3s.md b/raspberry-and-orange-pi/k3s.md index d7f12cd..1a10ebc 100644 --- a/raspberry-and-orange-pi/k3s.md +++ b/raspberry-and-orange-pi/k3s.md @@ -158,6 +158,7 @@ Unauthorized JSON-ответ от API. Что-то вроде: ## Подключение второго узла (мастер) + Для начала, на первой ноде получим токен для подключения нового узла к кластеру: ```bash sudo cat /var/lib/rancher/k3s/server/node-token @@ -241,7 +242,7 @@ opi5plus-3 Ready control-plane,etcd,master 2h v1.31.5+k3s1 Посмотрим на поды: ```bash -opi@opi5plus-2:~$ sudo k3s kubectl get pods -n kube-system -o wide +sudo k3s kubectl get pods -n kube-system -o wide ``` И увидим, что на новом воркере (opi5plus-1) запустился под балансировщика `svclb-traefik`: @@ -275,4 +276,102 @@ traefik LoadBalancer 10.43.164.48 192.168.1.26,192.168.1.27,192.16 и увидим, что балаансировщик работает и перенаправляет трафик и с ноды воркера. Что ж, теперь у нас есть кластер k3s с тремя нодами: двумя мастерами и одним воркером. Но, как я уже говорил, это не -идеальная конфигурация, так как у нас четное количество мастер-узлов. \ No newline at end of file +идеальная конфигурация, так как у нас четное количество мастер-узлов. + +Попробует отключить один из мастеров (не обязательно выключать питание, достаточно отсоединить сетевой кабель ethernet) +и посмотрим что произойдет. + +Само-собой доступ к панели Traefik на "погашенном узле" пропадет, но с обоих работающих узлов (живого мастера +и воркера) сохранится. И еще будет потеряна возможность работать с кластером через `kubectl`. Почему kubectl +не работает на втором мастере? Ошибка на втором мастере после отключения первого говорит о том, что кластер потерял +полную функциональность API-сервера. Как говорилось ранее, k3s с настройкой HA (высокая доступность) используется +встроенный etcd для хранения состояния. Для работы etcd в HA-режиме требуется кворум. + +Кворум в etcd — это минимальное количество узлов, которые должны быть доступны для согласования данных и принятия +решений в кластере. Это основа отказоустойчивости распределённой системы. При двух мастерах: **Кворум = N/2 + 1**, +где N — количество мастер-узлов. Для 2 узлов: *кворум = 2/2 + 1 = 2*. Это значит, что оба мастера должны быть живы, +чтобы etcd работал. Если один мастер падает, второй не может достичь кворума (1 < 2) и останавливает работу etcd. +Без etcd API-сервер на втором мастере не может отвечать на запросы kubectl, хотя поды продолжают работать, так как +им не нужен доступ к etcd в реальном времени. + +В чем может быть смысл иметь два мастера? Это обеспечивает репликацию данных (второй хранит копию etcd), но не +даёт отказоустойчивости -- когда один мастер упал, кластер становится неуправляемым (нет управления через kubectl), +рабочие нагрузки (поды) могут продолжать работать, пока жив хотя бы один узел, но новые изменения (развертывание +подов и обновления) невозможны. + +Таким образом, два мастера это не идеальная HA (High Availability), а скорее "полу-HA". Полная HA начинается +с трёх узлов! Три мастера — это стандарт для настоящей отказоустойчивости в Kubernetes (и k3s). При трёх мастерах: +**Кворум = 3/2 + 1 = 2**. Это значит, что кластер остаётся рабочим, если один мастер уме, но живы минимум 2 из 3. +Два оставшихся поддерживают кворум (2 >= 2), и кластер полностью управляем (kubectl работает и можно деплоить поды). + +### Удаление узла из кластера + +Чтобы снова получить возможность управлять кластером включим погашенный мастер-узел, подождем пока кворум восстановится +и удалим с k3s воркер-узел (opi5plus-1): +```bash +sudo /usr/local/bin/k3s-agent-uninstall.sh +``` + +Теперь состояние узлов в кластере: +```text +NAME STATUS ROLES AGE VERSION +opi5plus-1 NotReady 147m v1.31.5+k3s1 +opi5plus-2 Ready control-plane,etcd,master 3d2h v1.31.5+k3s1 +opi5plus-3 Ready control-plane,etcd,master 2d v1.31.5+k3s1 +``` + +Нода со статусом `NotReady` с ролью `` — это остатки бывшего воркера. Если запустить на том же хосте масте, узел +может "ожить" и перерегистрироваться с новыми ролями. Но это не обязательно удалит старый объект Node — он может +либо обновиться (если имя совпадает), либо создать дубликат, что приведёт к путанице. Надежнее удалить старый узел из +кластера: +```bash +sudo k3s kubectl delete node opi5plus-1 +``` + +Теперь состояние узлов: +```text +NAME STATUS ROLES AGE VERSION +opi5plus-2 Ready control-plane,etcd,master 3d2h v1.31.5+k3s1 +opi5plus-3 Ready control-plane,etcd,master 2d v1.31.5+k3s1 +``` + +После удаления узла, проверим состояние подов кластера (правильнее, конечно, было бы проверить поды до удаления узла, +но, допустим, мы имитировали ситуацию "смерти" узла): +```bash +sudo k3s kubectl get pods -n kube-system -o wide +``` + +Увидим: +```text +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +coredns-ccb96694c-tfjwj 1/1 Running 0 4d19h 10.42.0.4 opi5plus-2 +helm-install-traefik-crd-bdbgd 0/1 Completed 0 4d19h opi5plus-2 +helm-install-traefik-mlztm 0/1 Completed 1 4d19h opi5plus-2 +local-path-provisioner-5cf85fd84d-jwz5n 1/1 Running 0 4d19h 10.42.0.3 opi5plus-2 +metrics-server-5985cbc9d7-n9dwz 1/1 Running 0 4d19h 10.42.0.2 opi5plus-2 +svclb-traefik-4f8c2580-h7b9c 3/3 Running 0 2d18h 10.42.0.9 opi5plus-2 +svclb-traefik-4f8c2580-nhz65 3/3 Running 0 38h 10.42.2.2 opi5plus-1 +svclb-traefik-4f8c2580-qmzf6 3/3 Running 0 2d18h 10.42.1.5 opi5plus-3 +traefik-6c979cd89d-98fk8 1/1 Terminating 0 2d15h 10.42.1.6 opi5plus-3 +traefik-6c979cd89d-t4rhw 1/1 Running 0 38h 10.42.2.3 opi5plus-1 +``` + +Если бы у нас были рабочие поды на удаленном узле, то они бы перезапустились на других нодах. Но, у нас там был только +`svclb-traefik`, который теперь стал в статусе `Terminating`. Это процесс удаления пода. Kubernetes не сразу удаляет +поды, особенно если они находятся в состоянии "зависания" (например, `Terminating` или `Running`, но стали недоступны). +Так как агент удалён вместе с узлом, то некому сообщить кластеру, что под завершил работу, и он остается "призраком" +в списке. Удалим под `svclb-traefik` вручную (не забудьте заменить `xxxxxxxxx-xxxxx` на реальные значения +`<хеш-ревизии>`и `<суффикс>`): +```bash +sudo k3s kubectl delete pod svclb-traefik-xxxxxxxxx-xxxxx -n kube-system --force --grace-period=0 +``` + +Здесь `--force` и `--grace-period=0` говорят Kubernetes удалить под "форсированно" и "немедленно". Даже если узел +недоступен. Так как это DaemonSet, он не перезапустится на opi5plus-1, потому что узел уже NotReady. + +## Добавление третьего мастера + +Теперь у нас осталось две мастер-ноды и можно добавить третий мастер. Как это сделать, см выше. Но теперь +при добавлении можно в флаге `--server` указать IP как первого, так и второго мастера. И не забудьте в `--tls-san` +указать IP хоста нового (третьего) мастера. +