Một người hoài nghi lần đầu tiếp cận Kubernetes: Góc nhìn từ bên trong

Có những kỹ sư hạ tầng dành cả sự nghiệp để tránh Kubernetes, và tác giả bài viết này là một ví dụ điển hình. Sau nhiều năm làm quản trị hệ thống và phát triển hạ tầng, ông quyết định đối diện với định kiến của chính mình để xem liệu nó có cơ sở hay không.

Kết quả là một bài phân tích thẳng thắn: các khái niệm của Kubernetes thực sự hợp lý, đặc biệt là mô hình mạng của Service và mẫu Controller, nhưng vẫn còn đó những điểm khiến người ta phải đặt câu hỏi.

Sơ đồ các khái niệm cơ bản trong Kubernetes

Vì sao tác giả tránh Kubernetes?

Không phải ngẫu nhiên mà tác giả né tránh nền tảng này. Công việc của ông đòi hỏi kiểm soát cực kỳ chặt chẽ vị trí vật lý của từng workload — điều mà một hệ thống điều phối tự động khó đáp ứng. Dần dần, ông hình thành góc nhìn hoài nghi với Kubernetes, nhưng thừa nhận rằng cơ sở của nó khá mơ hồ: chỉ là cảm giác "một cách làm mới" và "phức tạp không cần thiết".

Bài viết này là nỗ lực thay thế định kiến bằng sự thật. Tác giả cho rằng các tài liệu hướng dẫn hiện có thường mô tả thành phần làm gì mà bỏ qua lý do phía sau và những đánh đổi đi kèm.

Những mảnh ghép cơ bản

Theo cách mô tả "chuẩn mực", Kubernetes cho phép bạn chạy workload tùy ý và cung cấp khả năng khai báo yêu cầu tài nguyên (CPU, ổ đĩa, bộ nhớ, số lượng bản sao), tự động mở rộng quy mô, chọn máy chủ chạy ứng dụng, "tự chữa lành" khi instance gặp sự cố, và công bố dịch vụ để các thành phần khác tìm thấy nhau qua DNS. Tất cả chỉ với điều kiện bạn đóng gói workload thành Docker image.

Các khối xây dựng nên một cluster gồm:

• Pod: đơn vị công việc, gồm một tập Docker image và cấu hình của chúng
• Node: máy tính chạy agent của Kubernetes (kubelet), nơi thực thi các Pod
• Cluster: tập hợp logic các Node cùng Control Plane
• Service: nhóm logic của một tập Pod
• Namespace: phân vùng logic của Cluster, tạo phạm vi tên giống như miền tìm kiếm DNS

Tuy nhiên, theo tác giả, cách giải thích này chẳng có gì đặc biệt — nhiều nền tảng hạ tầng khác cũng trông na ná như vậy.

Hai khái niệm làm nên giá trị thực sự

Tác giả cho rằng phần lớn giá trị của Kubernetes đến từ hai ý tưởng: vòng lặp điều khiển (control loop) và Service.

Vòng lặp điều khiển

Workload được quản lý bởi các vòng lặp điều khiển gọi là Controller. Một vòng lặp sẽ liên tục quan sát các biến cụ thể (qua sensor) và thực hiện hành động (qua control element) nếu cần, nhằm đạt được trạng thái mong muốn. Điểm thú vị là control element không nhất thiết phải tác động trực tiếp lên thứ mà sensor quan sát.

Ví dụ:

• Xử lý sự kiện từ hàng đợi: trạng thái mong muốn là hàng đợi rỗng, sensor là độ sâu hàng đợi, control element là số lượng máy chủ xử lý sự kiện
• Mở rộng theo tải người dùng: trạng thái mong muốn là giữ độ trễ P90 dưới X ms, sensor là số liệu đo độ trễ từ backend, control element là tạo thêm Pod
• Giám sát sức khỏe tổng quát: trạng thái mong muốn là mọi Node khỏe mạnh, control element là loại bỏ Node khỏi cluster

Mô hình hàng đợi và controller

Service và mô hình mạng

Service là khái niệm ở tầng mạng, cung cấp truy cập ổn định tới một tập Pod phía sau. Nó mang lại danh tính ổn định (địa chỉ IP ảo và bản ghi DNS không đổi), cân bằng tải, và khả năng khám phá dịch vụ.

So với cluster "cổ điển", Service tương đương với sự kết hợp của N máy chủ chạy Keepalived và NGINX (với tập backend động), cùng các bản ghi CNAME trỏ tới IP ảo.

Cơ chế hoạt động đáng chú ý: mỗi khi một Service mới được tạo, nó nhận một IP ảo, và mọi Node đều cập nhật cấu hình mạng (netfilter) để chuyển tiếp gói tin đến IP ảo đó về phía các Pod phía sau. Việc cập nhật do một Controller chạy trên từng Node đảm nhận, tên là kube-proxy.

Thiết kế này khiến mọi Node đều đóng vai trò bộ cân bằng tải, loại bỏ điểm hỏng đơn lẻ trong việc chuyển tiếp lưu lượng, và năng lực chuyển tiếp tăng theo quy mô cluster. Đổi lại, mỗi Node nhận luật cho toàn bộ Service, dẫn đến số lượng luật có thể rất lớn — điều này gây khó khăn cho những cách triển khai đánh giá luật tuyến tính như iptables. Lưu lượng đôi khi bị chuyển tiếp nhiều lần, tăng độ sẵn sàng nhưng cũng tăng tải cho cluster.

