Chẩn đoán lỗi cấu hình và trạng thái hệ thống
Trước khi đi sâu vào phân tích logs, bạn cần xác định xem Linkerd có đang hoạt động đúng chuẩn hay không thông qua công cụ kiểm tra tích hợp.
Lệnh linkerd check sẽ quét toàn bộ Control Plane và Data Plane, kiểm tra các thành phần như CRD, RBAC, Network Policies và trạng thái của các proxy. Đây là bước bắt buộc khi gặp sự cố bất thường.
linkerd check --prefix linkerd
Kết quả mong đợi: Tất cả các dòng hiển thị màu xanh lá với trạng thái ok. Nếu có dòng màu đỏ hoặc vàng, hãy chú ý vào thông báo lỗi đi kèm để biết nguyên nhân (ví dụ: thiếu resource, DNS lỗi, hoặc version không tương thích).
Kiểm tra chi tiết từng thành phần
Để tập trung vào một thành phần cụ thể mà không bị nhiễu bởi các kiểm tra khác, hãy sử dụng các cờ (flags) để lọc.
linkerd check --prefix linkerd --proxy
Kết quả mong đợi: Chỉ hiển thị các kiểm tra liên quan đến Data Plane (proxy), giúp bạn xác định nhanh việc injection proxy có thành công hay không.
linkerd check --prefix linkerd --control-plane
Kết quả mong đợi: Chỉ hiển thị các kiểm tra liên quan đến Control Plane, giúp bạn xác định các service như api-server, identity, destination có đang chạy ổn định không.
Chẩn đoán sâu với chế độ debug
Khi linkerd check báo lỗi nhưng không rõ nguyên nhân, hãy bật chế độ debug để xem chi tiết các request nội bộ.
linkerd check --prefix linkerd --verbose
Kết quả mong đợi: Xuất ra toàn bộ output chi tiết bao gồm các phản hồi HTTP từ các service trong control plane, giúp bạn thấy được điểm gãy (failure point) chính xác trong luồng xử lý.
Phân tích logs của Proxy eBPF và Control Plane
Khi sự cố không nằm ở cấu hình mà là lỗi runtime, bạn cần đọc logs. Với kiến trúc eBPF, logs sẽ khác biệt so với sidecar truyền thống do phần lớn logic nằm trong kernel.
Logs của Control Plane nằm trong các container của namespace linkerd. Hãy bắt đầu bằng cách xem logs của service identity và destination vì đây là hai điểm nghẽn thường gặp.
kubectl logs -n linkerd -l app=identity --tail=50
Kết quả mong đợi: Thấy các dòng log ghi nhận việc cấp phát chứng chỉ (issuing certificates) hoặc lỗi handshake TLS. Nếu thấy failed to connect, kiểm tra lại cấu hình CA.
kubectl logs -n linkerd -l app=destination --tail=50
Kết quả mong đợi: Logs hiển thị các request tra cứu endpoint (service discovery). Nếu có lỗi timeout hoặc connection refused, vấn đề thường nằm ở DNS hoặc Network Policy.
Phân tích logs của Proxy trong Pod ứng dụng
Với Linkerd + eBPF, proxy không chạy như một container riêng biệt (sidecar) mà chạy trong cùng namespace với ứng dụng, sử dụng eBPF để intercept traffic. Tuy nhiên, bạn vẫn cần xem logs của phần user-space (linkerd-proxy) để debug các lỗi logic cao cấp.
Giả sử bạn có một pod tên web-app-abc123 trong namespace production. Hãy xem logs của container proxy trong pod đó.
kubectl logs -n production -l app=web-app -c linkerd-proxy --tail=100
Kết quả mong đợi: Logs hiển thị các cảnh báo về policy violation, connection refused từ các pod khác, hoặc lỗi DNS resolution failed nếu proxy không thể resolve tên service.
Sử dụng eBPF trace để debug traffic
Đây là điểm mạnh của kiến trúc eBPF. Bạn có thể sử dụng công cụ linkerd tap để xem traffic đi qua proxy mà không cần thay đổi ứng dụng.
linkerd tap -n production -t deployment -c web-app --server --client
Kết quả mong đợi: Hiển thị thời gian thực các request HTTP/GRPC đi qua proxy, bao gồm method, path, status code, duration. Nếu traffic bị tắc, bạn sẽ thấy request xuất hiện nhưng không có response (hoặc response với status 5xx).
linkerd tap -n production -t deployment -c web-app --server --client --limit 10 --output json
Kết quả mong đợi: Xuất ra 10 request đầu tiên dưới dạng JSON, giúp bạn parse và phân tích chi tiết các trường metadata nếu cần debug sâu hơn.
Xử lý mất kết nối và lỗi DNS Resolution
Mất kết nối (Connection Lost) thường do Network Policy chặn traffic giữa các pod, hoặc proxy không thể forward traffic đúng cách. Lỗi DNS thường do CoreDNS không tương thích hoặc cấu hình stubDomain sai.
Điều tra lỗi DNS Resolution
Linkerd sử dụng DNS để resolve tên service. Nếu proxy không thể resolve tên service nội bộ, tất cả request sẽ thất bại.
Trước tiên, kiểm tra xem CoreDNS có đang hoạt động bình thường không.
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50
Kết quả mong đợi: Không có lỗi SERVFAIL hoặc connection refused liên quan đến các tên service trong cluster.
Trong môi trường eBPF, Linkerd cần cấu hình stubDomain để intercept DNS. Kiểm tra giá trị này trong file cấu hình Linkerd.
kubectl get configmap linkerd-config -n linkerd -o jsonpath='{.data.config}' | jq '.stubDomain'
Kết quả mong đợi: Giá trị mặc định là cluster.local. Nếu bạn đã thay đổi clusterDomain của Kubernetes, hãy đảm bảo giá trị này khớp.
Nếu vẫn lỗi, hãy thử chạy một pod debug để test DNS resolution từ bên trong cluster.
kubectl run dns-test --rm -it --image=busybox --restart=Never -- nslookup kubernetes.default
Kết quả mong đợi: Trả về IP của service kubernetes.default. Nếu lỗi, vấn đề nằm ở CoreDNS hoặc CNI, không phải Linkerd.
Xử lý mất kết nối giữa các Pod
Khi hai pod không thể kết nối, nguyên nhân thường là Network Policy hoặc Proxy không được inject đúng.
kubectl get networkpolicy -A
Kết quả mong đợi: Xem danh sách các Network Policy. Nếu có policy nào Deny hoặc Isolate không cho phép traffic giữa hai namespace liên quan, hãy sửa hoặc xóa policy đó.
Kiểm tra xem proxy đã được inject vào pod chưa bằng cách xem spec của pod.
kubectl get pod web-app-abc123 -n production -o jsonpath='{.spec.containers[?(@.name=="linkerd-proxy")].name}'
Kết quả mong đợi: Trả về linkerd-proxy. Nếu trả về rỗng, proxy chưa được inject. Hãy thêm annotation linkerd.io/inject: enabled vào deployment và redeploy.
Kiểm tra trạng thái kết nối TCP giữa hai pod.
linkerd tap -n production -t deployment -c web-app --server --client --limit 5
Kết quả mong đợi: Nếu thấy timeout hoặc reset, hãy kiểm tra lại firewall, CNI plugin (Calico/Cilium) và đảm bảo chúng tương thích với eBPF.
Tối ưu tài nguyên CPU/RAM cho Proxy trong Production
Proxy eBPF tiêu tốn ít tài nguyên hơn sidecar truyền thống, nhưng vẫn cần cấu hình giới hạn (limit) và yêu cầu (request) hợp lý để tránh làm ảnh hưởng đến ứng dụng chính.
Cấu hình Resource Limits cho Proxy
Bạn có thể cấu hình resource cho proxy thông qua ConfigMap linkerd-config hoặc qua CLI khi inject. Dưới đây là cách cấu hình toàn cục thông qua ConfigMap.
Tạo file cấu hình /tmp/linkerd-proxy-resources.yaml với nội dung sau:
cat > /tmp/linkerd-proxy-resources.yaml
Kết quả mong đợi: File YAML được tạo thành công.
Áp dụng cấu hình vào cluster.
kubectl apply -f /tmp/linkerd-proxy-resources.yaml
Kết quả mong đợi: ConfigMap được cập nhật. Lưu ý: Các pod mới được tạo sẽ áp dụng cấu hình này. Các pod cũ cần được restart để áp dụng.
Restart tất cả các pod trong namespace production để áp dụng cấu hình mới.
kubectl rollout restart deployment -n production
Kết quả mong đợi: Các deployment bắt đầu rollout, các pod cũ bị kill và pod mới được tạo với resource limits đã cấu hình.
Giám sát và điều chỉnh Resource
Sau khi áp dụng, bạn cần giám sát xem CPU/RAM có đủ không. Sử dụng lệnh linkerd stats hoặc kubectl top.
kubectl top pods -n production --containers
Kết quả mong đợi: Xem được usage CPU và RAM của container linkerd-proxy so với limit đã đặt. Nếu usage thường xuyên gần limit (trên 80%), hãy tăng limit lên.
Sử dụng linkerd stat để xem hiệu năng của proxy dưới góc độ Linkerd.
linkerd stat -n production -t deployment -c web-app --proxy
Kết quả mong đợi: Hiển thị số lượng request, tỷ lệ lỗi, và latency của proxy. Nếu latency tăng đột biến khi tải cao, hãy cân nhắc tăng CPU limit.
Tối ưu hóa với eBPF: Giảm overhead
Để tối ưu hơn nữa, hãy đảm bảo kernel của node đã được cấu hình để hỗ trợ eBPF tốt nhất. Kiểm tra các tham số kernel.
sysctl -a | grep net.core.bpf_jit_enable
Kết quả mong đợi: Giá trị phải là 1. Nếu là 0, eBPF sẽ không được biên dịch thành JIT, gây giảm hiệu năng đáng kể.
Để bật JIT (yêu cầu root), tạo file /etc/sysctl.d/99-bpf.conf.
cat > /etc/sysctl.d/99-bpf.conf
Kết quả mong đợi: File cấu hình được tạo.
Áp dụng cấu hình ngay lập tức.
sysctl --system
Kết quả mong đợi: Tham số net.core.bpf_jit_enable được cập nhật thành 1. Hiệu năng của proxy eBPF sẽ tăng lên đáng kể, giảm tiêu thụ CPU.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Service Mesh trên Kubernetes với Linkerd và eBPF
« Phần 5: Giám sát nâng cao và phân tích lưu lượng với eBPF