Những gì phỏng vấn xin việc cho tôi biết về Kubernetes

• Kubernetes đang được áp dụng ngay cả ở các công ty nhỏ không phải như một tiêu chuẩn để mở rộng kỹ thuật, mà để giải quyết vấn đề thống nhất cách triển khai và vận hành tổ chức
• Trong quá trình tìm việc gần đây, tất cả các công ty tôi trò chuyện đều đang dùng Kubernetes, khác hẳn với cục diện 5 năm trước khi VM·serverless·K8s cùng tồn tại
• Những lý do cốt lõi mà các CTO nêu ra là có thể triển khai mọi dịch vụ theo cùng một cách, lưu lại tri thức vận hành trong YAML và Helm chart, đồng thời theo dõi lịch sử thay đổi bằng GitOps
• Các công ty nhỏ chấp nhận sự phức tạp của Kubernetes không phải vì các tính năng nâng cao như HPA, Pod Disruption Budget hay node affinity, mà vì lợi ích ở cấp độ tổ chức
• Ở giai đoạn đầu, công ty nên bắt đầu mà không cần Kubernetes để tập trung vào sản phẩm, và nhu cầu áp dụng sẽ tăng lên từ thời điểm CTO không còn là người duy nhất phụ trách kỹ thuật

---

Thay đổi thấy được trong đợt tìm việc gần đây

• Gần đây, trong quá trình tìm việc, sau khi đọc tin tuyển dụng, đi phỏng vấn và trò chuyện với khoảng mười hai đội ngũ kỹ sư, tôi nhận ra rằng mọi công ty tôi nói chuyện cùng đều đang dùng Kubernetes
• Khi tìm việc 5 năm trước, vẫn đồng thời tồn tại nhóm hiếm khi dùng Kubernetes, nhóm dùng systemd trên VM/VPS/EC2, và nhóm serverless như Lambda hay Cloud Run
• Nơi tôi đang làm hiện nay có những bài toán ở quy mô Big Tech nên Kubernetes rõ ràng là phù hợp, nhưng việc ngay cả một startup 10 người chỉ có hai dịch vụ cũng dùng Kubernetes vẫn khiến tôi ngạc nhiên
• Những công ty tôi trò chuyện không vận hành microservices hay ở gần ngưỡng quy mô rất lớn, và họ cũng không đặc biệt quan tâm đến khía cạnh kỹ thuật của Kubernetes

Lý do áp dụng Kubernetes và tiêu chí đánh giá

• Vì sao dùng Kubernetes

  • Lý do đầu tiên là uniformity: nếu mọi dịch vụ đều được triển khai theo cùng một cách, sẽ không còn cảnh chỉ một dịch vụ nào đó bị mắc kẹt với bash script trên bare VM cũ hoặc Docker Compose
  • Lý do thứ hai là tri thức có thể chia sẻ và có thể tuyển dụng được: khi Kubernetes được dùng như một ngôn ngữ chung, chỉ cần nhìn Helm chart và cấu hình Kube là có thể nhanh chóng nắm được kiến trúc
  • Nếu tri thức không nằm trong đầu con người mà được ghi lại trong YAML, thì sau khi ai đó rời đi, người kế nhiệm sẽ ít phải mất vài tuần chỉ để hiểu cách chạy hệ thống hơn
  • Ở công ty hiện tại, đội SRE trực on-call vẫn có thể duy trì cả những dịch vụ chưa từng thấy trước đó vì các mẫu triển khai Kubernetes giữa các nhóm là giống nhau
  • Ưu điểm này chỉ đúng khi cấu hình không trở nên quá khác biệt và kỳ quặc
  • Lý do thứ ba là khả năng truy vết: thay vì chạy trực tiếp kubectl apply -f lên cluster, nếu đưa Helm chart lên git rồi triển khai thông qua phê duyệt MR và FluxCD hoặc ArgoCD thì lịch sử thay đổi sẽ được lưu lại
  • Luồng làm việc này gần như không tốn thêm chi phí nhưng vẫn hỗ trợ compliance, vì GitOps và Kubernetes tự nhiên khớp với nhau
  • Công ty hiện tại của tôi đang vượt qua chứng nhận ISO khá tốt bằng cách này

