Cộng đồng Kubernetes đang sôi nổi với các cuộc thảo luận về việc một phiên bản 2.0 giả định sẽ trông như thế nào, với các nhà phát triển và kỹ sư chia sẻ những bức xúc và danh sách mong muốn của họ cho nền tảng điều phối container phổ biến này. Trong khi bài viết gốc đề xuất các thay đổi nhận được phản ứng trái chiều do cách trình bày không rõ ràng, phản hồi từ cộng đồng đã khơi dậy những cuộc trò chuyện có ý nghĩa về các hạn chế hiện tại và hướng phát triển tương lai của Kubernetes.
Cuộc chiến ngôn ngữ cấu hình: YAML vs HCL vs mọi thứ khác
Một trong những cuộc tranh luận nóng nhất xoay quanh việc thay thế YAML bằng HashiCorp Configuration Language ( HCL ). Một số nhà phát triển hào hứng với khả năng này, đặc biệt là những người đã sử dụng Terraform và đánh giá cao tính an toàn kiểu dữ liệu và cấu trúc của HCL. Tuy nhiên, cộng đồng chia rẽ sâu sắc về vấn đề này. Nhiều nhà phát triển thấy HCL khó hiểu và khó đọc, với những lo ngại về việc gỡ lỗi và hỗ trợ import. Các đề xuất thay thế bao gồm sử dụng Protocol Buffers hoặc các ngôn ngữ định nghĩa giao diện khác cho phép người dùng chỉ định cấu hình bằng ngôn ngữ lập trình ưa thích của họ.
Cuộc thảo luận này tiết lộ một sự bức xúc rộng lớn hơn với việc quản lý cấu hình trong Kubernetes. Nhiều người dùng đã tìm cách khắc phục các hạn chế của YAML bằng cách sử dụng các công cụ như Terraform để quản lý toàn bộ cơ sở hạ tầng Kubernetes của họ, coi YAML như một biểu diễn trung gian thay vì thứ họ viết trực tiếp.
Các tính năng Kubernetes 2.0 được đề xuất từ thảo luận cộng đồng:
- Thay thế YAML bằng HCL ( HashiCorp Configuration Language ) để cấu hình
- Triển khai các API dựa trên gRPC/Protocol Buffer để hỗ trợ đa ngôn ngữ tốt hơn
- Thay thế etcd bằng PostgreSQL hoặc các backend lưu trữ có thể cắm thêm khác
- Thêm hỗ trợ IPv6 nguyên bản trên toàn bộ nền tảng
- Bao gồm "các cài đặt mặc định hợp lý" cho mạng, lưu trữ và cân bằng tải
- Cải thiện quản lý gói để thay thế hệ thống Go templating của Helm
- Thêm hỗ trợ WebAssembly ( WASM ) cho các workload
- Triển khai hỗ trợ user namespace ( userns ) tốt hơn theo mặc định
Lưu trữ và đơn giản hóa: Những điểm đau dai dẳng
Một chủ đề lặp lại trong các cuộc thảo luận cộng đồng là độ phức tạp của Kubernetes, đặc biệt xung quanh lưu trữ và mạng. Nhiều kỹ sư báo cáo rằng trong khi Kubernetes hoạt động tốt cho các ứng dụng không trạng thái, việc quản lý lưu trữ bền vững vẫn còn nhiều vấn đề. Cộng đồng đề xuất rằng Kubernetes 2.0 nên bao gồm các cài đặt mặc định hợp lý cho load balancer, mạng và lưu trữ, thay vì buộc người dùng phải ghép nối các giải pháp từ nhiều nhà cung cấp khác nhau.
Hiện tại việc chạy K8S trên bất cứ thứ gì khác ngoài các nhà cung cấp cloud và đồ chơi là thảm họa chờ xảy ra trừ khi bạn là một kỹ sư cơ sở hạ tầng thực sự dày dạn kinh nghiệm.
Vấn đề phức tạp này mở rộng ra ngoài lưu trữ. Một số thành viên cộng đồng lập luận rằng Kubernetes đã trở nên quá giàu tính năng, cố gắng hỗ trợ mong muốn và nhu cầu của mọi người trong nền tảng cốt lõi, dẫn đến sự phức tạp không cần thiết cho hầu hết người dùng.
Các Điểm Đau Của Cộng Đồng Với Kubernetes Hiện Tại:
- Quản Lý Lưu Trữ: Lưu trữ bền vững vẫn phức tạp và có vấn đề, đặc biệt đối với các triển khai tại chỗ
- Độ Phức Tạp Cấu Hình: Templating YAML với Helm khó debug và bảo trì
- Thiết Lập Mạng: Thiết kế mạng tập trung vào IPv4 không tận dụng được các ưu điểm của IPv6
- Quản Lý Package: Go templates của Helm tạo ra các tình huống lỗi khó hiểu
- Đường Cong Học Tập: Yêu cầu các đội ngũ kỹ thuật chuyên dụng (ước tính 3+ kỹ sư với chi phí 1 triệu USD hàng năm) cho các triển khai production
- Bị Khóa Với Nhà Cung Cấp Cloud: Cách tiếp cận "pin không đi kèm" đẩy người dùng về phía các dịch vụ đắt đỏ của nhà cung cấp cloud
Cải tiến cơ sở hạ tầng kỹ thuật
Cộng đồng đã xác định một số cải tiến kỹ thuật cho một Kubernetes 2.0 tiềm năng. Những cải tiến này bao gồm thay thế etcd bằng PostgreSQL hoặc các backend lưu trữ có thể cắm thêm khác, triển khai các API dựa trên gRPC để hỗ trợ đa ngôn ngữ tốt hơn, và thêm hỗ trợ IPv6 thích hợp ngay từ đầu. Nhiều người dùng cũng muốn có hệ thống quản lý gói tốt hơn để thay thế Helm, công cụ bị chỉ trích rộng rãi vì hệ thống template Go và khó khăn trong việc gỡ lỗi.
Thú vị là, một số thành viên cộng đồng đề xuất rằng giải pháp không nhất thiết phải là một cuộc viết lại hoàn toàn, mà là các công cụ và lớp trừu tượng tốt hơn được xây dựng trên nền tảng Kubernetes hiện có.
 |
