add: k3s (узел №3, воркер)

This commit is contained in:
Sergei Erjemin 2025-02-25 17:37:40 +03:00
parent bbaf3c4014
commit ef04ea4e26
2 changed files with 81 additions and 1 deletions

View File

@ -18,7 +18,9 @@
* [Измерение производительности накопителей](raspberry-and-orange-pi/measuring-performance-storage-devices.md)
* [Установка Docker и Docker Compose](raspberry-and-orange-pi/install-docker-compose.md)
* [Резервное копирование и восстановление](raspberry-and-orange-pi/backup-restore.md)
* [Kubernetes на Orange Pi (начало)](raspberry-and-orange-pi/k8s.md)
* [k8s (кubernetes) на Orange Pi (драфт...)](raspberry-and-orange-pi/k8s.md)
* [k3s (кubernetes) на Orange Pi](raspberry-and-orange-pi/k3s.md)
*
## Nginx / Apache
* [Ограничение доступа по User-Agent (на примере GPTBot)](nginx/nginx-ban-user-agent.md)

View File

@ -23,6 +23,16 @@ IoT-устройства, edge-серверы и т.п.). Для кластер
Мне же надо, чтобы как миниум две (а лучше все) ноды могли быть мастерами, так что я буду делать k3s-кластер
с использованием *etcd*.
### Важное предупреждение
k3s -- это не упрощенная мини-версия Kubernetes, здесь все компоненты упакованы в один бинарник, а значит намного
проще не только добавлять узлы, но и удалять их. Так что если что-то пойдет не так с настройкой узла, просто удалите
и начните заново. Удаление k3s с узла:
```bash
sudo /usr/local/bin/k3s-uninstall.sh # На мастерах
sudo /usr/local/bin/k3s-agent-uninstall.sh # На воркере
```
## Установка k3s на первом узле (мастер)
Некоторые требования к узлам:
@ -198,3 +208,71 @@ kube-system traefik-5d45fc8cc9-t5d58 1/1 Running 0
Как видим, у нас появился еще один `svclb-traefik` на второй ноде. Это под -- Service Load Balancer (SLB) для Traefik.
Он эмулирует облачный балансировщик нагрузки (типа AWS ELB), которого нет в локальном окружении вроде Orange Pi.
SLB перенаправляет внешний трафик (например, на порты 80/443) к сервисам типа LoadBalancer внутри кластера.
## Подключение третьего узла (воркера)
Добавление третьего узда в качестве воркера (рабочего узла) мы сделаем временно. Во-первых, чтобы показать как это
делается, а во-вторых, чтобы показать как удалять узел и с какими особенностями это связано. И наконец, в-третьих,
объяснить что такое кворум и почему важно, чтобы в кластере было нечетное количество мастер-узлов.
И так, подключение рабочего узла даже проще, чем мастера. Выполним на нашем новом узле:
```bash
curl -sfL https://get.k3s.io | sh -s - agent --server https://192.168.1.10:6443 --token <ТОКЕН>
```
Здесь ключ:
* `agent` -- устанавливает узел в режиме воркера (worker). Это значит, что узел будет выполнять рабочие нагрузки
(поды), но не будет управлять кластером (без *control-plane*, *master* и на нем нет реплики *etcd*).
Посмотрим на ноды (команда выполняется на одном из мастер-узлов):
```bash
sudo k3s kubectl get nodes
```
Теперь у нас три ноды, и все они имеют статус *Ready*:
```text
NAME STATUS ROLES AGE VERSION
opi5plus-1 Ready <none> 96s v1.31.5+k3s1
opi5plus-2 Ready control-plane,etcd,master 3h v1.31.5+k3s1
opi5plus-3 Ready control-plane,etcd,master 2h v1.31.5+k3s1
```
Новая нода `opi5plus-1` готова к работе и не имеет ролей, а только выполняет рабочие нагрузки (поды).
Посмотрим на поды:
```bash
opi@opi5plus-2:~$ sudo k3s kubectl get pods -n kube-system -o wide
```
И увидим, что на новом воркере (opi5plus-1) запустился под балансировщика `svclb-traefik`:
```text
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
coredns-ccb96694c-tfjwj 1/1 Running 0 3h 10.42.0.4 opi5plus-2 <none> <none>
helm-install-traefik-crd-bdbgd 0/1 Completed 0 3h <none> opi5plus-2 <none> <none>
helm-install-traefik-mlztm 0/1 Completed 1 3h <none> opi5plus-2 <none> <none>
local-path-provisioner-5cf85fd84d-jwz5n 1/1 Running 0 3h 10.42.0.3 opi5plus-2 <none> <none>
metrics-server-5985cbc9d7-n9dwz 1/1 Running 0 3h 10.42.0.2 opi5plus-2 <none> <none>
svclb-traefik-4f8c2580-4q7dj 3/3 Running 0 92s 10.42.2.2 opi5plus-1 <none> <none>
svclb-traefik-4f8c2580-h7b9c 3/3 Running 0 2h 10.42.0.9 opi5plus-2 <none> <none>
svclb-traefik-4f8c2580-qmzf6 3/3 Running 0 2h 10.42.1.5 opi5plus-3 <none> <none>
traefik-6c979cd89d-98fk8 1/1 Running 0 1h 10.42.1.6 opi5plus-3 <none> <none>
```
Посмотрим состояние сервисов в кластере:
```bash
sudo k3s kubectl get service -n kube-system
```
Увидим, что сервис *traefik* доступен на всех нодах:
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 3d
metrics-server ClusterIP 10.43.248.208 <none> 443/TCP 3d
traefik LoadBalancer 10.43.164.48 192.168.1.26,192.168.1.27,192.168.1.28 80:31941/TCP,443:30329/TCP,9000:32185/TCP 3d
```
Можем проверить доступность панели `Traefik` через браузер через IP-адрес нового узла и (в нашем случае `http://192.168.1.26:9000/dashboard/#/`)
и увидим, что балаансировщик работает и перенаправляет трафик и с ноды воркера.
Что ж, теперь у нас есть кластер k3s с тремя нодами: двумя мастерами и одним воркером. Но, как я уже говорил, это не
идеальная конфигурация, так как у нас четное количество мастер-узлов.