add: k3s (удаляем воркер-узел №3 и добавим его как мастер)
This commit is contained in:
parent
857d0dd7e1
commit
242f6ca5fb
@ -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`:
|
||||
@ -276,3 +277,101 @@ traefik LoadBalancer 10.43.164.48 192.168.1.26,192.168.1.27,192.16
|
||||
|
||||
Что ж, теперь у нас есть кластер k3s с тремя нодами: двумя мастерами и одним воркером. Но, как я уже говорил, это не
|
||||
идеальная конфигурация, так как у нас четное количество мастер-узлов.
|
||||
|
||||
Попробует отключить один из мастеров (не обязательно выключать питание, достаточно отсоединить сетевой кабель 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 <none> 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` с ролью `<none>` — это остатки бывшего воркера. Если запустить на том же хосте масте, узел
|
||||
может "ожить" и перерегистрироваться с новыми ролями. Но это не обязательно удалит старый объект 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 <none> <none>
|
||||
helm-install-traefik-crd-bdbgd 0/1 Completed 0 4d19h <none> opi5plus-2 <none> <none>
|
||||
helm-install-traefik-mlztm 0/1 Completed 1 4d19h <none> opi5plus-2 <none> <none>
|
||||
local-path-provisioner-5cf85fd84d-jwz5n 1/1 Running 0 4d19h 10.42.0.3 opi5plus-2 <none> <none>
|
||||
metrics-server-5985cbc9d7-n9dwz 1/1 Running 0 4d19h 10.42.0.2 opi5plus-2 <none> <none>
|
||||
svclb-traefik-4f8c2580-h7b9c 3/3 Running 0 2d18h 10.42.0.9 opi5plus-2 <none> <none>
|
||||
svclb-traefik-4f8c2580-nhz65 3/3 Running 0 38h 10.42.2.2 opi5plus-1 <none> <none>
|
||||
svclb-traefik-4f8c2580-qmzf6 3/3 Running 0 2d18h 10.42.1.5 opi5plus-3 <none> <none>
|
||||
traefik-6c979cd89d-98fk8 1/1 Terminating 0 2d15h 10.42.1.6 opi5plus-3 <none> <none>
|
||||
traefik-6c979cd89d-t4rhw 1/1 Running 0 38h 10.42.2.3 opi5plus-1 <none> <none>
|
||||
```
|
||||
|
||||
Если бы у нас были рабочие поды на удаленном узле, то они бы перезапустились на других нодах. Но, у нас там был только
|
||||
`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 хоста нового (третьего) мастера.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user