• Kết luận rút ra

  • Lựa chọn của các CTO không phải là một quyết định ngớ ngẩn, mà là một cách giải quyết vấn đề có thật
  • Kubernetes có vẻ là một lời giải kỹ thuật cho vấn đề kỹ thuật, nhưng nhiều CTO lại quan tâm đến lợi ích phi kỹ thuật nhiều hơn tôi nghĩ
  • Các vấn đề kỹ thuật của những công ty nhỏ thường chưa đến mức nhất thiết phải có Kubernetes, và nhiều khả năng trong manifest của họ sẽ không có topologySpreadConstraints, HPA, Pod Disruption Budget hay các quy tắc node affinity
  • Họ đang chấp nhận chi phí vận hành của một phần mềm phức tạp để đổi lấy lợi ích tổ chức, trong khi vẫn duy trì số lượng node tương tự như khi dùng VM

• Vì sao sự chuyển dịch này xảy ra gần đây

  • Cách đây 5 năm, VM với systemd, serverless và Kubernetes đều vẫn là các lựa chọn; nhưng trong tin tuyển dụng hiện nay, tổ hợp VM và systemd gần như biến mất, serverless vẫn chỉ là ngách, còn Kubernetes đã thắng
  • Lý do của thời điểm chuyển dịch này không hoàn toàn chắc chắn
  • Một khả năng là Kubernetes được quản lý như EKS, GKE, AKS đã trưởng thành hơn, và số người đã học Kubernetes cũng tăng đủ nhiều đến mức tuyển người cho một hướng khác lại trở nên khó hơn
  • Helm cũng biến việc dùng nguyên các chart do người khác tạo thành một lựa chọn thực tế

• Khi nào nên dùng Kubernetes

  • Tiêu chí cá nhân của tôi là thời điểm CTO không còn là kỹ sư duy nhất nữa
  • Khi kỹ sư thứ hai gia nhập, sẽ có người cần triển khai hệ thống dù không phải người trực tiếp thiết lập máy chủ, và lúc đó cần kiểm soát truy cập phù hợp thay vì phát SSH key cho mọi thứ
  • Rồi cuối cùng sẽ có người rời công ty, và tri thức vận hành mà họ nắm giữ cũng có thể biến mất theo
  • Từ thời điểm đó, tri thức cần được lưu lại trong hệ thống chứ không phải trong con người
  • Trước giai đoạn đó, việc debug cluster thật sự khó và có thể khiến năng lượng lẽ ra nên dành cho sản phẩm lại bị tiêu tốn vào hạ tầng
  • So với việc mất hai tiếng để tìm nguyên nhân một pod rơi vào CrashLoopBackOff ngay trước cuộc gọi với khách hàng lớn, thì cách ứng cứu khẩn cấp bằng git pull trên VPS có thể vừa nhanh hơn vừa dễ hiểu hơn

[GN⁺]

Ý kiến trên Lobste.rs

• Ở phía châu Âu, lý do khá rõ ràng. Các CTO tin rằng nếu chạy trên K8s thì có thể đổi nhà cung cấp K8s managed chỉ trong vài tuần
  Không có nghĩa là điều đó đúng, nhưng họ thực sự tin như vậy. Họ cũng cho rằng môi trường PR sẽ dễ hơn
  Nhưng cốt lõi là khả năng chuyển đổi nhà cung cấp. Họ dự đoán trong vài năm tới sẽ xuất hiện lệnh cấm dùng nhà cung cấp có liên hệ với Mỹ, đặc biệt trong GDPR, hệ thống tài chính, v.v. Nên họ chuẩn bị trước cho rủi ro đó

