Đọc phần 1 tại đây

Nguồn lực hữu hạn

Khi bắt đầu sử dụng Kubernetes, chúng tôi hiểu rằng tài nguyên là hữu hạn. Chúng ta có thể quy định cấu hình các tài nguyên và giới hạn CPU / bộ nhớ trên các pod. Chúng ta cũng có thể kiểm soát các tài nguyên và hạn chế bursting.

Những cài đặt này cực kỳ quan trọng để có thể chạy nhiều container cùng nhau một cách hiệu quả. Nếu chúng tôi không thiết lập cài đặt một cách chính xác, các container sẽ gặp sự cố vì chúng không thể phân bổ đủ bộ nhớ.

Hãy thiết lập cài đặt và test giới hạn của tài nguyên từ sớm. Mọi thứ vẫn sẽ chạy tốt nếu không thiết lập giới hạn cho tài nguyên, tuy nhiên sẽ có sự cố xảy ra khi chúng ta đặt một lượng tải lớn vào một trong các container.

Chúng tôi đã monitor Kubernetes như thế nào?

Khi gần hoàn thành việc cài đặt Kubernetes, chúng tôi nhanh chóng nhận ra rằng việc monitoring & logging đặc biệt quan trọng trong môi trường mới này. Bạn không thể đăng nhập vào server để tìm kiếm một file log trong một số lượng lớn các replicas và nodes. Ngay khi bắt đầu sử dụng Kubernetes, chúng ta nên có kế hoạch xây dựng hệ thống monitoring và logging tập trung.

 

Logging

Có rất nhiều công cụ open-source có sẵn để logging. Chúng tôi quyết định sử dụng Graylog, một công cụ tuyệt vời để logging và Apache Kafka, một hệ thống messaging để thu thập và trích xuất logs từ các container. Các container gửi log đến Kafka và Kafka gửi chúng cho Graylog để đánh index. Chúng tôi đã quyết định để các thành phần của application tự gửi log đến Kafka để stream log và đánh index dễ dàng hơn. Ngoài ra, có các công cụ truy xuất log từ bên ngoài container và gửi chúng sang một hệ thống xử lý log khác.

 

Monitoring

Kubernetes thực hiện việc recovery rất tốt khi có lỗi phát sinh. Trong trường hợp pods bị sập vì bất kỳ lý do gì, Kubernetes sẽ khởi động lại chúng và ngay cả khi Kubernetes đang tạo thêm các replicas, người dùng thậm chí sẽ không nhận thấy vấn đề gì. Kubernetes  thực hiện việc recovery tốt tới mức các container của chúng tôi nhiều lần gặp sự cố trong ngày do memory leak, mà không một ai (kể cả chính chúng tôi) nhận thấy điều đó.

Đây là điểm mạnh của Kubernetes, nhưng chắc hẳn chúng ta vẫn muốn phát hiện ngay khi có vấn đề xảy ra. Chúng tôi sử dụng dashboard health-check tùy chỉnh để theo dõi các Kubernetes node, các pod riêng lẻ – các application đang chạy…và các services khác như lưu trữ dữ liệu. Việc sử dụng Kubernetes API rất hữu ích nếu bạn muốn triển khai 1 dashboard như vậy. 

Ngoài ra chúng tôi cũng nghĩ rằng việc đo tải, lưu lượng, lỗi trên application và các chỉ số khác cũng không kém phần quan trọng. Một lần nữa, các open-source sẽ hỗ trợ chúng ta rất nhiều. Các thành phần trong application của chúng tôi đẩy các số liệu lên một InfluxDB. Chúng tôi cũng sử dụng Heapster để thu thập các số liệu trên Kubernetes. Các số liệu được lưu trữ trong InfluxDB được hiển thị trong Grafana, một công cụ dashboard nguồn mở. Ngoài InfluxDB / Grafana, cũng có rất nhiều tool hữu ích khác để bạn theo dõi những gì đang chạy. 

 

Lưu trữ dữ liệu và Kubernetes

Một câu hỏi mà nhiều người mới dùng Kubernetes đặt ra là: Nên xử lý các dữ liệu của mình với Kubernetes như thế nào?

Khi sử dụng một kho dữ liệu như MongoDB hoặc MySQL, chúng ta luôn muốn dữ liệu được bảo toàn. Bởi bạn biết rằng container sẽ mất dữ liệu khi chúng khởi động lại. Điều này không phải là vấn đề với các stateless components, nhưng không tốt đối với một kho dữ liệu cần được bảo toàn. Kubernetes đưa ra khái niệm về volume để làm việc với các dữ liệu cần được bảo toàn.

Một volume có thể được triển khai bằng nhiều cách, bao gồm các file trên máy chủ, AWS Elastic Block Store (EBS) và NFS. Khi chúng tôi đang nghiên cứu về bảo toàn cho dữ liệu , volume là một giải pháp  tốt, nhưng nó chưa phải là giải pháp hoàn hảo cho các kho dữ liệu đang hoạt động của chúng tôi.

 

Vấn đề với sự nhân bản

