Hướng dẫn dành cho những người không thích Kubernetes

Hướng dẫn phê phán về Kubernetes

• Kubernetes đã có danh tiếng là phức tạp một cách không cần thiết và tốn thời gian trong một bộ phận kỹ sư, và việc dùng nó trong các nhóm nhỏ thường bị xem là thiết kế quá mức.
• Tại Jamsocket, sau vài năm vận hành Kubernetes trong môi trường production, họ đã tìm ra cách sử dụng hiệu quả bằng cách chỉ dùng những tính năng cần thiết và bỏ qua phần còn lại.

Vì sao dùng Kubernetes

• Kubernetes là con đường đã được kiểm chứng nhất khi bạn đồng thời muốn cả ba điều sau:
  • Muốn chạy nhiều tiến trình/máy chủ/tác vụ theo lịch.
  • Muốn chạy chúng theo dạng dự phòng và phân tán tải.
  • Muốn cấu hình và mô tả mối quan hệ giữa chúng bằng code.
• Kubernetes là một lớp trừu tượng cho phép đối xử với một cụm máy tính như một máy tính không đầu mối duy nhất.
• Jamsocket triển khai nhiều lần mỗi ngày, và nếu sản phẩm của họ gặp sự cố thì sản phẩm của khách hàng cũng bị ảnh hưởng, nên việc triển khai cuốn chiếu giúp họ có đủ tự tin để triển khai thường xuyên.

Cách họ dùng Kubernetes

• Jamsocket là một dịch vụ tạo ra các tiến trình động có thể giao tiếp với ứng dụng web, tương tự AWS Lambda nhưng vòng đời tiến trình không phụ thuộc vào một lượt request/response duy nhất mà phụ thuộc vào kết nối WebSocket.
• Kubernetes được dùng để vận hành các tiến trình chạy dài hạn như API server, container registry, controller, bộ thu thập log, một số dịch vụ DNS và thu thập metric.
• Những thứ họ không dùng Kubernetes cho: tiến trình tạm thời, site tĩnh/site marketing, và những thứ trực tiếp lưu trữ dữ liệu.
• Họ dùng Google Kubernetes Engine để ủy thác việc quản lý Kubernetes ra bên ngoài, và nếu cần thì việc chuyển sang Amazon EKS cũng tương đối đơn giản.

Các tài nguyên Kubernetes được dùng tích cực

• Deployments: phần lớn pod được tạo thông qua deployment.
• Services: dùng ClusterIP cho dịch vụ nội bộ và LoadBalancer cho dịch vụ bên ngoài.
• CronJobs: dùng cho các script dọn dẹp và tương tự.
• ConfigMaps và Secrets: dùng để truyền dữ liệu vào các tài nguyên ở trên.

Những thứ được dùng một cách thận trọng

• Họ có dùng StatefulSet và PersistentVolumeClaim, nhưng thích lưu dữ liệu quan trọng vào các dịch vụ được quản lý ở bên ngoài Kubernetes hơn.
• Họ tránh RBAC nhiều nhất có thể vì nó làm tăng độ phức tạp.

Những thứ chủ động tránh

• Viết YAML thủ công: họ dùng TypeScript và Pulumi để tạo ra định nghĩa tài nguyên Kubernetes.
• Tài nguyên phi tiêu chuẩn và operator: chúng cho phép phần mềm bên thứ ba sử dụng hạ tầng của Kubernetes, nhưng trên thực tế lại khó dùng.
• Helm: họ không dùng vì operator và các quy ước YAML.
• Mọi thứ có chữ "mesh" trong tên: họ cho rằng không cần thiết.
• Tài nguyên Ingress: họ tránh thêm các tầng gián tiếp không cần thiết.
• Sao chép toàn bộ stack k8s về local: họ dùng Docker Compose hoặc script riêng để chỉ khởi động phần hệ thống cần thiết.

Con người không nên phải chờ Pod

