Bạn thân mến, bạn đã tạo ra Kubernetes

• Lá thư gửi người bạn

  • Nội dung giải thích rằng dù đã cố tránh Kubernetes, cuối cùng vẫn tạo ra một hệ thống tương tự.
  • Người bạn đã chọn "công nghệ nhàm chán" và muốn chạy container một cách đơn giản, nhưng cuối cùng lại gặp vấn đề vì các script và cấu hình phức tạp.
  • Ngay cả khi chuyển sang Docker Compose, vẫn không thể giải quyết mọi vấn đề, và nhận ra rằng cần các giải pháp riêng cho triển khai, rolling update, rollback và scaling.

• Mở rộng máy chủ và độ phức tạp của mạng

  • Bắt đầu cảm thấy cần phải mở rộng sang máy chủ thứ hai.
  • Thử dùng mạng overlay như Tailscale để thực hiện service discovery.
  • Cố gắng giải quyết độ phức tạp của mạng, nhưng cuối cùng lại phải đối mặt với nhiều vấn đề hơn.

• Bảo trì và tự động hóa

  • Nảy sinh câu hỏi: nếu người tạo ra các script đi nghỉ phép hoặc nghỉ việc, ai sẽ quản lý cấu hình phức tạp và những thay đổi cấu hình không được tài liệu hóa?
  • Để giải quyết vấn đề bảo trì của các script tùy chỉnh, sử dụng Ansible để biến VM thành bất biến và có thể quản lý phiên bản.
  • Nghĩ rằng vì không dùng Kubernetes nên việc bảo trì sẽ dễ hơn.

• Sinh container và vấn đề bảo mật

  • Xuất hiện yêu cầu phải tạo các container khác một cách lập trình.
  • Việc mount Docker socket vào web app là rủi ro về bảo mật, nên đã viết một dịch vụ riêng để giải quyết.
    • Vấn đề được giải quyết bằng cách viết một dịch vụ riêng chỉ phơi bày phần an toàn của Docker API.

• Kết luận

  • Cuối cùng nhận ra rằng mình đã xây dựng một hệ thống tương tự Kubernetes.
    • Hoàn thiện một hệ thống phức tạp bao gồm định dạng cấu hình chuẩn, phương thức triển khai, mạng overlay, service discovery, node bất biến và API server

• PS

  • Điều này không phủ nhận khả năng tồn tại một giải pháp tốt hơn để thay thế Kubernetes.
  • Tuy nhiên, trước khi khẳng định Kubernetes là phức tạp, tác giả khuyên nên hiểu đầy đủ những vấn đề mà nó đang cố giải quyết.

[savvykang]

Mình thật sự không hiểu câu chuyện áp dụng Kubernetes để giải quyết việc bàn giao triển khai.

[kandk]

Việc bảo trì và tự động hóa có thể được thực hiện dễ dàng ở cấp độ code.
Infra as code cũng khả thi.

[savvykang]

Trong môi trường dịch vụ k8s được quản lý như EKS thì có cả load balancer và có thể tích hợp với Route 53, nhưng với k8s tự host thì vừa không có triển khai load balancer, vừa bị hạn chế trong việc tích hợp DNS. Ở những công ty có riêng đội ngũ quản lý k8s thì những ưu điểm bạn nói có thể đúng thật.

Nghe qua thì có vẻ là một giải pháp ổn, nhưng khi dùng thực tế thì không phải lúc nào cũng hoạt động trong mọi tình huống.

[kandk]

Dễ dùng ngay cả khi không có đội ngũ quản lý k8s. Chỉ cần dùng EKS là được.

[savvykang]

Chẳng phải điều này cũng giống như lập luận rằng chỉ cần bàn giao mã nguồn là xong sao? Có vẻ như tài liệu hướng dẫn công việc và lịch sử thực hiện công việc vẫn là những thứ cần thiết.

[kbumsik]

Bản thân Infra as Code vốn là để chỉ cần đưa mã nguồn vào là xong.
À, tất nhiên cũng như mọi loại mã khác, tài liệu cơ bản vẫn phải được viết đầy đủ.

[kandk]

Có thể làm được nếu mã nguồn được viết tốt và tài liệu đầy đủ.
Sẽ hữu ích nếu có riêng sổ tay công việc và lịch sử thực hiện công việc, nhưng có vẻ đó là câu chuyện khác với bài viết này.

[GN⁺]

Ý kiến trên Hacker News

• Đã có kinh nghiệm triển khai thành công ở nhiều công ty bằng shell script

  • Với 2 dịch vụ PHP, xử lý hơn 1 tỷ request mỗi ngày, triển khai không downtime bằng cách chuyển file lên server và chạy migration
  • Trong các ngành không cần webscale như tài khoản hưu trí, triển khai bằng lệnh Docker thông qua Jenkins
  • Có thể dùng môi trường thử nghiệm theo nhu cầu chỉ trong vài phút
  • Công ty hiện tại đang cố áp dụng Kubernetes nhưng gặp khó khăn vì độ phức tạp

• Kubernetes đòi hỏi hai đến ba nhân sự chuyên trách chỉ để quản lý các file YAML

  • Nếu chọn nhà cung cấp cloud thì có thể giải quyết phần phức tạp, nhưng sẽ phát sinh thêm chi phí
  • File YAML là file cấu hình nên được công cụ tạo ra, không phải thứ để con người tự viết
  • Phần lớn website và dịch vụ không cần Kubernetes

• Quan niệm rằng cái gì đơn giản thì mong manh là sai lầm

  • Việc hiểu và debug độ phức tạp của YAML file và Kubernetes còn khó hơn
  • Một lựa chọn thay thế cho Kubernetes là shell script

• Có những trường hợp không cần Kubernetes

  • Với EC2 instance và shell script đơn giản, vẫn có thể xử lý hơn 100.000 người dùng đồng thời
  • Nếu không có vấn đề thì không nhất thiết phải thay đổi

• Có thể dễ dàng quản lý quy tắc iptables và chỉnh sửa sysctl bằng shell script

  • Thay vì tạo container theo kiểu lập trình bằng job queue, có thể chỉ cần push công việc

• Chỉ trích Kubernetes là hành động thiếu chuyên nghiệp

  • Nếu không phải ứng dụng quy mô lớn như Google hay Netflix thì viết script đơn giản sẽ tốt hơn

• Giả định rằng mọi ràng buộc của hệ thống tự xây đều là chi phí, còn mọi tính linh hoạt của giải pháp dùng chung đều là lợi ích, là sai lầm

  • Người ta muốn tuân theo các mẫu tương tự trong codebase và muốn các dịch vụ được triển khai theo cùng một cách

• Vấn đề của Kubernetes là vô số thư viện mã nguồn mở khiến hệ thống khó hiểu và dễ phát sinh bug

• Những người đã vượt qua đường cong học tập của Kubernetes thường nói rằng độ phức tạp không tệ đến vậy

  • Các buổi dạy Kubernetes cho developer chỉ mất khoảng 30 phút và có thể giúp họ viết Helm chart