NHỮNG ĐIỀU CẦN BIẾT KHI CHẠY CONTAINER VÀ KUBERNETES TRÊN AWS (PHẦN 1)

Trong vài năm qua, Docker đã trở thành một trong những công nghệ phát triển phần mềm quan trọng nhất thế giới. Nó thay đổi hoàn toàn cách các ứng dụng được xây dựng, di chuyển và triển khai. Thay vì phải luôn cẩn thận chú ý chi tiết các vấn đề môi trường. Docker cho phép bạn đặt ứng dụng đang chạy bên trong container và có một giao diện đồng nhất.

Nhưng trong khi Docker là một công cụ tuyệt vời cho cả nhà phát triển và vận hành. 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. Đây là lý do tại sao các công cụ điều phối khác nhau đã được tạo ra để quản lý nhiều container Docker. Một công cụ điều phối tốt cho phép quản lý tập trung nhiều dịch vụ cùng một lúc.

Kiến trúc này mang lại nhiều lợi ích to lớn. Nhưng đồng thời chúng ta cũng phải đối mặt với sự phức tạp mới. Bây giờ chúng ta có thêm hai lớp cần quản lý: các container và máy chủ chạy các container đó. Để thành công với kiến trúc mới này, bạn phải nắm vững sự phức tạp đó.

1.Kubernetes

Kubernetes là công cụ orchestration (tạo ra, điều phối và chỉ huy các container) phổ biến nhất hiện nay. Nó bắt nguồn từ Google và hiện vẫn được duy trì phát triển và bảo trì. Nhưng hiện tại nó là một phần của Cloud Native Computing Foundation (CNCF).

Công cụ này được nhiều công ty lớn sử dụng trong quá trình sản xuất. Và phát triển nhanh chóng nhờ vào các bản cập nhật mới thường xuyên. Kubernetes được thiết kế để cho phép người dùng cấu hình nó theo nhu cầu. Những người đam mê công nghệ rất thích tính linh hoạt này. Tuy nhiên, thật không dễ dàng thiết lập và duy trì hệ thống cho những người mới bắt đầu hoặc trong những lần đầu tiên.

Lợi dụng điều này, các nhà cung cấp dịch vụ đám mây bắt đầu cung cấp các giải pháp nhằm gói gọn sự phức tạp của Kubernetes trong một giao diện người dùng dễ tiếp cận hơn. Cho đến nay đã có một số thành công. Tuy nhiên, bài viết này sẽ tập trung vào việc hỗ trợ những người thiết lập và quản lý các Kubernetes Cluster của riêng họ.

2.Điều quan trọng khi thiết lập một Kubernetes Cluster

Một thách thức lớn xuất hiện ngay từ ban đầu: thiết lập Kubernetes Cluster. Đây không phải là một nhiệm vụ dễ dàng. Tuy có các công cụ sẵn có để giúp bạn, như kops. Nhưng hãy lưu ý rằng nó đã đưa ra nhiều quyết định thay bạn. Vì vậy mặc dù nó đơn giản hóa trải nghiệm. Nhưng mức độ kiểm soát mà bạn nhận được cũng bị hạn chế. Tuy nhiên, các lựa chọn mà kops đưa ra cho bạn là hợp lý đối với các workload điển hình. Bạn có thể xem thêm hướng dẫn về kops tại đây.

Một cách phổ biến để tìm hiểu sâu về Kubernetes ngay từ đầu là thiết lập thật khó cluster của bạn. Cách tiếp cận này thực sự khó, nhưng nó sẽ giúp hiểu chi tiết về cách chạy cluster. Kèm theo giải thích tại sao bạn phải làm tất cả những điều đó. Bạn sẽ phải dành nhiều thời gian nếu chọn cách này, tùy thuộc vào kinh nghiệm trước đây và loại công việc có thể mất đến vài ngày để hoàn thành.

Một vài lưu ý khi thiết lập Kubernetes:

Không có hỗ trợ cho identity federation (vì vậy, việc có thể sử dụng nhà cung cấp danh tính, như đăng nhập Google, LDAP hoặc Active Directory) không phải là chuyện nhỏ.
Không có chế độ tự động High Availability. Để tạo một cluster cấp sản xuất với tính High Availability. Yêu cầu cần cấu hình HA thủ công cho etcd cluster, kube-apiserver, bộ cân bằng tải, bất kỳ worker node có mức độ ưu tiên cao hơn và nhiều thứ khác.

Với đề xuất định cấu hình trước cluster để tránh hết bộ nhớ. Điều này có thể được thực hiện bằng cách thiết lập các máy chủ kubelet để bắt đầu thu thập garbage dựa trên số lượng inode miễn phí. Kubernetes có các giá trị mặc định cho bộ nhớ khả dụng và dung lượng khả dụng. Nhưng bạn vẫn có thể hết inodes trước những giá trị đó, dẫn đến sự cố không mong muốn. Sau đây là một ví dụ để kích hoạt thu gom garbage dựa trên inodes miễn phí: – eviction-hard = memory.available <100Mi, nodefs.available <10%, nodefs.inodesFree <5%

3.Vấn đề thường gặp với Kubernetes Cluster

Sau đây là một số thông tin hữu ích để làm việc với một Kubernetes Cluster:

3.1 Giới hạn Namespace