Hành trình gói tin từ Pod 1 đến Service 1

Quản lý workload: chạy cái gì, khi nào và ở đâu

Bạn có thể tạo Pod thủ công bằng một tệp YAML, nhưng làm vậy nghĩa là bạn tự lên lịch chạy nó đúng một lần. Cách này dễ nhưng có hạn chế nghiêm trọng: nếu Node chứa Pod chết, Pod không được lên lịch lại; nếu Pod bị đẩy ra do áp lực tài nguyên (eviction), nó cũng biến mất; và bạn không thể nói "giờ tôi muốn có 2 cái như thế".

ReplicaSet giải quyết vấn đề này: nó là một Controller đảm bảo đúng số lượng bản sao Pod luôn chạy. Nhưng ReplicaSet chỉ cho phép thay đổi số bản sao — muốn đổi phiên bản nginx hay mở thêm cổng thì phải xóa và tạo lại tài nguyên.

Deployment khắc phục hạn chế trên. Nó đảm bảo cuối cùng sẽ có đúng số Pod với đúng image đang chạy. Chữ "cuối cùng" rất quan trọng: khi bạn cập nhật Deployment, nó tạo ReplicaSet mới, tăng dần quy mô trong khi thu nhỏ ReplicaSet cũ, nhờ đó hỗ trợ cập nhật cuốn chiếu (rolling update).

Lưu trữ: dữ liệu tồn tại và di chuyển thế nào

Mặc định, các container trong cùng một Pod không chia sẻ ổ đĩa. Nếu cần chia sẻ, bạn dùng Ephemeral Volume — vòng đời gắn liền với Pod, dữ liệu mất khi Pod tắt. Loại này hữu ích cho việc đẩy log từ sidecar hay nạp sẵn cache cho ứng dụng chính.

Muốn lưu trữ thực sự bền vững, bạn dùng Persistent Volume, có vòng đời tách rời khỏi Pod. Bạn khai báo nó qua một PersistentVolumeClaim rồi gắn vào Pod.

Một số điểm đáng lưu ý:

• Nhiều Pod dùng chung một Claim sẽ chia sẻ dữ liệu — khá rủi ro nếu có nhiều nguồn ghi
• PersistentVolume có thể được cung cấp bởi nhiều driver khác nhau (NFS, SMB, iSCSI...), nhưng Pod không biết driver nào đang chạy, nên không thể dựa vào các tính năng đặc thù như đổi tên nguyên tử
• Muốn có lưu trữ bền vững riêng cho từng instance, bạn dùng StatefulSet, gói gọn trong một tài nguyên: workload, số bản sao, cấu hình gắn kết và mẫu khai báo volume

StatefulSet có các Pod mang hostname ổn định (nginx-0, nginx-1...), và việc triển khai diễn ra theo thứ tự: tạo Pod theo thứ tự tăng dần, xóa và cập nhật theo thứ tự giảm dần. Tác giả thấy điểm này kỳ lạ và không tin lắm vào lời giải thích rằng các instance số nhỏ là "nòng cốt" hay "ổn định hơn" — vì một Pod hay bị crash đâu có được đánh số lại.

Bảng điểm tổng kết

Sau khi tìm hiểu vòng lặp điều khiển, Service, workload và lưu trữ, tác giả đã có được quan điểm ít định kiến hơn. Ông đánh giá các khái niệm rất hợp lý, đặc biệt ấn tượng với Service (kể cả mô hình mạng và kube-proxy), và cho rằng duy trì mẫu Controller làm động cơ quản lý tài nguyên là hướng đi đúng đắn.

Nhưng vẫn còn những câu hỏi mở:

• Tài liệu Controller nói rằng cluster có thể không bao giờ đạt trạng thái ổn định và điều đó không quan trọng — tác giả phản biện: nếu đang vận hành cluster không thể ổn định thì lẽ ra phải biết ngay lập tức
• Với mẫu Controller, tại sao không có hỗ trợ cho kiến trúc "cloud native"? Ví dụ một ReplicaSet tự mở rộng dựa trên độ sâu hàng đợi chia cho 16, và các interface chuẩn cho những sự kiện như số kết nối hay độ trễ phản hồi
• Tại sao phần triển khai lưu trữ và mạng lại nằm "ngoài cây" (CNI/CSI), trong khi nhà cung cấp cloud lại được hỗ trợ tường minh?

Và một lời phàn nàn về kiểu chuỗi

Phần sôi nổi nhất của bài viết dành cho thói quen dùng nội suy chuỗi (text interpolation) trong hệ sinh thái Kubernetes. Tác giả dẫn ví dụ một bộ mở rộng cho RabbitMQ của KEDA (do Microsoft bảo trì), nơi kiểu dữ liệu của một trường phụ thuộc vào giá trị của trường khác, và trường đó lại là chuỗi trong khi đáng lẽ phải là enum.

Ông cũng đặt câu hỏi về sự phổ biến của Helm: tại sao phải tạo ra YAML — một ngôn ngữ có cấu trúc — bằng cách dùng máy tính thêm thủ công từng khoảng trắng để cú pháp hợp lệ? Lẽ ra không nên tồn tại tầng biểu diễn trung gian bằng mẫu văn bản như vậy.

Dù vậy, bài viết vẫn là lời mời gọi đáng giá: hãy đánh giá Kubernetes bằng hiểu biết thực sự, chứ không phải bằng định kiến.