Những bài học từ các buổi phỏng vấn về sự thống trị của Kubernetes

Những bài học từ các buổi phỏng vấn về sự thống trị của Kubernetes

Gần đây, tôi đang trong quá trình tìm kiếm cơ hội việc làm mới. Việc đọc các tin tuyển dụng, tham gia phỏng vấn và trò chuyện với các đội ngũ kỹ thuật tại khoảng một chục công ty đã giúp tôi nhận ra một điều thú vị. So với cách đây 5 năm, lần cuối tôi đi xin việc, bối cảnh hiện tại đã thay đổi hoàn toàn: tất cả mọi người đều đang sử dụng Kubernetes. Mọi công ty tôi tiếp xúc đều vậy.

Lần trước tôi săn việc, tình hình hoàn toàn khác biệt. Khi đó, thị trường chia làm ba phe phái rõ rệt: những người áp dụng Kubernetes hiếm hoi, nhóm dùng systemd trên VM/VPS/EC2, và những người ủng hộ serverless (như Lambda, Cloud Run, v.v.).

Điều này thực sự khiến tôi ngạc nhiên. Tại nơi tôi đang làm, chúng tôi đối mặt với những vấn đề ở quy mô của Big Tech, nên việc dùng K8s là hoàn toàn hợp lý. Nhưng một startup chỉ có 10 người với hai dịch vụ thì sao? Không một nơi nào trong số đó đang làm microservices hay gặp phải vấn đề về độ mở rộng quy mô (high scale). Vì vậy, tôi đã đặt câu hỏi "Tại sao?".

Spoiler: Họ không thực sự quan tâm nhiều đến khía cạnh kỹ thuật của K8s.

Tại sao lại như vậy?

Buổi phỏng vấn kỹ thuật thực sự là một nơi tuyệt vời để hỏi "tại sao", đặc biệt là khi bạn đang nói chuyện trực tiếp với CTO. Và tôi đã làm vậy. Câu trả lời về cơ bản là giống nhau ở khắp mọi nơi.

Tính đồng nhất

Lý do đầu tiên là sự đồng nhất. Mọi dịch vụ đều được triển khai theo cùng một cách. Không còn tình trạng bí mật rằng dịch vụ thanh toán chạy trên một máy chủ ảo (bare VM) với một đoạn bash script "nguyền rủa" từ năm 2019, trong khi API lại chạy trên Docker Compose vì chẳng ai đụng vào nó cả. Chỉ có một cách duy nhất để triển khai mọi thứ.

Kiến thức chuẩn hóa

Lý do thứ hai là kiến thức chia sẻ và dễ tuyển dụng. K8s về cơ bản đã trở thành một ngôn ngữ chung (lingua franca). Ngày đầu tiên làm việc tại công ty hiện tại, tôi đã kéo repo chứa các Helm chart và cấu hình Kube, và chỉ trong vòng một giờ tôi đã nắm rõ toàn bộ kiến trúc. Kiến thức nằm trong YAML, không bị kẹt trong đầu ai cả. Nếu mất một người, người thay thế không phải mất ba tuần để lục lọi tài liệu nhằm tìm hiểu cách hệ thống vận hành.

Tại công ty hiện tại của tôi, các kỹ sư SRE trực ca có thể giữ cho bất kỳ dịch vụ nào hoạt động ổn định ngay cả khi họ chưa từng chạm vào nó trước đó. Họ biết Kubernetes, và các mẫu của Kubernetes là giống nhau ở mọi nơi cho tất cả các đội. Hãy thử làm điều đó với một loạt máy chủ ảo nơi mỗi dịch vụ được thiết lập một cách khác nhau xem sao. (Tất nhiên, điều này chỉ đúng nếu không ai đi theo hướng thiết lập quá lạ lẫm).

Truy xuất ai làm gì

