Triển khai Kiali và Prometheus để giám sát Mesh
Cài đặt Kiali Dashboard để trực quan hóa lưu lượng và Prometheus để thu thập metric từ Envoy Proxy.
Kiali cung cấp giao diện web để xem đồ thị phụ thuộc dịch vụ, phân tích truy vấn và kiểm tra trạng thái mTLS. Prometheus lưu trữ các metric hiệu năng như độ trễ (latency) và số lượng lỗi (error rate) của Database Mesh.
1. Tạo namespace cho monitoring stack nếu chưa tồn tại.
kubectl create namespace istio-system --dry-run=client -o yaml | kubectl apply -f -
Kết quả: Namespace istio-system được tạo hoặc xác nhận là đã tồn tại.
2. Cài đặt Kiali và Prometheus thông qua Helm chart của Istio.
helm install kiali kiali/kiali \
--namespace istio-system \
--set auth.strategy=anonymous \
--set prometheus.enabled=true \
--set prometheus.namespace=istio-system
Kết quả: Các pod kiali-server và prometheus được tạo trong namespace istio-system với trạng thái Running.
3. Cấu hình Ingress cho Kiali để truy cập từ bên ngoài (giả định đã có Gateway).
Chỉnh sửa file cấu hình Kiali để chỉ định cổng Gateway mặc định của Istio.
helm upgrade kiali kiali/kiali \
--namespace istio-system \
--set service.type=ClusterIP \
--set extraConfig.dashboard.defaultRootNamespace=default
Kết quả: Kiali được cấu hình để đọc metric từ tất cả các namespace, sẵn sàng cho việc debug.
4. Verify kết quả bằng cách mở port-forward để truy cập Kiali.
kubectl port-forward svc/kiali 20001:20001 -n istio-system
Kết quả: Terminal hiển thị thông báo "Forwarding from 127.0.0.1:20001 -> 20001". Truy cập http://localhost:20001 trong trình duyệt sẽ thấy dashboard Kiali với các biểu đồ lưu lượng.
Sử dụng kubectl exec và Envoy Admin Endpoint để Debug
Sử dụng các công cụ dòng lệnh để kiểm tra trạng thái nội bộ của Envoy Proxy đang chạy trong pod Database.
Envoy Admin Endpoint (thường là cổng 15000) cung cấp các API JSON chi tiết về các kết nối hiện tại, cấu hình listener, cluster và thống kê lỗi (stats) mà Prometheus không hiển thị đầy đủ.
1. Xác định pod đang chạy Envoy Proxy cho Database.
kubectl get pods -l app=postgres-db -n default
Kết quả: Danh sách các pod, ví dụ: postgres-db-7d8f9c2b4-x9z1. Lưu tên pod này để dùng ở bước tiếp theo.
2. Truy cập vào container Envoy và gọi Admin Endpoint để xem trạng thái kết nối.
kubectl exec -it -n default -c istio-proxy -- curl -s localhost:15000/config_dump | jq '.static_resources.listeners[] | select(.name | contains("127.0.0.1:5432"))'
Kết quả: JSON hiển thị cấu hình listener của Envoy trên cổng 5432. Nếu không có output, có thể Envoy chưa lắng nghe cổng này hoặc cấu hình không đúng.
3. Kiểm tra các kết nối đang hoạt động (Connections) để debug lỗi "connection refused" hoặc treo.
kubectl exec -it -n default -c istio-proxy -- curl -s localhost:15000/clusters | jq '.[] | select(.name | contains("postgres"))'
Kết quả: JSON hiển thị thông tin về cluster PostgreSQL, bao gồm số lượng kết nối hiện tại (upstream_cx_total), trạng thái bảo mật và địa chỉ upstream.
4. Xem các thống kê lỗi chi tiết (Stats) để tìm nguyên nhân handshake failed.
kubectl exec -it -n default -c istio-proxy -- curl -s localhost:15000/stats | grep "ssl_error"
Kết quả: Dòng output hiển thị số lượng lỗi SSL/TLS nếu có. Nếu giá trị > 0, chứng tỏ có vấn đề trong quá trình mTLS handshake.
Xử lý các lỗi phổ biến: Connection Refused, mTLS Handshake Failed
Giải quyết các sự cố mạng và bảo mật thường gặp trong kiến trúc Database Mesh sử dụng Envoy.
Lỗi "Connection Refused" thường do cấu hình Service không khớp hoặc Envoy không được inject. Lỗi "mTLS Handshake Failed" thường do chứng chỉ (certificate) không hợp lệ hoặc policy mTLS quá chặt.
1. Xử lý lỗi "Connection Refused" do Service không khớp.
Kiểm tra xem Service Kubernetes của Database có label selector trùng với Pod không.
kubectl get svc postgres-db -o yaml | grep -A 5 selector
Kết quả: Output hiển thị selector. So sánh với `kubectl get pod postgres-db -o yaml | grep -A 5 labels`. Nếu khác nhau, sửa lại Service.
kubectl patch svc postgres-db -p '{"spec":{"selector":{"app":"postgres-db"}}}'
Kết quả: Service được cập nhật và Envoy có thể định tuyến traffic đến Pod.
2. Xử lý lỗi "Connection Refused" do Envoy chưa lắng nghe cổng 5432.
Đảm bảo Pod Database có annotation để kích hoạt Envoy cho cổng 5432.
kubectl annotate pod postgres-db-7d8f9c2b4-x9z1 \
istio.io/config.json='{"pilotSidecar":{"trafficPorts":[{"number":5432,"name":"postgresql","protocol":"TCP"}]}}' --overwrite
Kết quả: Envoy Proxy trong pod sẽ khởi động lại listener trên cổng 5432.
3. Xử lý lỗi "mTLS Handshake Failed" bằng cách chuyển sang PERMISSIVE mode tạm thời.
Chỉnh sửa PeerAuthentication để cho phép cả plain text và mTLS, giúp debug xem lỗi có phải do chứng chỉ không.
cat
Kết quả: Traffic có thể đi qua cả mTLS và không mTLS. Nếu lỗi biến mất, vấn đề nằm ở chứng chỉ hoặc cấu hình mTLS STRICT.
4. Xử lý lỗi mTLS do chứng chỉ hết hạn hoặc không hợp lệ.
Cập nhật lại chứng chỉ bằng cách restart Istiod (chỉ dùng cho dev/debug) hoặc kiểm tra thời gian sống (TTL) của chứng chỉ.
kubectl rollout restart deployment istiod -n istio-system
Kết quả: Istiod sẽ phát hành lại chứng chỉ mới cho tất cả các proxy. Kiểm tra lại lỗi bằng lệnh `grep "ssl_error"` ở phần trước.
Mẹo tối ưu hiệu năng cho Database qua Envoy/Istio
Cấu hình Envoy để giảm độ trễ và tăng thông lượng khi truy cập Database qua Service Mesh.
Mặc định Envoy có thể tạo overhead không cần thiết cho Database. Cần tắt một số tính năng như TCP Fast Open (nếu không cần), điều chỉnh timeout và buffer.
1. Cấu hình Timeout để tránh treo kết nối dài (Long-running connections).
Sử dụng VirtualService hoặc DestinationRule để đặt timeout cụ thể cho database query.
cat
Kết quả: Envoy giới hạn số lượng kết nối TCP đồng thời và đặt thời gian kết nối tối đa là 5 giây, giúp tránh tràn buffer.
2. Bật TCP Keepalive để phát hiện kết nối chết sớm.
Thêm cấu hình keepalive vào DestinationRule để giữ kết nối ổn định.
cat
Kết quả: Envoy sẽ gửi gói tin giữ kết nối mỗi 30 giây. Nếu không nhận được phản hồi sau 10 giây, kết nối sẽ bị đóng để tiết kiệm tài nguyên.
3. Giảm overhead của mTLS cho lưu lượng nội bộ tin cậy (nếu cần).
Trong môi trường nội bộ Kubernetes an toàn, có thể cân nhắc tắt mTLS để giảm latency, nhưng chỉ nên làm sau khi đã test kỹ.
cat
Kết quả: Traffic đến postgres-db không còn yêu cầu mTLS, giảm độ trễ handshake đáng kể. Lưu ý: Chỉ dùng trong môi trường Dev/Test hoặc khi đã có firewall mạng ở tầng hạ tầng.
4. Verify hiệu năng sau khi tối ưu.
Dùng Prometheus để so sánh độ trễ (latency) trước và sau khi cấu hình.
curl http://prometheus:9090/api/v1/query?query=histogram_quantile(0.95, sum(rate(istio_request_duration_milliseconds_bucket{reporter="source", destination_service="postgres-db"}[1m])) by (le))
Kết quả: Giá trị P95 latency giảm xuống, chứng tỏ cấu hình tối ưu đã phát huy tác dụng.
Điều hướng series:
Mục lục: Series: Triển khai Database Mesh với Envoy và Istio trên Ubuntu 24.04
« Phần 5: Cấu hình Policy và Traffic Management cho Database