После курса по Kubernetes собрал в домашней лаборатории кластер, приближенный к «взрослой» топологии: отказоустойчивый control plane, отдельный edge-узел с HAProxy, MetalLB для LoadBalancer-сервисов и NFS для persistent-томов. Всё крутится в виртуальных машинах на Proxmox.
Топология
Слева (A) — состав кластера, справа (B) — путь внешнего запроса до приложения.
Узлы
| Узел | IP | Роль |
|---|---|---|
| kube-ssh-gate-01 | 192.168.1.180 | SSH-шлюз в сеть кластера |
| kube-edge-01 | 192.168.1.181, 10.100.0.100 | Edge: HAProxy, вход трафика и балансировка API |
| kube-monitoring-01 | 192.168.1.182 | Мониторинг |
| kube-master-01…03 | 10.100.0.2–4 | Control plane (HA, 3 узла) |
| kube-minion-01…03 | 10.100.0.5–7 | Worker-узлы: приложения + ingress-nginx |
| kube-nfs-01 | 10.100.0.8 | NFS: persistent-хранилище |
Сеть кластера (10.100.0.0/24) изолирована от домашней (192.168.1.0/24); наружу смотрят только edge, ssh-шлюз и мониторинг.
Путь запроса
- Клиент приходит на kube-edge-01 (HAProxy, 80/443) — TCP passthrough, без терминации TLS на границе;
- HAProxy балансирует на NodePort ingress-nginx воркеров (30080/32043);
- ingress-nginx терминирует TLS и маршрутизирует HTTP на сервис приложения (ClusterIP или LoadBalancer-IP от MetalLB);
- Под приложения при необходимости монтирует том с kube-nfs-01.
Тот же HAProxy балансирует и Kubernetes API между тремя мастерами — у control plane единая точка входа.
Компоненты
- HAProxy (edge) — вход HTTP/HTTPS и балансировка API-сервера;
- MetalLB — LoadBalancer-IP в bare-metal-окружении;
- ingress-nginx — TLS-терминация и маршрутизация;
- NFS — простое общее хранилище для стендов;
- Отдельный SSH-шлюз — доступ администратора в изолированную сеть.
Что даёт лаборатория
Это стенд для практики: раскатка приложений Helm-чартами, эксперименты с отказами (выключение мастера или воркера — и наблюдение, как кластер переживает), обкатка манифестов и подходов до того, как что-то похожее встретится в работе.