• Kubernetes được thiết kế với trọng tâm là độ bền vững và tính mô-đun hơn là thời gian khởi động container, nên không phù hợp với các trường hợp con người phải chờ pod khởi động.
• Jamsocket dùng Plane, một orchestrator viết bằng Rust theo giấy phép MIT, để lên lịch và chạy tiến trình nhanh cho các workload mang tính tương tác.

Trừu tượng hóa ở cấp cao hơn

• Một số lựa chọn thay thế Kubernetes rất tốt, đặc biệt hữu ích khi bạn không cần mô tả hạ tầng bằng code.
• Có thể chọn các giải pháp khác thay cho Kubernetes bằng cách dùng những dịch vụ như Railway, Render hoặc Flight Control.
• Nếu bạn quản lý cách tiếp cận Kubernetes một cách có hệ thống, sẽ không ai có thể nói là bạn bắt đầu quá sớm.

Ý kiến của GN⁺

• Kubernetes là công cụ mạnh mẽ cho quản lý độ phức tạp và tự động hóa, đặc biệt trong các hệ thống quy mô lớn, nhưng chính độ phức tạp đó có thể trở thành gánh nặng với các dự án nhỏ hoặc startup.
• Bài viết này đưa ra cách tránh sự phức tạp quá mức có thể phát sinh khi dùng Kubernetes, từ đó giúp người mới hoặc các nhóm nhỏ vẫn có thể tận dụng lợi ích của Kubernetes.
• Trước khi dùng Kubernetes, cần cân nhắc kỹ các tính năng thực sự cần thiết và năng lực kỹ thuật của đội ngũ để đánh giá lợi ích so với độ phức tạp và chi phí quản lý.
• Thay vì Kubernetes, việc dùng các dịch vụ đơn giản và dễ quản lý hơn có thể là lựa chọn tốt hơn. Ví dụ như Docker Swarm, Apache Mesos, Nomad, mỗi giải pháp đều có ưu và nhược điểm riêng.
• Khi áp dụng Kubernetes, cần xem xét việc tích hợp với hạ tầng hiện có, bảo mật, chi phí quản trị và đường cong học tập.
• Những lợi ích có được khi chọn Kubernetes là khả năng mở rộng, tính sẵn sàng cao và trải nghiệm triển khai nhất quán trên nhiều môi trường đám mây. Tuy nhiên, điều đó đòi hỏi phải hiểu về quản lý tài nguyên và orchestration cần thiết.

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  • Khi áp dụng một hệ thống phức tạp như Kubernetes, độ phức tạp đó tiếp tục mở rộng, khiến nhiều thành phần khác nhau củng cố lẫn nhau và dần được xem là thiết yếu.
  • Khi cloud mới xuất hiện, mọi người bị thu hút bởi việc giảm bớt sự phức tạp trong cân bằng tải và quản lý cơ sở dữ liệu.
  • Máy chủ ứng dụng không trạng thái (stateless) vốn không phải là vấn đề lớn về bảo trì, nhưng việc truyền bá microservices lại tạo ra những vấn đề vốn trước đây không tồn tại.
  • Giờ đây văn hóa này đã ăn sâu, khiến việc đơn giản gật đầu đồng ý với lập luận rằng microservices là bắt buộc trở nên khó khăn.

• Tóm tắt bình luận thứ hai:

  • Với tư cách là người triển khai Kubernetes tại các doanh nghiệp vừa và nhỏ, có một số kỹ sư không hài lòng, nhưng đa số trả lời rằng họ hài lòng.
  • Kubernetes phức tạp, nhưng đó là công cụ phù hợp cho những vấn đề phức tạp.
  • Có một tiêu chuẩn vẫn tốt hơn sự hỗn loạn giản đơn nhưng không được ghi chép, và người này cho rằng "kubectl explain X" tốt hơn tài liệu AWS rất nhiều.
  • Kubernetes tuy phức tạp, nhưng nó hoạt động giống cách mà các lập trình viên đã dùng ở công ty trước, và tốc độ là điều quan trọng.