|---|
| Ảnh chụp màn hình từ Artifact Hub này minh họa các tài nguyên liên quan đến quản lý gói, làm nổi bật nhu cầu về công cụ tốt hơn trong các cuộc thảo luận về Kubernetes 20 |
Thách thức tương thích ngược
Có lẽ cái nhìn sâu sắc nhất từ cuộc thảo luận cộng đồng là thách thức về tương thích ngược. Như một kỹ sư đã lưu ý, việc tạo ra một phiên bản 2.0 với đủ tương thích ngược để áp dụng từng bước trong khi làm cho hệ thống đơn giản hơn là cực kỳ khó khăn. Tương thích ngược thường tăng độ phức tạp vì các hệ thống mới phải xử lý cả cách tiếp cận cũ và mới.
Điều này đã khiến một số thành viên cộng đồng lập luận rằng những gì Kubernetes thực sự cần không phải là những thay đổi cách mạng, mà là một thành tích ổn định và đơn giản kéo dài một thập kỷ. Trọng tâm nên là giảm khả năng người dùng tạo ra các cấu hình phức tạp, khó bảo trì thay vì thêm các tính năng mới.
Sự đồng thuận của cộng đồng dường như là trong khi Kubernetes có chỗ để cải thiện, bất kỳ thay đổi lớn nào cũng phải cân bằng cẩn thận giữa đổi mới và nhu cầu thực tế của những người dùng hiện tại đã xây dựng cơ sở hạ tầng của họ xung quanh hệ thống hiện tại.
Tham khảo: What Would A Kubernetes 2.0 Look Like