add: k3s (удаляем воркер-узел №3 и добавим его как мастер)
This commit is contained in:
parent
857d0dd7e1
commit
242f6ca5fb
@ -158,6 +158,7 @@ Unauthorized JSON-ответ от API. Что-то вроде:
|
|||||||
|
|
||||||
## Подключение второго узла (мастер)
|
## Подключение второго узла (мастер)
|
||||||
|
|
||||||
|
|
||||||
Для начала, на первой ноде получим токен для подключения нового узла к кластеру:
|
Для начала, на первой ноде получим токен для подключения нового узла к кластеру:
|
||||||
```bash
|
```bash
|
||||||
sudo cat /var/lib/rancher/k3s/server/node-token
|
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
|
```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`:
|
И увидим, что на новом воркере (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 с тремя нодами: двумя мастерами и одним воркером. Но, как я уже говорил, это не
|
Что ж, теперь у нас есть кластер 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