Khi quản lý workload trong môi trường điều phối container, sẽ có sự ngăn cách giữa các workload này. Nhưng về mặt vật lý chúng vẫn chia sẻ cùng một tài nguyên phần cứng. Có nghĩa là các vấn đề trong một dịch vụ vẫn có thể ảnh hưởng đến những dịch vụ khác. Vì vậy, hãy cấu hình giới hạn mặc định cho namespaces trong Kubernetes Cluster. Sau đó, nếu ứng dụng của bạn bị rò rỉ bộ nhớ, pod đang chạy ứng dụng của bạn sẽ không làm hỏng worker node. Vì nó đạt đến giới hạn bộ nhớ trước. Sau đây là một ví dụ về cấu hình cho một namespaces:

apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
default
Request:
memory: 256Mi
type: Container

Điều cần cân nhắc tiếp theo là nguyên tắc bảo mật. Đặc biệt là trên nền tảng Đám mây: hạn chế quyền của người dùng theo Principle of Least Privilege. Trong môi trường Kubernetes quy mô lớn, bạn thường có thể phân loại người dùng của mình thành hai hoặc nhiều nhóm.

Ở đây chúng tôi xem xét những điểm chung nhất; quản trị viên và deployer. Quản trị viên bị giới hạn trong một namespaces, truy cập vào vùng thông tin mật của namespaces và tất cả các quyền quản trị. Deployer cũng bị giới hạn trong một namespaces và chỉ có các đặc quyền tối thiểu để triển khai. Đó là cập nhật các dịch vụ. Đối với quyền truy cập có lập trình vào Kubernetes API thông qua ứng dụng hoặc tập lệnh. Bạn có thể tạo role hoặc tài khoản dịch vụ với các giới hạn quyền tương tự như deployer.

3.2 Khai báo

Kubernetes là nền tảng linh hoạt và mở. Cho phép cả cách tiếp cận theo mệnh lệnh và khai báo. Với các lệnh bắt buộc, bạn ra lệnh trực tiếp cho Kubernetes biết phải làm gì. Chẳng hạn như tạo một tài nguyên thuộc loại cụ thể. Với cấu hình khai báo, bạn viết một tập hợp các tệp (định dạng YAML) mô tả trạng thái mong muốn của bạn và để Kubernetes quyết định cách đạt được nó. Ngoại trừ thử nghiệm hoặc gỡ lỗi, hãy thử sử dụng phương pháp khai báo với Kubernetes. Bằng cách này, bạn tập trung vào những gì quan trọng (mục tiêu) và cũng đảm bảo rằng cấu hình được lưu trữ và có thể chạy lại khi cần thiết (vì chuỗi lệnh kubectl trong phương pháp mệnh lệnh sẽ khó tái tạo và thường dẫn đến lỗi).

Vậy làm thế nào chúng tôi triển khai các ứng dụng đến Kubernetes Cluster bằng các kiểu khác nhau. Theo mệnh lệnh, hãy sử dụng lệnh “kubectl create deployment”. Theo cách khai báo, hãy sử dụng tệp YAML mô tả đối tượng triển khai. Và sau đó cập nhật Kubernetes Cluster với “kubectl apply” cho tệp đó làm tham số. Một nguyên tắc chung là với Kubernetes, phương pháp mệnh lệnh tốt hơn khi kiểm tra và gỡ lỗi nhanh. Trong khi cách khai báo là cách bạn quản lý các cluster hàng ngày.

3.3 Docker Tags

Vấn đề thường thấy với Docker Tags sẽ gây ngạc nhiên cho bất kỳ người dùng mới nào. Mọi người có xu hướng sử dụng lại tag “latest” cho hình ảnh Docker của họ và bất ngờ là sau đó thấy Kubernetes không cập nhật Pod của họ. Điều này xảy ra bởi vì Kubernetes coi các Docker Tags là bất biến.

Trong các khái niệm của Kubernetes, một khi một tag được đặt, thì nó luôn trỏ đến cùng một phiên bản hoặc đối tượng và không bao giờ thay đổi. Nhưng kỳ vọng này rõ ràng là sai đối với Docker Tags “latest”, tag này tự động cập nhật để trỏ đến phiên bản latest. Mặc dù có một số giải pháp thay thế, nhưng tốt hơn hết bạn nên tránh tag “latest” khi làm việc với Kubernetes. Và thay vào đó hãy đảm bảo gắn tag hình ảnh Docker của bạn bằng một tag cụ thể (ví dụ: số đang chạy hoặc git commit hash), tag này đã được thêm lợi ích khi quản lý hình ảnh Docker của bạn.

3.4 Cấu hình Pod Disruption Budgets

Một mẹo hữu ích khác là thiết lập Pod Disruption Budgets. Để cho phép cluster của bạn duy trì high availability trong những lần gián đoạn có kế hoạch hoặc bất ngờ, như trong quá trình triển khai. Pod Disruption Budgets nhằm mục đích duy trì sự sẵn có workload của bạn ngay cả khi có điều gì đó thay đổi. Pod Disruption Budgets được định cấu hình YAML như sau:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a

Kết luận

Trong phần 1 này, chúng tôi đã giới thiệu về Kubernetes và một số mẹo hữu ích cho việc thiết lập. Đừng bỏ lỡ phần tiếp theo của chúng tôi 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.

Hãy liên hệ ngay với Renova Cloud để được tư vấn những giải pháp tốt nhất cho doanh nghiệp.