ĐIỀU CẦN BIẾT KHI CHẠY CONTAINERS VÀ KUBERNETES TRÊN AWS (PHẦN 2)

Mặc dù Docker là một công cụ tuyệt vời cho cả nhà phát triển và vận hành. Nhưng việc mở rộng quy mô cho nhiều dịch vụ nhỏ đòi hỏi nhiều thao tác thủ công. Trong bài viết này, chúng ta sẽ xem xét kỹ hơn về giám sát, bảo trì cluster và khả năng mở rộng cũng như những giải pháp quản lý thay thế cho Kubernetes.

4.Giám sát Kubernetes Cluster

Khi quản trị môi trường Kubernetes, hãy theo dõi cluster và các ứng dụng đang chạy trong đó để biết về những gì đang thực sự xảy ra. Sẽ có rất nhiều rủi ro nếu không thực hiện hiệu quả việc giám sát. Sự phức tạp của Kubernetes cũng làm cho việc giám sát trở nên khó hơn. Vì có nhiều lớp, log, thông số cần được theo dõi và xem xét.

4.1 Giám sát Kubernetes

Rất tiếc, giải pháp tích hợp sẵn của Kubernetes cho việc này khá đơn giản. Và chủ yếu giới hạn trong việc thu thập và truy xuất log từ các container Docker. Các bản ghi được lưu trữ trong không gian dành riêng trên worker node. Và có thể đọc chúng bằng lệnh kubectl log. Mặc dù đây là cách giúp nhanh chóng bắt đầu tìm hiểu Kubernetes. Nhưng bạn cần một giải pháp chuyên ghi log và giám sát cho mọi môi trường thực tế.

4.2 Ghi log ở toàn Cluster-Level

Cluster-level logging có thể tạo ra với node-level logging agents. Nhưng nếu bạn tự tạo Kubernetes cluster, thì agent không tự động sẵn có ở đó. Vì vậy bạn phải cài đặt chúng. Thường thì DaemonSet được sử dụng cho việc này (DaemonSet giống như Deployment nhưng được đảm bảo là một Pod đang chạy sẽ được đặt trên mỗi worker node). Khi bạn có các agent, quản lý log cluster có thể được định cấu hình bằng ELK hoặc EFK hoặc một công cụ tương tự.

4.3 Kiểm toán

Đảm bảo thiết lập kiểm tra, theo dõi tất cả các lệnh gọi API đến Kubernetes cluster. Việc bảo mật này cần được đặc biệt quan tâm. Vì rất cần có log kiểm tra nếu có bất kỳ hoạt động nào sai. Cũng như trong các doanh nghiệp, các chính sách tổ chức, pháp lý hoặc việc tuân thủ tiêu chuẩn luôn yêu cầu cần được kiểm toán. Hãy kiểm tra định kỳ và lưu trữ tất cả kết quả quá trình kiểm tra.

4.4 Tự động phát hiện sự cố trong node

Nên thiết lập bộ phát hiện sự cố trong mỗi node (máy chủ hoặc máy ảo) trong DaemonSet. Sau đó, nếu bất kỳ node nào gặp sự cố và không thể hoạt động bình thường, bộ dò sẽ gửi cảnh báo. Tài liệu chính thức của Kubernetes có hướng dẫn đầy đủ cho bạn.

4.5 Số liệu

Điều quan trọng trong việc giám sát Kubernetes cluster là thu thập các số liệu. Prometheus cho đến nay là giải pháp phổ biến nhất, được tích hợp Kubernetes rất tốt. Hướng dẫn này sẽ phù hợp để thiết lập ban đầu. Khi Prometheus chạy, và đang thu thập,  lưu trữ các số liệu, bạn sẽ nhận ra rằng các tính năng đồ họa của nó bị hạn chế. Giải pháp phổ biến là sử dụng dữ liệu do Prometheus thu thập làm nguồn. Để Grafana tạo trang tổng quan, các hình ảnh trực quan khác, và AlertManager để gửi các cảnh báo được kích hoạt.

5.Bảo trì cluster và khả năng mở rộng