Trong quá trình triển khai ứng dụng, các kho dữ liệu sẽ chạy replica. Mongo thường chạy kiểu replica  và MySQL có thể chạy chế độ primary /replica. Điều này có thể gây nên một số vấn đề. Trước hết, mỗi node trong cụm lưu trữ dữ liệu sử dụng một volume khác nhau, do đó ghi dữ liệu vào cùng một volume sẽ dẫn đến lỗi dữ liệu. Một vấn đề khác là hầu hết các kho dữ liệu cần được cấu hình một cách chính xác để cluster có thể bắt đầu chạy; việc tự động tìm và cấu hình của các node là không phổ biến. 

Đồng thời, một thiết bị chạy kho dữ liệu thường được chỉ định chỉ để thực hiện công việc đó. Sử dụng IOPS cao hơn  là một ví dụ. Scaling(thêm / xóa các node) cũng là một việc làm gây tốn kém đối với hầu hết kho lưu trữ data. Tất cả những điều trên không hề khớp với bản chất tự nhiên của Kubernetes deployments.

 

Quyết định không sử dụng Kubernetes để chạy kho dữ liệu trong production

Tình huống này sẽ cho chúng ta thấy việc chạy một  kho dữ liệu trong Kubernetes vẫn có khả năng bị hạn chế.  Sự linh hoạt của Kubernetes không phải lúc nào cũng thật sự hữu dụng. Việc setup cũng phức tạp hơn nhiều so với hầu hết các Kubernetes deployments thông thường khác.

Do đó, chúng tôi quyết định không chạy kho dữ liệu của production bằng Kubernetes. Thay vào đó, chúng tôi thiết lập các cluster này thủ công trên các máy chủ khác nhau với các điều chỉnh cần thiết để tối ưu hóa kho dữ liệu đó. Các ứng dụng của chúng tôi chạy bên trong Kubernetes chỉ cần kết nối tới cụm lưu trữ dữ liệu như bình thường. Bài học ở đây là chúng ta không cần phải chạy tất cả mọi thứ trong Kubernetes. Trừ các kho dữ liệu và máy chủ HAProxy, mọi thứ còn lại của chúng tôi đều chạy bằng Kubernetes, bao gồm cả các giải pháp monitoring và logging.

 

Tại sao chúng tôi hào hứng khi sử dụng Kubernetes vào những năm tiếp theo

Khi chúng tôi nhìn lại các deployment đã thực hiện, Kubernetes thực sự rất tuyệt vời. Kubernetes API là một công cụ hữu dụng trong việc tự động hóa một quy trình deployment. Việc deploy không chỉ an toàn mà còn nhanh chóng hơn rất nhiều vì chúng tôi không còn phải mất thời gian làm việc với với VMs nữa. Các bản dựng và deployment đã trở nên đáng tin cậy hơn vì chúng dễ dàng để kiểm tra và chuyển vào các container.

Chúng tôi hiểu rằng  việc sử dụng phương thức deploy mới này là cần thiết để bắt kịp các development team khác. Bởi chính họ cũng đang thay đổi thường xuyên hơn và tìm cách tối ưu chi phí thực hiện mỗi ngày.

 

Tính toán chi phí

Có 2 mặt của vấn đề khi nhìn vào chi phí. Để chạy Kubernetes thì nhất định phải có một cụm etcd và một master node . Mặc dù đây không phải là các thành phần quá tốn kém, tuy nhiên nó sẽ trở nên đáng kể một khi chúng ta chạy các ứng dụng nhỏ. Đối với ứng dụng loại này, tối ưu nhất có lẽ là sử dụng một giải pháp có sẵn, ví dụ như dịch vụ của Google’s Container.

Triển khai các ứng dụng lớn đồng nghĩa với việc dễ dàng tiết kiệm chi phí server hơn. Chi phí hoạt động của etcd và master node sẽ không đáng kể lắm khi triển khai các ứng dụng kiểu này. Kubernetes sẽ giúp cho việc chạy nhiều container trên cùng một  hosts trở nên dễ dàng hơn, từ đó tận dụng được tối đa các tài nguyên có sẵn. Điều này giúp giảm số lượng server,đồng nghĩa với việc tiết kiệm chi phí cho chúng ta. Nghe có vẻ tuyệt vời đúng không? Tuy nhiên, nếu đứng từ góc nhìn khác, các cụm cluster kiểu này có vẻ chưa thực sự hấp dẫn, bởi hiện nay có hàng “tá” các dịch vụ có sẵn tốt hơn hơn, như Cloud RTI mà nhóm chúng tôi đang sử dụng. 

 

Tương lai tươi sáng của Kubernetes

Chạy Kubernetes trong phiên bản pre-released lúc đó khá “khoai”, và việc theo kịp với những phiên bản mới là điều gần như không thể. Sự phát triển của Kubernetes đã diễn ra với tốc độ cực kỳ nhanh trong năm qua; cộng đồng sử dụng nó thậm chí đã đủ trở thành một “quốc gia riêng” với cư dân là các kỹ sư tài năng. Chúng tôi thật sự rất kinh ngạc trước sự phát triển của Kubernetes trong năm vừa rồi. 

Like và follow Fanpage của Pixta Việt Nam tại đây để cùng đọc và cập nhật những tin tức công nghệ mới nhé!

Tác giả: Paul Bakker, Software architect, Netflix

Xem bài viết gốc tại đây

Tổng hợp và dịch: Vân Phạm, Thảo Ly, Huy Trần, Hoàng Lân