Cơn ác mộng gián đoạn dịch vụ theo vùng
Các Kubernetes Ingress controller tiêu chuẩn xử lý lưu lượng nội bộ rất tốt. Nhưng khi toàn bộ một vùng điện toán đám mây (cloud region) như US-East-1 gặp sự cố nghiêm trọng, Ingress cục bộ của bạn sẽ trở thành một ngõ cụt. Nếu hạ tầng của bạn trải dài qua các biên giới địa lý—chẳng hạn như US-East và EU-West—bạn cần một cách để điều phối lưu lượng ở cấp độ DNS dựa trên trạng thái sức khỏe (health) của cluster theo thời gian thực.
Trong nhiều năm, Global Server Load Balancing (GSLB) vốn bị giới hạn trong các phần cứng đắt tiền như F5 BIG-IP hoặc các dịch vụ đám mây độc quyền như AWS Route53. Những công cụ này thường tạo cảm giác như những thành phần “ngoại lai” trong một quy trình làm việc chuẩn Kubernetes (Kubernetes-native). K8gb thay đổi điều đó. Đây là một operator mã nguồn mở giúp biến CoreDNS hiện có của bạn thành một bộ cân bằng tải phân tán toàn cầu, vận hành ngay tại nơi mã nguồn của bạn thực thi.
Tại sao K8gb vượt trội hơn GSLB truyền thống
Hầu hết các giải pháp GSLB yêu cầu gọi API thủ công hoặc các tích hợp rưuờm rà để cập nhật bản ghi DNS khi có sự cố xảy ra. K8gb khắc phục điều này bằng cách sử dụng mô hình Kubernetes Operator. Nó liên tục theo dõi sức khỏe ứng dụng của bạn trên các cluster. Nếu một dịch vụ ở London bị lỗi, K8gb sẽ tự động ghi đè các phản hồi DNS để điều hướng người dùng sang New York thay thế.
Vấn đề lệ thuộc vào nhà cung cấp (vendor lock-in) không còn là trở ngại ở đây. Bạn có thể chạy một cluster trên GKE, một cluster khác tại chỗ (on-premises), và một cluster thứ ba trên AWS. K8gb tạo ra một mạng lưới (mesh) nhẹ giữa chúng để chia sẻ trạng thái sức khỏe. Trong các bài kiểm tra thực tế của tôi, thiết lập này xử lý các đợt tăng đột biến độ trễ vùng tốt hơn nhiều so với việc phân bổ trọng số DNS tĩnh, thường kích hoạt failover trong vòng chưa đầy 10 giây.
Thiết lập mạng lưới đa vùng của bạn
Bạn cần ít nhất hai cluster Kubernetes để thấy được sự kỳ diệu. Trong hướng dẫn này, chúng ta sẽ sử dụng cluster-eu và cluster-us. Mỗi cluster phải có một dịch vụ LoadBalancer công khai hoặc một địa chỉ IP có thể truy cập được.
Điều kiện tiên quyết
- Hai cluster Kubernetes đang hoạt động (v1.24+).
- Helm đã được cài đặt trên máy cục bộ.
- Một tên miền (ví dụ:
example.com) được quản lý qua Route53, Cloudflare, hoặc các nhà cung cấp tương tự.
Cài đặt K8gb qua Helm
Bạn cần chạy lệnh cài đặt trên cả hai cluster để chúng có thể giao tiếp với nhau. K8gb hoạt động dựa trên CoreDNS, vì vậy chúng ta sẽ triển khai nó bằng Helm chart chính thức. Mỗi site cần một geo-tag duy nhất để xác định vị trí của nó.
# Triển khai lên cluster EU
helm repo add k8gb https://www.k8gb.io
helm repo update
helm install k8gb k8gb/k8gb \
--namespace k8gb \
--create-namespace \
--set k8gb.clusterGeoTag="eu" \
--set k8gb.extGslbClustersGeoTags="us" \
--set k8gb.edgeDNSZone="example.com" \
--set k8gb.edgeDNSServers="8.8.8.8"Bây giờ, hãy chuyển context sang cluster US và chạy lại lệnh trên, nhưng thay đổi các tag tương ứng:
# Triển khai lên cluster US
helm install k8gb k8gb/k8gb \
--namespace k8gb \
--create-namespace \
--set k8gb.clusterGeoTag="us" \
--set k8gb.extGslbClustersGeoTags="eu" \
--set k8gb.edgeDNSZone="example.com" \
--set k8gb.edgeDNSServers="8.8.8.8"K8gb sử dụng ExternalDNS bên dưới. Nó tạo các bản ghi NS (Name Server) tại nhà cung cấp DNS chính của bạn, ủy quyền hiệu quả một subdomain như gslb.example.com cho các instance K8gb đang chạy bên trong cluster của bạn.
Xác định chiến lược điều phối lưu lượng
Hãy quên việc quản lý bản ghi DNS thủ công đi. Khi operator đã hoạt động, bạn có thể kiểm soát lưu lượng bằng Custom Resource Gslb. Bạn có thể chọn giữa các chiến lược RoundRobin, Failover, hoặc GeoIP tùy theo nhu cầu.
Chiến lược Failover
Failover là lựa chọn an toàn nhất cho các ứng dụng nặng về cơ sở dữ liệu. Bạn chỉ định một vùng Chính (Primary) và chỉ điều hướng lưu lượng đến vùng Phụ (Secondary) nếu vùng Chính hoàn toàn không thể truy cập. Điều này ngăn chặn các vấn đề nhức nhối về tính nhất quán dữ liệu do độ trễ sao chép giữa các vùng (cross-region replication lag).
# failover-strategy.yaml
apiVersion: k8gb.absa.oss/v1beta1
kind: Gslb
metadata:
name: my-app-gslb
namespace: my-app
spec:
strategy:
type: failover
primaryGeoTag: eu
ingress:
rules:
- host: app.gslb.example.com
http:
paths:
- path: /
backend:
serviceName: my-app-service
servicePort: 80Áp dụng tệp này cho cả hai cluster. K8gb sẽ phát hiện host chung app.gslb.example.com. Vì eu là vùng chính, các truy vấn DNS sẽ trả về IP LoadBalancer của vùng EU miễn là các pod đó còn khỏe mạnh.
Chiến lược Round Robin
Các microservice không trạng thái (stateless) hoạt động rất hiệu quả với roundRobin. Chiến lược này phân bổ người dùng trên tất cả các vùng để cân bằng tải. Đây là một cách đơn giản để cải thiện hiệu suất cho lượng người dùng toàn cầu.
spec:
strategy:
type: roundRobinỞ chế độ này, K8gb trả về địa chỉ IP từ cả hai cluster. DNS resolver của client sau đó sẽ tự động xoay vòng qua các địa chỉ đó.
Xác minh và Giám sát trong môi trường Production
Kiểm thử GSLB đòi hỏi một sự thay đổi trong tư duy. Bạn không chỉ kiểm tra mã trạng thái HTTP; bạn còn phải theo dõi các phản hồi DNS. Sử dụng công cụ dig để xem cluster nào đang trả lời yêu cầu của bạn.
# Truy vấn trực tiếp instance DNS của K8gb
dig @<K8GB_SERVICE_IP> app.gslb.example.comThử mô phỏng một sự cố bằng cách giảm số lượng pod (scale) của deployment chính về 0. Trong khoảng 10 đến 30 giây, quá trình kiểm tra sức khỏe của K8gb sẽ đánh dấu site EU là đã sập. Chạy lại lệnh dig, và bạn sẽ thấy địa chỉ IP của cluster US xuất hiện ngay lập tức.
Khả năng quan sát (Observability) là bắt buộc đối với môi trường production. K8gb xuất các chỉ số (metrics) sang Prometheus theo mặc định. Tôi khuyên bạn nên xây dựng một dashboard Grafana để theo dõi ba khu vực chính sau:
- Sức khỏe vùng (
k8gb_gslb_status): Cluster US có nhìn thấy cluster EU đang ở trạng thái “Up” không? - Độ trễ phân giải: Các instance CoreDNS của bạn có phản hồi trong dưới 20ms không?
- Lỗi đồng bộ Edge: Bạn có đang gặp giới hạn tốc độ gọi API (rate limit) trên Route53 hoặc Cloudflare không?
Theo kinh nghiệm của tôi, hệ thống hiếm khi lỗi ở cấp độ K8gb. Hầu hết các vấn đề bắt nguồn từ cấu hình “Edge DNS”. Nếu các bản ghi NS của tên miền cha không trỏ chính xác đến các IP LoadBalancer của K8gb, việc điều phối lưu lượng sẽ thất bại ngay cả trước khi nó bắt đầu. Hãy coi các quy tắc lưu lượng toàn cầu như mã nguồn (as-code), và bạn sẽ đạt được khả năng phục hồi mà các hệ thống phân tán hiện đại yêu cầu.
