erjemin/doc_memo
erjemin/doc_memo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add: k3s (подключение внешнего

Browse Source 
узла, part-fin)
This commit is contained in:
Sergei Erjemin 2025-03-07 12:09:22 +03:00
parent a86d2d5ed7
commit 8634efc350
1 changed files with 29 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
raspberry-and-orange-pi/k3s.md
View File

@ -619,9 +619,33 @@ sudo k3s kubectl get nodes
Получим, например:
```text
NAME STATUS ROLES AGE VERSION
opi5plus-1 Ready control-plane,etcd,master 5d4h v1.31.5+k3s1
opi5plus-2 Ready control-plane,etcd,master 8d v1.31.5+k3s1
opi5plus-3 Ready control-plane,etcd,master 7d2h v1.31.5+k3s1
opi5plus-1 Ready control-plane,etcd,master 1d4h v1.31.5+k3s1
opi5plus-2 Ready control-plane,etcd,master 1d v1.31.5+k3s1
opi5plus-3 Ready control-plane,etcd,master 1d2h v1.31.5+k3s1
rpi3b Ready <none> 25h v1.31.6+k3s1
vps-sw-eye Ready <none> 7h35m v1.31.6+k3s1
vps-sw-eye Ready <none> 35m v1.31.6+k3s1
```
#### Проблема Flannel для внешних узлов
Узлы во внешнем интернете создаются и управляются через Kubernetes API, используя порт `6443/TCP`. Но, для того чтобы
передавать трафик и данные между узлами k3s использует сетевой плагин **Flannel**. Он встроен в бинарник k3s (в отличие
от k8s, где Flannel работают как поды) и использует overlay-сеть (`10.42.x.x`). Это внутренняя сеть k3s, VXLAN-туннель
между всеми узлами кластера (мастерами и воркерами). Flannel использует порт `8472/UDP`.
К сожалению проброс порта `8472` с внешнего хоста в домашнюю сеть через роутер не поможет, так обмен идёт не через TCP-,
а UDP-порт. Внешний узел отправит пакеты через overlay-сеть Flannel (10.42.x.x) через 8472/UDP к мастеру, но Мастер
отвечает через свой реальный IP (192.168.1.x), который недоступен напрямую из интернета без обратного проброса или VPN.
Проброс <PUBLIC_IP>:8472 → <VIP>>:8472 позволяет трафику от внешнего хоста доходить до домашней сети, но ответный
трафик от мастеров к VPS (например, от <NODE-1>:8472 к <VPS_IP>:8472) не будет проходить, потому что NAT в роутере
"односторонний" — он не знает, как маршрутизировать UDP-ответы от мастеров обратно к VPS через интернет.
Таким образом, для управления удаленным узлом нужно чтобы он имел локальный IP-адрес в домашней сети, а не внешний.
SSH-тоннель с помощью `autossh` и упаковкой UDP-трафика в TCP через `socat` не сработает (а я надеялся). Таким образом
"пробросить" Flannel для полноценного подключения удаленного k3s-узла -- VPN-туннель между каждой мастер-нодой на
удаленный узел. Это вполне рабочия вариант, если удаленные узлы -- полноценные и произвольные хосты. Но в моём
случае удаленный узел -- хост на 1 ядро и 1 ГБ ОЗУ. К тому же он на платформе x86_64, а не ARM, а значит ради одного
узла не стоит заморачиваться с VPN.
Другим вариантом является подключение внутри самих подов на удаленном узле к необходимым сервисам напрямую. Но таким
образом порты базы данных, менеджеров очередей и т.д. будут доступны из интернета, что небезопасно и в целом плохая идея.