Phân tích và xử lý sự cố log của Cilium, Istio và eBPF
Trong môi trường production, việc đầu tiên khi gặp sự cố là xác định nguồn gốc lỗi từ kernel, Cilium CNI, hay Sidecar Proxy của Istio.
Chúng ta sẽ tập trung vào các log phổ biến nhất: lỗi drop packet của eBPF, lỗi handshake mTLS giữa Envoy và ứng dụng, và lỗi OOM của container.
Xử lý lỗi "Drop" và "Error" trong Cilium Hubble
Khi lưu lượng bị chặn hoặc mất mát, Hubble là công cụ đầu tiên để kiểm tra. Lỗi thường gặp là "Policy Denied" hoặc "Connection Refused" do eBPF map bị full.
Chạy lệnh sau để xem các gói tin bị drop trong 5 phút gần nhất với chi tiết policy:
hubble observe --since 5m --type policy --output json | jq '.[] | select(.verdict == "DROP") | {src: .connection.source.ip, dst: .connection.destination.ip, port: .connection.destination.port, policy: .policy.reason}'
Kết quả mong đợi: Một danh sách JSON chỉ ra nguồn, đích và lý do policy (ví dụ: "Identity: 1234 (kube-system)" bị từ chối bởi AuthorizationPolicy).
Nếu thấy lỗi "Map full" hoặc "Too many entries", đây là dấu hiệu eBPF map đã hết dung lượng, cần điều chỉnh tham số kernel.
Phân tích log lỗi mTLS của Envoy Sidecar
Lỗi phổ biến nhất trong mesh là "Handshake failed" hoặc "TLS error". Nguyên nhân thường do chứng thư số (cert) hết hạn hoặc không khớp giữa client và server.
Định tuyến log của sidecar envoy trong pod để tìm lỗi:
kubectl logs -n -c istio-proxy --tail 200 | grep -i "handshake\|tls\|certificate"
Kết quả mong đợi: Các dòng log chỉ rõ lỗi như "handshake failure: certificate unknown" hoặc "certificate has expired".
Để kiểm tra trạng thái chứng thư số đang được sử dụng bởi Istiod, chạy lệnh:
istioctl proxy-status -n -o wide
Kết quả mong đợi: Bảng hiển thị trạng thái "OK" hoặc "HEALTHY" cho các pod. Nếu thấy "FAIL", hãy kiểm tra thời gian hết hạn của cert trong log.
Debug lỗi eBPF và Kernel Panic
Khi eBPF program bị lỗi nghiêm trọng, nó có thể gây crash kernel hoặc làm mất kết nối mạng hoàn toàn. Cần kiểm tra dmesg của node.
Chạy lệnh trên node để xem lỗi kernel liên quan đến eBPF:
dmesg | grep -i "eBPF\|cilium\|invalid\|segfault"
Kết quả mong đợi: Các dòng log kernel chỉ ra lỗi như "eBPF program failed to attach" hoặc "invalid argument".
Để kiểm tra trạng thái của Cilium Agent trên node:
kubectl logs -n kube-system -l k8s-app=cilium --all-containers --tail 100 | grep -i "error\|failed"
Kết quả mong đợi: Log chỉ rõ lỗi cấu hình hoặc lỗi tải driver eBPF.
Tối ưu cấu hình Kernel và Resource cho Production
Mặc định của Kubernetes và Linux thường chưa tối ưu cho eBPF và Service Mesh. Để đạt hiệu năng cao và độ trễ thấp, cần tinh chỉnh kernel parameters.
Cấu hình Kernel Parameters cho eBPF
eBPF yêu cầu map lớn hơn và số lượng program nhiều hơn so với mặc định. Cần tăng `net.core.somaxconn` và `vm.max_map_count`.
Tạo file cấu hình sysctl để áp dụng trên tất cả các node worker. Lưu file vào `/etc/sysctl.d/99-cilium-eBPF.conf`:
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_tw_reuse = 1
vm.max_map_count = 262144
net.core.bpf_jit_harden = 2
net.core.bpf_jit_enable = 1
Áp dụng cấu hình ngay lập tức:
sysctl --system
Kết quả mong đợi: Không có lỗi trả về, và các tham số được cập nhật (kiểm tra bằng `sysctl -a | grep somaxconn`).
Tối ưu Resource Limit cho Sidecar và Cilium
Envoy Proxy tiêu tốn RAM đáng kể. Nếu không set limit, container có thể bị OOM Kill, gây gián đoạn dịch vụ. Cilium agent cũng cần CPU để xử lý packet.
Cập nhật `IstioOperator` manifest để giới hạn resource cho sidecar. Lưu file `istio-values.yaml`:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
name: istio-base
namespace: istio-system
spec:
values:
global:
proxy:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
pilot:
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 2Gi
Áp dụng cấu hình:
istioctl install -f istio-values.yaml
Kết quả mong đợi: Các pod sidecar mới khởi động với resource limit đã đặt, không bị OOM Kill khi traffic tăng.
Đối với Cilium, chỉnh `CiliumClusterwideNetworkPolicy` hoặc config map để tối ưu số lượng eBPF map. Chỉnh sửa `cilium-config` trong namespace `kube-system`:
kubectl edit cm cilium-config -n kube-system
Thêm hoặc sửa các key sau trong data:
auto-direct-node-routes: "true"
bpf-l7-proxy-redirect-policy: "native"
k8s-require-full-init: "false"
Kết quả mong đợi: Cilium agent tự động reload và tối ưu hóa route table, giảm overhead cho packet forwarding.
Xử lý vấn đề Latency và Throughput trong Mesh
Service Mesh thêm overhead do quá trình proxy và mTLS. Nếu không tối ưu, latency có thể tăng 10-20ms mỗi hop.
Giảm Latency bằng Connection Pooling và Keep-Alive
Mặc định, Envoy có thể tạo kết nối mới cho mỗi request nếu không cấu hình đúng. Cần tăng số lượng kết nối trong pool.
Tạo `DestinationRule` để cấu hình connection pool cho workload quan trọng:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: pool-optimize
namespace: production
spec:
host: api-service.production.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1000
http:
http2MaxRequests: 1000
maxRequestsPerConnection: 100
tls:
mode: ISTIO_MUTUAL
loadBalancer:
simple: ROUND_ROBIN
Áp dụng chính sách:
kubectl apply -f destination-rule-pool.yaml
Kết quả mong đợi: Latency giảm đáng kể khi test với load cao, số lượng kết nối TCP duy trì ổn định.
Giảm Throughput Bottleneck bằng eBPF Acceleration
Đảm bảo Cilium đang sử dụng eBPF mode thay vì iptables để tăng throughput. Kiểm tra mode hiện tại:
kubectl get pods -n kube-system -l k8s-app=cilium -o json | jq '.items[].spec.containers[] | select(.name=="cilium") | .env | map(select(.name=="CILIUM_MODE")) | .[0].value'
Kết quả mong đợi: Giá trị phải là "bpf". Nếu là "iptables", cần chuyển đổi sang bpf (yêu cầu reboot node hoặc reinstall).
Để giảm overhead của mTLS, bật "Inline" mode cho Envoy nếu supported (tùy phiên bản). Hoặc sử dụng `Sidecar` injection với `resources` tối ưu như đã làm ở phần trên.
Chạy benchmark để đo throughput trước và sau khi tối ưu:
istioctl experimental pprof --duration 30s --type memory --address ..svc.cluster.local:15020
Kết quả mong đợi: Phân tích memory profile cho thấy giảm peak memory usage của Envoy.
Chiến lược nâng cấp và duy trì Service Mesh an toàn
Nâng cấp Service Mesh là rủi ro cao vì thay đổi cấu trúc mạng và bảo mật. Cần tuân thủ quy trình Canary và Rollback tự động.
Chiến lược nâng cấp Istio theo phiên bản nhỏ
Không bao giờ nhảy phiên bản lớn (ví dụ 1.15 -> 1.18). Luôn nâng cấp từng minor version (1.15 -> 1.16 -> 1.17).
Sử dụng `istioctl upgrade` để nâng cấp an toàn. Trước tiên, kiểm tra trạng thái hiện tại:
istioctl version
Thực hiện nâng cấp lên minor version tiếp theo (ví dụ 1.16.0):
istioctl upgrade --version 1.16.0 --set revision=default --wait --set pilot.autoscaleMin=2 --set pilot.autoscaleMax=5
Kết quả mong đợi: Istio operator tự động cập nhật các component, và các pod được rolling update mà không drop connection.
Chiến lược nâng cấp Cilium với eBPF
Nâng cấp Cilium cần cẩn thận vì thay đổi kernel module. Luôn test trên cluster staging trước.
Sử dụng Helm để nâng cấp:
helm upgrade cilium cilium/cilium --namespace kube-system --version 1.14.0 --set bpf.kubeProxyReplacement=true --set bpf.masquerade=true
Kết quả mong đợi: Cilium pods restart và áp dụng các thay đổi eBPF mới.
Giám sát và Rollback tự động
Cài đặt Alerting để phát hiện sự cố ngay khi nâng cấp. Nếu error rate vượt quá ngưỡng, tự động rollback.
Tạo `VirtualService` để phân chia traffic cho version mới (Canary):
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: canary-rollout
namespace: production
spec:
hosts:
- api-service
http:
- route:
- destination:
host: api-service
subset: v1
weight: 90
- destination:
host: api-service
subset: v2
weight: 10
Áp dụng và giám sát metrics. Nếu lỗi tăng, giảm weight của v2 về 0:
kubectl apply -f virtual-service-canary.yaml
Kết quả mong đợi: Traffic được phân chia 90/10. Nếu v2 lỗi, Kiali hoặc Prometheus sẽ báo động, cho phép rollback thủ công hoặc tự động.
Bảo trì định kỳ và Audit Policy
Thực hiện audit chính sách bảo mật hàng tuần để loại bỏ các policy không cần thiết gây tắc nghẽn.
Chạy lệnh audit:
istioctl analyze -n production --verbose
Kết quả mong đợi: Danh sách các cảnh báo về policy bị xung đột hoặc không được sử dụng.
Xóa các policy thừa:
kubectl delete authorizationpolicy -n production
Kết quả mong đợi: Hệ thống nhẹ hơn, hiệu năng tăng lên và rủi ro bảo mật giảm.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Service Mesh nội bộ an toàn với Istio, Cilium và eBPF trên Kubernetes để quản lý lưu lượng mạng, bảo mật và quan sát chi tiết
« Phần 6: Thiết lập hệ thống quan sát (Observability) với Hubble và Kiali