• Đây có vẻ là bằng chứng cho thấy ngành công nghệ đã hoàn toàn lạc hướng, bất kể quy mô công ty. Stack ngày càng đồng nhất và phức tạp hơn, nhưng kết quả là càng khó tìm được sản phẩm và dịch vụ có thể dùng mà không phải nghiến răng chịu đựng

  • Các tầng cấp thấp quá nhiều lỗi và quá phức tạp, nên để sống sót thì cuối cùng cũng buộc phải tạo ra thứ như Kubernetes
    Nếu muốn ngăn stack tiếp tục cao thêm, thì phải làm cho các tầng bên dưới tốt hơn
    Cần những thành phần nền tảng của hệ điều hành tốt hơn nhiều. Ví dụ, container là một mớ trộn lẫn nhiều tính năng cô lập của kernel mà không có thiết kế nhất quán, nên đầy lỗ hổng
    Hiện nay khả năng cô lập của container đã tốt hơn nhiều, nhưng đó là kết quả của việc vá kiểu đập chuột chũi, chứ không phải được thiết kế ngay từ đầu cho bảo mật và tính đúng đắn. Cho đến khi kernel xử lý xong núi nợ kỹ thuật khổng lồ đó, hoặc có ai làm ra một kernel đủ đáng để chuyển sang, chúng ta sẽ vẫn tiếp tục chồng thêm thứ này lên trên nó

• Một công cụ triển khai đủ phức tạp thì rốt cuộc cũng sẽ bao gồm một bản triển khai nửa vời của Kubernetes được dựng tạm, định nghĩa không chính thức, nhiều lỗi và chậm chạp

  • Cách gọi là “nửa vời” thì đúng. Chỉ là cái nửa đó lại chính là cái nửa cần thiết
    Tôi có thể nói rất dài về cách người ta tổ chức một công ty SaaS thương mại điện tử trị giá 1 tỷ đô vào năm 2009, hay cách backend online của một game AAA multiplayer cỡ lớn vận hành, và chúng chắc chắn gần với Kubernetes hơn là triển khai trên một máy đơn
    Nhưng chúng nhanh hơn, và mang tính áp đặt đúng theo nhu cầu thực sự của tổ chức, chứ không phải theo cách xung đột với yêu cầu sản phẩm
    Phần “nhiều lỗi” của Kubernetes thường không nằm ở hệ thống cốt lõi, mà ở vô số lớp giao diện chúng ta chồng lên trên để buộc nó hoạt động theo ý mình
  • Điều này đúng với Erlang, không phải Kubernetes. Với Kubernetes thì hoàn toàn vô nghĩa

• Vấn đề là phần lớn tổ chức triển khai K8s một cách nửa vời, còn lập hẳn đội DevOps để quản lý nó, nhưng cuối cùng vẫn đẩy toàn bộ việc viết, triển khai, debug và vận hành liên quan đến K8s cho kỹ sư phần mềm
  Một đội DevOps giỏi lẽ ra phải cung cấp nội bộ trải nghiệm kiểu Heroku. Bạn chỉ cần định nghĩa tài nguyên cần thiết và merge vào main là quá trình triển khai diễn ra, chứ không phải mò mẫm xem cái gì sai trong một bảng điều khiển GitOps/DevOps tệ hại
  Theo tôi, Heroku từng là đỉnh cao của trải nghiệm lập trình viên, và từ sau K8s thì chúng ta đã đánh mất điều đó

  • Ngoài việc có thể thấy Pod chạy trên node, tôi không rõ có khác biệt lớn nào trong trải nghiệm dùng Heroku và Kubernetes
    Tất nhiên Heroku mang lại trải nghiệm tích hợp hơn cho việc kết nối cơ sở dữ liệu hay triển khai bằng git push, nhưng làm một lớp vỏ tùy biến trên Kubernetes thì không hay lắm. Cuối cùng bạn vẫn phải để lộ nguyên mọi tham số ra ngoài

• Trong ngành này, việc tiếp nhận công nghệ luôn vận hành theo nguyên tắc “thuê như đồ may sẵn, sa thải nếu không cần nữa”. Đây chỉ là ví dụ mới nhất của điều đó

• Câu “tri thức phải nằm trong hệ thống chứ không phải trong con người” diễn đạt rất hay điều tôi vẫn mơ hồ nghĩ đến
  Kiểu hình thức hóa này chỉ khả thi khi mức biến động của quy trình giảm xuống. Con người làm trực tiếp trước, rồi ghi chép quy trình, biến nó thành script, rồi sau đó mới tự động hóa
  Trong các workflow phổ biến của những công cụ hay hệ sinh thái thông dụng, bạn gần như có được phần lớn các bước này gần như miễn phí