Thoạt nhìn, có vẻ như Kubernetes đã trừu tượng hóa cơ sở hạ tầng vật lý, bằng ngôn ngữ logic của nó chẳng hạn như các node. Nhưng khi bạn thực sự bắt đầu công việc, bạn nhận ra rằng các node vẫn là máy chủ thực tế hoặc máy ảo. Vì vậy, các ứng dụng và workload bên trong Pods đang chạy trên các máy chủ và việc bảo trì nó là trách nhiệm của bạn.

Vậy Kubernetes thực sự như thế nào? Có lẽ, chúng ta có thể xem nó như một nền tảng triển khai, và lập kế hoạch cho Docker. Chứ không phải là một hệ thống toàn năng sẽ chạy các container của bạn mà không cần lo lắng gì thêm. Cơ sở hạ tầng cơ bản rất quan trọng và bạn cần sớm làm quen với nó.

5.1 Master và Worker Node

Các node của Kubernetes cluster, như master node và worker node, vẫn cần được bảo trì tương tự như bất kỳ thiết bị nào khác được kết nối với Internet. Quan trọng nhất là bản vá và cập nhật hệ điều hành. Ngoài ra đôi khi bạn phải cài đặt phần mềm hoặc phiên bản mới khi cần thiết. Kubernetes sẽ không quan tâm đến bất kỳ điều gì trong số này, nó tự giới hạn tài nguyên của mình; kubelet và Pods chạy trên node. Vì vậy, bạn phải chịu trách nhiệm về việc này. Và cần có quy trình bảo trì theo lịch trình hoặc tự động trong quy trình làm việc của bạn.

Ngoài ra, bạn phải theo dõi thông tin bảo mật để tìm hiểu về các lỗ hổng đã được công bố sẽ ảnh hưởng đến hệ điều hành của bạn. Vá các lỗ hổng bảo mật của hệ điều hành và ứng dụng là điều tối thiểu phải làm trên mọi node, để tránh bị tấn công hoặc DDOS. Tùy thuộc vào hệ điều hành trong các node của bạn, hãy làm quen với công cụ quản lý (yum, apt-get, dnf, dpkg, …) và chuẩn bị các script để thường xuyên kiểm tra các bản sửa lỗi bảo mật.

Nếu bạn đang sử dụng giải pháp được quản lý cho cluster của mình. Thì hy vọng rằng nó sẽ có các giải pháp tại chỗ để thực hiện bảo trì cho bạn, hoặc tốt hơn là tự động. Trong trường hợp giải pháp Kubernetes được quản lý, nhà cung cấp dịch vụ nên đưa ra câu trả lời rõ ràng về node OS và chiến lược vá lỗ hổng bảo mật của họ. Các nhà cung cấp dịch vụ tốt nhất có thể xử lý hầu hết các bảo trì ở mọi node OS-level. Mà không có bất kỳ gián đoạn nào cho các dịch vụ của bạn.

5.2 Tự động mở rộng quy mô trong Kubernetes

Kubernetes được phần lớn người dùng sử dụng vì nó cung cấp nhiều tùy chọn mở rộng quy mô. Việc mở rộng cluster hoặc workload trong cluster có thể được thực hiện trên cả hai lớp. Mức vật lý (các node) và ở mức logic (Pods) nếu thích hợp.

Ở mức workload, Kubernetes cho phép mở rộng và thu hẹp quy mô các Pod bằng Horizontal Pod Autoscaler. Tương tự như khi làm việc với các tài nguyên tự động mở rộng khác, bạn cấu hình số liệu có liên quan đến ứng dụng của mình. Và nó đo lường workload của cluster tốt nhất có thể.

Vertical Pod Autoscaler cũng được Kubernetes sử dụng với stateful Pod. Database engine sẽ là một ví dụ cho điều này. Stateful Workload là không thể dễ dàng thêm các Pod mới. Vì chúng không có trạng thái giống như Pod hiện có. Do đó khi việc sử dụng tài nguyên thay đổi, Pod sẽ được tăng hoặc giảm theo số liệu.

Cluster Autoscaler giám sát trạng thái của tất cả các Pod nói chung. Và sau đó có thể giao tiếp với nhà cung cấp đám mây để tạo hoặc xóa các worker node dựa trên số liệu Pod. Vì thêm và xóa máy chủ là một hoạt động phụ thuộc vào nhà cung cấp dịch vụ lưu trữ. Tính khả dụng của Cluster Autoscaler phụ thuộc vào nơi lưu trữ Kubernetes cluster. Nó hỗ trợ các nhà cung cấp đám mây lớn. Có khả năng tạo và xóa các máy ảo ngay lập tức theo yêu cầu, chẳng hạn như AWS, GCP và Azure.