• Tóm tắt bình luận thứ ba:

  • Việc chỉ trích Kubernetes đang là xu hướng, nhưng nó vẫn là giải pháp tốt nhất.
  • Nó cho phép định nghĩa hạ tầng theo kiểu khai báo, đồng thời cung cấp cân bằng tải, tự phục hồi và tự động mở rộng.
  • Nó mang lại khả năng quan sát rất tốt cho toàn bộ stack, và có thể sử dụng nhiều phần mềm được đóng gói sẵn.
  • Có thể xây dựng gần như cùng một hạ tầng trên cloud, máy chủ riêng và môi trường cục bộ, nên không bị phụ thuộc vào một nhà cung cấp cloud cụ thể.

• Tóm tắt bình luận thứ tư:

  • Lợi ích lớn của Kubernetes là Helm hoặc Operators.
  • Nếu đã phải trả giá cho độ phức tạp, thì cũng nên nhận được lợi ích của một "app store" cho các thành phần hạ tầng và khả năng quản lý vận hành theo cách lập trình được.
  • Ví dụ, nếu cần thiết lập một thứ phức tạp như Ceph thì Rook là một cách tốt.
  • Helm hoặc Operators không biến hạ tầng thành các thiết bị managed kiểu "turnkey", nhưng giao diện khai báo nhìn chung vẫn dễ quản lý hơn.

• Tóm tắt bình luận thứ năm:

  • Kubernetes là công nghệ tốt, nhưng vì độ phức tạp mà những người bảo trì thường có xu hướng trở thành anh hùng trong công ty.
  • Nhiều tinh chỉnh và cần gạt có thể khiến người ta chệch khỏi mục tiêu thực sự của dự án.

• Tóm tắt bình luận thứ sáu:

  • Công ty hiện tại đang chia thành hai hướng: Kubernetes và một hệ thống triển khai tùy chỉnh dựa trên Ansible.
  • Cách làm với Ansible hoạt động tốt, nhưng nếu chuyển sang Kubernetes thì có thể rút ngắn thời gian triển khai từ vài giờ xuống vài phút, đồng thời tự động mở rộng nhanh hơn và hiệu quả hơn.
  • Những phản hồi nhất quán từng nghe từ các nhóm đi trước là khó xác định nguyên nhân khi triển khai Helm thất bại, và cần học một cách vận hành mới.

• Tóm tắt bình luận thứ bảy:

  • Trong cuộc trò chuyện với một cựu kỹ sư độ tin cậy trang web của Google, người này nói rằng số công ty thực sự cần Kubernetes là rất ít.
  • Nhiều người có xu hướng phát triển theo trào lưu.

• Tóm tắt bình luận thứ tám:

  • Kubernetes có thể là công cụ phù hợp, nhưng nên được chấp nhận như một cái ác cần thiết.
  • Phần mềm có khả năng thất bại trong hợp tác do lỗi từ nhiều bên thường dễ gây ra vấn đề.

• Tóm tắt bình luận thứ chín:

  • Việc tự viết YAML có thể là vấn đề, nên thay vào đó họ dùng TypeScript và Pulumi để tạo định nghĩa tài nguyên Kubernetes.
  • Thay vì lint YAML, họ đưa vào cả runtime của một ngôn ngữ lập trình hoàn chỉnh cùng thư viện bên thứ ba, đồng thời chấp nhận thêm độ phức tạp như quản lý phiên bản và biên dịch dự án.

• Tóm tắt bình luận thứ mười:

  • Với tư cách là người từng rất nhiệt tình với Kubernetes, phần tốt của Kubernetes là các thành phần cơ bản như deployments, services, configmaps, còn phần còn lại chỉ nên dùng trong những trường hợp đặc biệt.
  • Nhóm thích viết YAML thuần và dùng kustomize để giữ cấu hình rõ ràng, minh bạch.