• Tôi không làm DevOps nhiều, hiện giờ hệ thống vẫn chạy ổn chỉ với systemd và vài container podman dùng thỉnh thoảng. Tôi làm trong mảng IoT/AgTech
  Bài này có kiểu “khẳng định” mà tôi thường nghe từ các quản lý không chuyên kỹ thuật. Đại loại như “bên kia cũng dùng LoRa đúng không? Vậy là xong chứ? Mai launch được rồi nhỉ?”
  Có một niềm tin rằng sự không đồng nhất là trở ngại duy nhất của thành công. Nếu hai hệ thống dùng Fiber, Modbus, hoặc “có API”, thì người ta cho rằng có thể nối chúng lại ngay và tạo ra một trải nghiệm tuyệt vời kiểu “1 + 1 lớn hơn tổng”
  Nhưng việc hai phần mềm đồng ý ở một tiêu chuẩn tương tác cấp thấp không có nghĩa là công việc thực sự để quyết định phải diễn giải và sử dụng dữ liệu dễ parse đó như thế nào sẽ biến mất
  Hai người nói cùng một ngôn ngữ không có nghĩa là sẽ không còn việc gì phải làm. Việc dùng chung ngôn ngữ cũng không xóa đi những quyết định mà một phần đội ngũ đã đưa ra trong bối cảnh các điều kiện mà họ biết tại thời điểm dùng công cụ đó
  Thời kỳ đầu, trong giới khoa học/kỹ thuật, Fortran từng là ngôn ngữ chung, nhưng điều đó không khiến người ta hết bối rối trước những gì đồng nghiệp đã làm hoặc không còn phải viết lại chúng
  Tôi không có vấn đề gì với giá trị của K8s hay việc nó hiện đã trở thành “tiêu chuẩn”. Chỉ là tôi khó đồng ý với lập luận rằng nhờ vậy một số loại vấn đề lập trình nào đó sẽ biến mất. Định luật bảo toàn sự xấu xí vẫn còn nguyên

• Kubernetes là một nền tảng triển khai khá ổn

• Hình thức phân phối cũng là một lý do khác. Tôi làm việc với node Canton, và phần mềm Canton upstream cùng các ứng dụng liên quan được cung cấp dưới dạng chart Helm
  Bất kể Kubernetes có phù hợp với công việc của chúng tôi hay không, theo tôi là không, thì phần mềm vẫn được phân phối và hỗ trợ theo cách đó. Nếu đi chệch khỏi con đường đó thì khối lượng công việc còn nhiều hơn cả việc xử lý Kubernetes

• Không biết có phải chỉ mình tôi thấy bài này nghe quá giống do AI viết không
  Nhưng tôi vẫn đồng ý với tinh thần của nó. Tôi đang chuyển các cấu hình homelab/self-hosting ra khỏi kiểu thiết lập systemd tùy biến, các lệnh shell chẳng còn nhớ nổi, và trạng thái “chết tiệt, mình đã ghi quy trình cấu hình đó trong file Markdown nào nhỉ?” — cảm giác rất sảng khoái
  Tôi vẫn chưa dùng một hệ thống triển khai liên tục thực thụ, nhưng chỉ cần một script shell apply nhỏ cùng một mớ file YAML là đã thấy yên tâm rằng nếu có thảm họa thì vẫn có thể khôi phục được 90%
  systemd đơn giản về mặt khái niệm nhưng tính tái lập lại phức tạp, còn Kubernetes thì ngược lại. Bạn trả giá khái niệm cao hơn, nhưng đổi lại có tính tái lập và mức độ thấu hiểu đi kèm mạnh hơn nhiều. Ít nhất hiện giờ tôi thấy là vậy
  Tôi vẫn đang ở giai đoạn giữa của việc học Kubernetes, nhưng gần đây dùng nó khá vui

  • Nếu là 10 năm trước thì tôi sẽ đồng ý, nhưng bây giờ với đủ loại tùy chọn namespace và tích hợp người dùng động, systemd cũng bắt đầu giống “một con quái vật khác”
    Kiểu tích hợp dọc với các định nghĩa hạng nhất như thế này có vẻ là đi sai hướng
  • Việc có phải AI viết hay không không quan trọng lắm. Quan trọng là nó được viết tốt hay tệ