6.Giải pháp thay thế

Hiện tại, việc cấu hình Kubernetes cluster đòi hỏi rất nhiều công việc. Vì vậy nhu cầu về các giải pháp được quản lý do bên thứ ba cung cấp rất cao. Với các giải pháp như vậy, việc quản lý cluster cơ bản nhất được thực hiện bởi nhà cung cấp dịch vụ. Trong khi đó bạn chỉ cần tập trung vào workload của mình.

Trước hết, cần nhắc lại rằng Google (nhà phát triển Kubernetes ban đầu) cung cấp dịch vụ Google Kubernetes Engine (GKE) như một phần của Google Cloud Platform (GCP). GKE tận hưởng lợi thế từ sự phát triển của riêng Google. Tích hợp Kubernetes khá tốt vào hệ sinh thái đám mây của họ. Tuy nhiên, AWS cũng có các dịch vụ khá phổ biến.

6.1 EKS

Giải pháp Kubernetes do AWS quản lý là Elastic Kubernetes Engine (EKS). Việc thiết lập một cluster EKS phức tạp hơn một chút so với GKE. Cách cấu hình phổ biến là sử dụng các mẫu CloudFormation do AWS cung cấp. Sửa đổi chúng dựa trên những gì bạn cần. Và triển khai CloudFormation để thiết lập cơ sở hạ tầng Kubernetes cluster trong EKS. Cũng như các dịch vụ được AWS quản lý, EKS tích hợp tốt với các dịch vụ AWS khác, như IAM và CloudWatch. Và hiện tại đang là một tùy chọn được yêu thích.

6.2 ECS

Ngoài Kubernetes, một dịch vụ được quan tâm khác là ECS. Đây là giải pháp độc quyền từ AWS để chạy các container Docker và không dựa trên Kubernetes. Một trong những điều hấp dẫn nhất về dịch vụ này là bạn có hai tùy chọn tính toán: máy ảo EC2 truyền thống và phiên bản Fargate serverless.

AWS đã phát hành Fargate vào năm 2017 như một tùy chọn để quản lý các cluster dựa trên Docker. Fargate hoạt động như một phần mềm phụ trợ cho ECS. Và giải pháp serverless này loại bỏ nhu cầu quản lý cơ sở hạ tầng cơ bản mà các container Docker đang chạy. Tại đây, bạn chỉ cần tập trung vào lớp container với các ứng dụng của mình. Fargate tự động mở rộng quy mô và xử lý mọi bản cập nhật nền tảng mà người dùng không cần phải làm gì cả. Với tùy chọn tính toán này, phần lớn sự phức tạp của việc điều phối container sẽ được tránh khỏi.

7.Kết luận

Tùy thuộc vào mục tiêu của bạn. Nếu bây giờ, bạn chỉ muốn chơi với Kubernetes, tìm hiểu, cài đặt và sử dụng minikube trên máy tính của riêng bạn hoặc trong máy ảo. Công cụ này sẽ có một Kubernetes cluster kích thước nhỏ kích hoạt chạy trong giây lát.

Tiếp theo, việc tạo, cấu hình, mở rộng quy mô và quản lý Kubernetes của riêng bạn thật không phải điều dễ dàng. Hãy chuẩn bị để học nhiều và nghiên cứu hàng ngày trên internet. Các giải pháp thường có sẵn nhưng chúng không phải lúc nào cũng rõ ràng. Hãy tranh thủ sự trợ giúp của các công cụ phù hợp. Nhưng phải nghiên cứu kỹ lưỡng về chúng. Một ví dụ như sử dụng trình quản lý gói Helm là một cách tốt để giữ cho các dịch vụ của bạn có tổ chức.

Tuy nhiên, nếu bạn quyết định rằng bạn không thể nào tự quản lý? Thì đó là lý do tại sao các giải pháp, chẳng hạn như Amazon Elastic Kubernetes Service (EKS) tồn tại. Và cuối cùng, mục tiêu của việc kinh doanh là để thành công. Do đó để đạt được điều này, bạn có thể lựa chọn tự mình làm tất cả hay chọn một giải pháp đã được tạo sẵn.