Lý do thứ ba là khả năng truy xuất (có hoặc không có yêu cầu tuân thủ). Tại công ty tôi, không ai có thể lén lút chạy lệnh kubectl apply -f thẳng vào cụm cluster. Bạn đẩy Helm chart lên git, có dấu vết, có quy trình phê duyệt MR (Merge Request), sau đó FluxCD hoặc ArgoCD sẽ xử lý việc triển khai thực tế. Không có gì diễn ra trong bóng tối. Điều này kết hợp rất tốt với các yêu cầu tuân thủ: về cơ bản đó là cách chúng tôi đạt được các chứng nhận ISO. Và vì GitOps kết hợp tự nhiên với Kubernetes, bạn nhận được tất cả những thứ đó gần như miễn phí.

Tôi rút ra bài học gì từ đây

Các CTO mà tôi nói chuyện không đang đưa ra một lựa chọn sai lầm. Họ đang giải quyết các vấn đề thực tế.

Tôi trước đây chỉ tập trung vào khía cạnh kỹ thuật, và với tôi, Kube luôn là giải pháp kỹ thuật cho các vấn đề kỹ thuật. Nhưng có vẻ như nhiều CTO quan tâm chủ yếu đến các lợi ích phi kỹ thuật. Nhiều hơn những gì tôi nghĩ. Các vấn đề kỹ thuật của họ thực sự không đòi hỏi phải dùng K8s. Tôi cá là bạn sẽ không tìm thấy topologySpreadConstraints trong manifest của họ, họ không quan tâm. Không HPA (Horizontal Pod Autoscaler), không Pod Disruption Budgets, không quy tắc node affinity. Chỉ là số lượng node giống như số lượng VM họ sẽ dùng thôi. Nhưng họ chấp nhận trả giá cho một phần mềm phức tạp để đổi lấy lợi ích về mặt tổ chức.

Thành thật mà nói, tôi nghĩ điều này chủ yếu là ổn. Nhưng tôi vẫn nghĩ rằng hầu hết các công ty nên bắt đầu mà không cần nó. Các cụm cluster thực sự rất khó gỡ lỗi khi có sự cố, và ở giai đoạn đó bạn muốn dồn năng lượng vào sản phẩm, không phải hạ tầng. Khi bạn đang thuyết phục khách hàng lớn tiếp theo, việc bật một VPS lên và làm một lệnh git pull bừa bãi là một cách sửa lỗi khẩn cấp hoàn toàn hợp lệ. Chưa tối ưu, chắc chắn. Nhưng nhanh, và bạn biết chính xác điều gì đang xảy ra. Bạn thực sự không muốn dành hai giờ để tìm hiểu tại sao pod của bạn lại bị kẹt trong trạng thái CrashLoopBackOff ngay trước cuộc gọi với khách hàng.

Tại sao sự thay đổi này lại xảy ra gần đây?

Tôi vẫn không hoàn toàn hiểu tại sao sự chuyển dịch này lại diễn ra đúng vào thời điểm này. Năm năm trước, cả ba phe phái đều sống tốt. Bây giờ, đám đông VM+systemd cơ bản đã biến mất khỏi các tin tuyển dụng, serverless vẫn ngách, và K8s đã chiến thắng.

Lời đoán tốt nhất của tôi: các dịch vụ K8s được quản lý (như EKS, GKE, AKS) đã trở nên trưởng thành và nguồn nhân lực đã đảo chiều: đủ nhiều người đã học nó khiến việc tuyển dụng cho bất kỳ công nghệ nào khác trở thành lựa chọn khó khăn hơn. Và Helm đã biến việc "chỉ dùng chart của người khác" thành một lựa chọn thực sự. Nhưng tôi không chắc chắn. Nếu bạn đã trải qua sự thay đổi này và có lý thuyết tốt hơn, tôi thực sự muốn biết.

Khi nào nên sử dụng Kubernetes

Ngưỡng cá nhân của tôi sẽ là thời điểm CTO không còn là kỹ sư duy nhất nữa. Ngay khi người thứ hai xuất hiện, các vấn đề mà K8s giải quyết sẽ trở nên thực tế. Bây giờ bạn có người không thiết lập máy chủ nhưng cần triển khai code. Người cần quyền kiểm soát truy cập phù hợp, không phải các khóa SSH cho mọi thứ. Người sẽ rời đi cuối cùng và mang theo tất cả những gì họ biết. Đó là lúc bạn muốn hệ thống nắm giữ kiến thức, không phải con người.