add: k3s (подключение внешнего
узла, part-fin)
This commit is contained in:
parent
a86d2d5ed7
commit
8634efc350
@ -619,9 +619,33 @@ sudo k3s kubectl get nodes
|
|||||||
Получим, например:
|
Получим, например:
|
||||||
```text
|
```text
|
||||||
NAME STATUS ROLES AGE VERSION
|
NAME STATUS ROLES AGE VERSION
|
||||||
opi5plus-1 Ready control-plane,etcd,master 5d4h v1.31.5+k3s1
|
opi5plus-1 Ready control-plane,etcd,master 1d4h v1.31.5+k3s1
|
||||||
opi5plus-2 Ready control-plane,etcd,master 8d v1.31.5+k3s1
|
opi5plus-2 Ready control-plane,etcd,master 1d v1.31.5+k3s1
|
||||||
opi5plus-3 Ready control-plane,etcd,master 7d2h v1.31.5+k3s1
|
opi5plus-3 Ready control-plane,etcd,master 1d2h v1.31.5+k3s1
|
||||||
rpi3b Ready <none> 25h v1.31.6+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.
|
||||||
|
|
||||||
|
Другим вариантом является подключение внутри самих подов на удаленном узле к необходимым сервисам напрямую. Но таким
|
||||||
|
образом порты базы данных, менеджеров очередей и т.д. будут доступны из интернета, что небезопасно и в целом плохая идея.
|
||||||
|
Loading…
Reference in New Issue
Block a user