1. Tổng quan
Trong quá trình triển khai hệ thống Kubernetes, đôi lúc bạn sẽ có nhu cầu mở kênh kết nối VPN kiểu client-to-site, để người dùng từ xa có thể truy cập vào các tài nguyên nội bộ như:
- Pod, Service trong cluster Kubernetes
- Các node (master, worker)
- Mạng nội bộ tại site (VD:
192.168.0.0/24,10.10.10.0/24, v.v.)
Một giải pháp tưởng như hợp lý là: tạo một Pod trong cluster Kubernetes chạy WireGuard hoặc OpenVPN, từ đó người dùng kết nối vào.
Tuy nhiên, mô hình này thực tế có nhiều giới hạn về mạng mà nếu không hiểu rõ, bạn sẽ gặp khó khăn khi triển khai.
Bài viết này chia sẻ chi tiết:
- Tại sao VPN client-to-site trong Pod có thể không như bạn kỳ vọng
- Các mô hình VPN thay thế và cách triển khai phù hợp hơn
- So sánh ưu/nhược điểm từng mô hình
- Sơ đồ minh họa cho từng cách làm
- Lời khuyên thực tiễn
Vấn đề thường gặp khi chạy VPN server trong Pod Kubernetes.
Một số người triển khai VPN server (WireGuard/OpenVPN) trong Pod trong cluster K8s với mục đích như sau:
- Cho client VPN truy cập vào toàn bộ hệ thống (bao gồm Pod, Service, node và mạng LAN)
- Tận dụng auto scaling hoặc CI/CD để quản lý VPN server
Nhưng khi client kết nối vào thì… họ chỉ truy cập được IP của Service, còn các tài nguyên khác như:
- IP Pod
- IP node (master/worker)
- IP mạng nội bộ
→ đều không truy cập được, hoặc rất hạn chế.
2. Các mô hình triển khai VPN client-to-site với Kubernetes
Mô hình 1: VPN server chạy trong Pod Kubernetes (Service IP)
Sơ đồ:
[Client VPN]
|
~ Internet ~
|
[Pod chạy WireGuard/OpenVPN]
|
+------------------+
| Kubernetes |
| Cluster |
| ┌────────────┐ |
| | Services | <── Có thể truy cập
| └────────────┘ |
| ┌────────────┐ |
| | Pods | <── Có thể không truy cập được
| └────────────┘ |
+------------------+
[LAN / Node IP: KHÔNG truy cập được]Ưu điểm:
- Dễ triển khai
- Có thể tích hợp vào CI/CD pipeline
Nhược điểm:
- Client VPN không truy cập được IP node hoặc mạng nội bộ
- Không truy cập được các tài nguyên bên ngoài Kubernetes
- Cần hiểu rõ Kubernetes networking để debug
Mô hình 2: VPN server chạy trên VM hoặc máy vật lý ngoài Kubernetes
Sơ đồ:
[Client VPN]
|
~ Internet ~
|
[WireGuard/OpenVPN VM]
|
[Site LAN: 192.168.x.x]
|
+---------------------+
| Kubernetes Cluster |
| ┌─────────────────┐ |
| | Nodes (Master...)| <── Truy cập được
| | Pods / Services | <── Truy cập được (qua routing)
| └─────────────────┘ |
+---------------------+Ưu điểm:
- Truy cập được tất cả: Pod, node, LAN, DB nội bộ…
- Không bị giới hạn bởi Kubernetes overlay network
- Routing dễ cấu hình hơn
Nhược điểm:
- Cần có một VM/gateway riêng
- Khó quản lý bằng YAML/Helm (nằm ngoài K8s)
Mô hình 3: VPN server trong Pod (HostNetwork + privileged)
Sơ đồ.
[Client VPN]
|
~ Internet ~
|
[VPN Pod - HostNetwork + Privileged]
|
[Node thực (host)]
|
+------------------+
| Kubernetes |
| Pods + Services |
+------------------+
[LAN subnet: Có thể truy cập qua NAT & route]Ưu điểm:
- VPN server có thể truy cập node IP và LAN nếu cấu hình chuẩn
- Vẫn nằm trong cluster Kubernetes (quản lý dễ hơn mô hình 2)
Nhược điểm:
- Phải cấp quyền cao (privileged + hostNetwork)
- Không dễ scale, chạy đa node phức tạp
- Phức tạp khi triển khai trong cloud hoặc public cluster
Mô hình 4: VPN server + MetalLB + routing nâng cao (advanced)
Sơ đồ:
[Client VPN]
|
~ Internet ~
|
[VPN Service (MetalLB IP)]
|
[Kubernetes Cluster Network]
|
┌──────────────┐
| WireGuard Pod| <── cần NAT/Forwarding
└──────────────┘
|
[Route đi ra LAN + node qua iptables + router config]
Ưu điểm:
- Truy cập được Pod, Services, node, LAN nếu cấu hình chuẩn
- VPN server vẫn nằm trong cluster (quản lý bằng YAML)
Nhược điểm:
- Phức tạp về routing, iptables, NAT, sysctl…
- Cần cấu hình route tại router hoặc switch của site
- Khó mở rộng, khó debug nếu không quen Linux net stack
3. So sánh tổng thể
| Mô hình | Quản lý dễ | Truy cập Pod | Truy cập Node | Truy cập LAN | Mức độ phức tạp |
|---|---|---|---|---|---|
| 1. VPN trong Pod (thường) | ✅ | ✅ (hạn chế) | ❌ | ❌ | Thấp |
| 2. VPN ngoài K8s (VM) | ❌ | ✅ | ✅ | ✅ | Trung bình |
| 3. VPN Pod (hostNetwork) | ✅ | ✅ | ✅ | ✅ | Cao |
| 4. VPN + MetalLB + routing | ✅ | ✅ | ✅ | ✅ | Rất cao |
4. Ví dụ thực tế mô hình dùng VM làm VPN Gateway
- Cài WireGuard trên một VM nằm trong mạng
192.168.10.0/24 - Cấp cho client VPN địa chỉ
10.66.66.2/24 - Cấu hình
AllowedIPs = 0.0.0.0/0trên client - Cấu hình route tại router: vbnetCopyEdit
Destination: 10.66.66.0/24 Next hop: 192.168.10.10 (IP của VM VPN)
Client VPN sẽ:
- Truy cập được các IP trong LAN
- Vào cluster K8s qua IP node hoặc các service đã expose
5. Lời khuyên thực tiễn
- ✅ Nếu mục tiêu của bạn là cho phép client truy cập toàn bộ hệ thống (K8s + LAN + node IP):
→ Hãy triển khai VPN server ngoài cluster Kubernetes (trên một VM hoặc thiết bị gateway) - ⚠️ Chỉ nên dùng mô hình VPN trong Pod nếu:
- Bạn chỉ cần client truy cập một vài service trong cluster
- Không cần truy cập LAN hoặc IP node
- Bạn quen với cấu hình networking Linux (iptables, routing)
- ❗ Đừng đánh giá thấp việc cấu hình routing, NAT và forwarding nếu bạn chọn giải pháp trong Pod.
6. Kết luận
Việc triển khai VPN client-to-site trong môi trường Kubernetes cần cân nhắc kỹ về kiến trúc mạng. Dù việc đặt VPN server trong một Pod nghe có vẻ hợp lý, nhưng nó không giúp bạn truy cập toàn bộ hệ thống nếu không đi kèm rất nhiều cấu hình phức tạp.
Lựa chọn đơn giản, ổn định và dễ bảo trì nhất chính là: VPN server đặt ngoài cluster Kubernetes, sử dụng một server vật lý hoặc VM trong cùng mạng nội bộ.
