Cài Linkerd lên cụm K8s thật, và những điều học được

Sau khi chọn Linkerd ở phần trước, mình dành một buổi tối để cài lên cụm K8s thật. Bài này ghi lại các bước, và quan trọng hơn, những chỗ mọi thứ không suôn sẻ như tài liệu mô tả.

Cài control plane

Cài Linkerd bắt đầu bằng việc kiểm tra cụm có đáp ứng yêu cầu hay không, rồi cài phần lõi:

linkerd check --pre
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check

Bước check --pre đáng làm kỹ, nó bắt lỗi cấu hình trước khi mình kịp cài gì lên cụm. Lần đầu mình bỏ qua bước này, và mất nửa tiếng để nhận ra namespace linkerd đã tồn tại từ một lần thử nghiệm cũ chưa dọn sạch.

Bật sidecar cho namespace

Linkerd không tự động tiêm proxy vào mọi pod. Cần đánh dấu namespace muốn bật:

kubectl annotate namespace default linkerd.io/inject=enabled

Sau đó, mọi pod mới tạo trong namespace đó sẽ tự động có thêm container linkerd-proxy. Điều dễ nhầm: annotation này chỉ áp dụng cho pod mới. Các pod đang chạy từ trước cần được xoá và tạo lại (hoặc rollout restart deployment) để nhận sidecar.

kubectl rollout restart deployment -n default

Lỗi đầu tiên: pod treo ở trạng thái khởi động

Sau khi bật sidecar, vài pod bị treo lâu ở trạng thái Init. Hoá ra nguyên nhân là container chính của pod cố gắng gọi ra ngoài trước khi linkerd-proxy kịp khởi động xong, và bị chặn vì proxy chưa sẵn sàng nhận traffic.

Cách xử lý là bật proxy-wait-before-exit-seconds và đảm bảo container chính có retry hợp lý khi mới khởi động, thay vì kỳ vọng mọi kết nối đều thành công ngay lập tức.

Điều mình không lường trước: chi phí quan sát dữ liệu

Sau khi mesh chạy ổn định, mình bật dashboard để xem số liệu:

linkerd viz install | kubectl apply -f -
linkerd viz dashboard

Điều bất ngờ không phải là kỹ thuật, mà là mình nhận ra bao nhiêu request nội bộ trước giờ mình chưa từng biết tồn tại. Có vài service gọi qua gọi lại nhau ba, bốn lần cho một request từ người dùng, hoàn toàn không cần thiết. Cái mesh không tạo ra vấn đề đó, nó chỉ làm cái đã luôn ở đó trở nên nhìn thấy được.

Nhìn lại cả series

Ba phần viết xong, điều mình mang về nhiều nhất không phải là biết thêm một công cụ. Đó là hiểu rõ hơn ranh giới giữa việc gì nên xử lý trong code ứng dụng, và việc gì nên đẩy ra hạ tầng. Service mesh không giải quyết vấn đề kiến trúc tệ, nó chỉ khiến những vấn đề đó dễ nhìn thấy hơn để mình còn biết đường mà sửa.