bỏ qua Nội dung chính
Chào mừng bạn đến với Gimasys!
Hotline: +84 974 417 099 (HCM) | +84 987 682 505 (HN) gcp@gimasys.com

5 tính năng của Google Kubernetes Engine (GKE) giúp tối ưu hóa các cluster hệ thống

Trong bài đăng này, Google sẽ thảo luận về 5 tính năng trong GKE mà bạn có thể sử dụng để tối ưu hóa các cluster. Để bắt đầu thử nghiệm những thứ này trong GKE, hãy xem các hướng dẫn tương tác của Google để bắt đầu với standardautopilot clusters. 

Nếu bạn tìm thấy giá trị từ việc chạy workloads trên các Kubernetes cluster trong tổ chức của mình, thì rất có thể bạn sẽ trải qua nhiều thứ- có thể là thông qua các cluster lớn hơn hoặc nhiều cluster hơn.

Cho dù cách tiếp cận của bạn là gì, có một điều chắc chắn: bạn phải trả tiền cho các tài nguyên mà bạn sử dụng. Mọi người thường nói – nhiều tài nguyên hơn, sẽ gặp nhiều vấn đề hơn. Bạn càng có nhiều tài nguyên trên các cluster thì việc đảm bảo rằng bạn đang sử dụng chúng một cách hiệu quả càng trở nên quan trọng.

Google Kubernetes Engine có nhiều tính năng được tích hợp sẵn mà bạn với tư cách là quản trị viên cluster có thể sử dụng để tối ưu hóa việc sử dụng tài nguyên của bạn trong GKE.

Hãy xem lại năm trong số các tính năng mà bạn có thể bắt đầu ngay hôm nay.

Tự động hóa quản trị, mở rộng cấu trúc dữ liệu với tích hợp Google Dataplex - BigLake 2

#1 – Xem chế độ cost optimization của cluster ngay trong console

Nếu bạn không biết bắt đầu từ đâu với việc tối ưu hóa các cluster của mình, nơi tốt nhất để bắt đầu là tìm kiếm một vấn đề nổi bật. Điều đó có thể dễ thấy nhất bằng cách xem chế độ xem bao trùm tất cả các cluster của bạn.

Trong GKE, Google có một tab cost optimization ở cấp độ cluster được tích hợp trong console, chứa nhiều thông tin mà bạn có thể khó thu thập bằng cách khác.

Bạn có thể tìm thấy điều này như đã thấy trong hình ảnh sau:

Hình 1 - Điều hướng đến tab cost optimization trong cloud console.
Hình 1 – Điều hướng đến tab cost optimization trong cloud console.

Khi bạn điều hướng đến tab này, bạn sẽ thấy các biểu đồ hình ảnh với các giá trị chuỗi thời gian.

Đối với các GKE standard clusters, biểu đồ này biểu diễn chuỗi thời gian hiển thị ba đồ thị chính cho CPU và Memory trên tất cả các cluster của bạn trong một project:

  • Tổng số CPU/Memory có thể phân bổ – Số CPU hoặc GB of memory có thể được phân bổ cho workloads của người dùng
  • Tổng yêu cầu CPU/Memory – # CPU hoặc GB of memory đã được yêu cầu bởi workloads của người dùng
  • Tổng mức sử dụng CPU/Memory – mức sử dụng thực tế theo # CPU hoặc GB of memory theo workloads của người dùng
Hình 2 - Dữ liệu allocatable, requested, và usage time series trên CPU hoặc memory trong tất cả các standard GKE clusters trên một cửa sổ được chỉ định.
Hình 2 – Dữ liệu allocatable, requested, và usage time series trên CPU hoặc memory trong tất cả các standard GKE clusters trên một cửa sổ được chỉ định.

Phân tích những điều này và liên hệ chúng với nhau có thể giúp xác định câu trả lời cho các câu hỏi tối ưu hóa quan trọng, chẳng hạn như:

  • Google có quá nhiều CPU và memory có thể phân bổ không hoạt động trên các cluster tiêu chuẩn GKE của Google không? Nếu vậy, Google có thể làm những việc như đánh giá lại các loại máy mà Google sử dụng trong nhóm nút không? Điều này có thể giúp Google đóng gói cluster, bằng cách có tỷ lệ tài nguyên có thể phân bổ cao hơn được phân bổ cho các yêu cầu Pod.
  • Workloads đang chạy trong các cluster tiêu chuẩn GKE của Google có yêu cầu quá nhiều CPU và memory không được sử dụng không? Nếu vậy, Google có thể làm những việc như làm việc với chủ sở hữu workloads để điều chỉnh các yêu cầu không? Điều này có thể giúp Google có workloads phù hợp, bằng cách đặt các yêu cầu để phản ánh chính xác hơn mức sử dụng dự kiến.

Nếu Google đang sử dụng GKE Autopilot, hình ảnh hóa chuỗi thời gian này sẽ hơi khác một chút, như thể hiện trong hình ảnh sau:

Hình 3 - Dữ liệu chuỗi thời gian được yêu cầu và sử dụng trên CPU hoặc memory trong tất cả các cluster GKE Autopilot
Hình 3 – Dữ liệu chuỗi thời gian được yêu cầu và sử dụng trên CPU hoặc memory trong tất cả các cluster GKE Autopilot

Trong trường hợp cluster GKE Autopilot, Google chỉ có thể xem Tổng yêu cầu CPU/Memory và Tổng dữ liệu sử dụng CPU/Memory. Nhưng không có gì ở đây thực sự là mất tích!

Trong các cluster Autopilot, bạn chỉ trả tiền cho mỗi Pod dựa trên các requests của nó; Autopilot tự động xử lý việc cung cấp cơ sở hạ tầng, cung cấp cho Google các tài nguyên có thể phân bổ dựa trên bất kỳ thứ gì bạn đặt yêu cầu Pod. Khi Google trao đổi quyền sở hữu việc cung cấp node đó, Google cũng trao đổi quyền kiểm soát để tối ưu hóa ở lớp đó.

Đối với quản trị viên cluster, thông tin này có thể là động lực để thúc đẩy các hành động như đi sâu vào các clusters riêng lẻ hoặc họp với các nhóm workloads để giải quyết các yêu cầu và giới hạn mà họ đặt ra cho workloads. Trong nghiên cứu của Google, đây có lẽ là lĩnh vực có tác động mạnh nhất mà nhiều nhóm tối ưu hóa. Chúng ta sẽ đi sâu hơn một chút vào cách GKE có thể kích hoạt các tính năng trong blog này.

Khi tìm hiểu những thành phần đó đó, sẽ có một số cách giúp tối ưu hóa dữ liệu tài chính để phù hợp với doanh nghiệp. Việc tự mình thu thập thông tin này có thể yêu cầu một chút công sức (đối với một số người, rất nhiều spreadsheets nữa!), nhưng may mắn thay, GKE có một tính năng riêng khác để giúp bạn dễ dàng truy cập thông tin này.

#2 – Phân bổ chi phí GKE

Phân bổ chi phí GKE là một tính năng gốc của GKE tích hợp việc sử dụng workloads với Cloud Billing và các báo cáo của nó, cho phép bạn xem và cảnh báo về việc thanh toán không chỉ ở cấp độ mỗi cluster mà còn ở cấp độ tên per-Kubernetes hoặc per-Kubernetes label.

Nó phải được bật trên cluster của bạn để nó hoạt động, vì vậy nếu bạn đang làm việc với cluster GKE hiện có và muốn bật nó, hãy sử dụng lệnh gcloud sau khi bạn đã đặt zone  hoặc region thích hợp của mình:

$ gcloud beta container clusters create $CLUSTER_NAME \ –enable-cost-allocation

Hình 4 - Báo cáo Thanh toán trên đám mây về các không gian tên trong cluster GKE có bật phân bổ chi phí
Hình 4 – Báo cáo Thanh toán trên đám mây về các không gian tên trong cluster GKE có bật phân bổ chi phí

Nếu không có phân bổ chi phí GKE, tác động tài chính của một cluster và tất cả các workloads khác nhau mà nó có thể chạy sẽ hơi khó hiểu. Với cluster là cấp độ chi tiết sâu nhất trong thanh toán, việc tìm kiếm các khu vực để tối ưu hóa hoặc thậm chí thực hiện hiển thị và chargeback là một thách thức.

Với Namespaces và Labels xuất hiện trong các báo cáo thanh toán, giờ đây bạn có thể hiểu chi phí của các yêu cầu CPU/Memory mà workloads xác định trong Kubernetes. Lưu ý – điều này hoạt động tốt nhất khi bạn đang sử dụng Namespaces và Labels để xác định và tổ chức một cách hợp lý các nhóm cũng như workloads của họ.

Sự tích hợp này cũng mang lại bức tranh tối ưu hóa toàn cảnh hơn – trong đó GKE thường không bị cô lập! Về lý thuyết, workloads trong Namespaces của nhóm có thể đang sử dụng các dịch vụ sao lưu bên ngoài như Cloud Memorystore, đây cũng là một phần quan trọng trong quá trình sử dụng.

Vì dữ liệu Thanh toán trên đám mây có tất cả các dịch vụ GCP nên giờ đây Google có thể lọc và truy vấn trên các Namespaces cũng như các dịch vụ sao lưu tương ứng của chúng.

#3 – Tối ưu hóa chi phí workloads tại console

Khi bạn đã xác định được các nhóm mà bạn có thể muốn làm việc cùng, GKE cung cấp tab tối cost optimization ở cấp độ workloads, sau đó bạn có thể bắt đầu đi sâu vào và xác định workloads cụ thể có thể được tối ưu hóa thông qua một bài tập có tên là “workload right-sizing”. Đây là hành động đảm bảo rằng các yêu cầu Pod phản ánh chặt chẽ hơn mức sử dụng dự kiến ​​của chúng.

Hình 5 - Biểu đồ thanh workload riêng lẻ trong tab tối ưu hóa chi phí GKE
Hình 5 – Biểu đồ thanh workload riêng lẻ trong tab tối ưu hóa chi phí GKE

Như bạn có thể thấy ở đây, Google đưa ra các biểu đồ thanh để thể hiện mối quan hệ của việc sử dụng, yêu cầu và giới hạn với nhau.

  • Xanh đậm: Mức sử dụng CPU/Memory
  • Xanh nhạt: Yêu cầu CPU/Memory
  • Màu xám: Giới hạn CPU/Memory
  • Màu vàng: Các tình huống trong đó mức sử dụng CPU/Memory vượt quá yêu cầu

Bạn cũng có thể di chuột qua từng biểu đồ thanh workload riêng lẻ để hiển thị một báo cáo nhỏ trên màn hình về dữ liệu này. Tương tự như tab tối ưu hóa chi phí của chế độ xem cluster, bạn có thể lọc một khoảng thời gian tùy chỉnh; Google khuyên bạn nên xem dữ liệu này trong khoảng thời gian dài hơn một giờ (tức là một ngày, một tuần, một tháng) để có khả năng phát hiện ra các mẫu hàng ngày hoặc hàng ngày mà nếu không sẽ bị xáo trộn.

Trong ảnh chụp màn hình trước của các biểu đồ này, Google có thể nêu ra một vài mẫu có thể nổi bật với bạn:

  • Nếu chúng ta có quá nhiều màu xanh nhạt xếp chồng lên trên màu xanh đậm trong một thanh, chúng ta có thể có workload được cung cấp quá mức.
  • Nếu Google có thanh màu vàng, thì Google có workload trong đó yêu cầu không được đặt đủ cao, đây có thể là rủi ro về độ ổn định/độ tin cậy – tiêu tốn thêm tài nguyên trên nút của nó và có khả năng bị điều chỉnh hoặc OOMKilled nếu nút đạt đến giới hạn.
  • Nếu Google có một thanh toàn màu xanh đậm, điều này có nghĩa là Google chưa đặt yêu cầu cho workload – đây không phải là phương pháp hay nhất! Đặt các yêu cầu đó.

Với thông tin này, việc nhanh chóng xác định workload cần yêu cầu và giới hạn được điều chỉnh để tối ưu hóa chi phí hoặc độ ổn định và độ tin cậy sẽ trở nên dễ dàng hơn.

#4 – Đề xuất điều chỉnh theo workload requests

Trong các tình huống mà chúng ta cần tăng hoặc giảm các CPU/Memory requests, việc biết rằng nó cần được thực hiện sẽ dễ dàng hơn là biết nó cần được thực hiện như thế nào. Chúng ta nên đặt yêu cầu là gì?

Hình 6 - Đề xuất Vertical Pod Autoscaler cho CPU và memory cho workload 
Hình 6 – Đề xuất Vertical Pod Autoscaler cho CPU và memory cho workload

Hình 6 – Đề xuất Vertical Pod Autoscaler cho CPU và memory cho workload 

GKE tích hợp các đề xuất từ ​​Kubernetes Vertical Pod Autoscaler (VPA) trực tiếp vào bảng điều khiển workload của nó, hiện tại cho tất cả các triển khai trong cluster của bạn. Bạn có thể tìm thấy điều này bằng cách điều hướng đến menu Actions > Scale > Scale compute resources menu khi xem trang cho một workload cụ thể.

Điều quan trọng cần nhớ là những khuyến nghị này chỉ là – khuyến nghị. Chúng dựa trên dữ liệu sử dụng lịch sử, vì vậy, khi xem các giá trị này, điều quan trọng là phải làm việc với chủ sở hữu workload để xem liệu những đề xuất này có phù hợp để kết hợp vào các tệp kê khai Kubernetes tương ứng của họ hay không.

 #5 – Dự toán chi phí và hướng dẫn setup tạo cluster

Cuối cùng, nếu bạn mới bắt đầu với GKE và bạn muốn bắt đầu một cách thuận lợi, được tối ưu hóa, thì Google đã tích hợp công cụ vào trang tạo cluster GKE.

Hình 7 - Hướng dẫn thiết lập tạo cluster (1) và ước tính chi phí tạo cluster (2)
Hình 7 – Hướng dẫn thiết lập tạo cluster (1) và ước tính chi phí tạo cluster (2)

Trước tiên, Google có một hướng dẫn thiết lập sẽ giúp bạn tạo một cluster tiêu chuẩn GKE được đánh giá cao với một số tính năng mà Google đã thảo luận ở đây đã được bật, chẳng hạn như phân bổ chi phí GKE và Bộ tự động chia tỷ lệ nhóm dọc.

Thứ hai, Google cũng có một bảng ước tính chi phí, tùy thuộc vào cấu hình của cluster tiêu chuẩn GKE của bạn, sẽ hiển thị cho bạn chi phí ước tính hàng tháng. Điều này thậm chí còn giúp bạn có được một loạt các chi phí tiềm năng nếu bạn mong muốn cluster của mình tăng và giảm quy mô!

Cloud đã và đang là xu hướng tất yếu trong hệ thống phát triển , tối ưu công nghệ của các doanh nghiệp. Gimasys – Premier Partner của Google tại Việt Nam là đơn vị cung cấp, tư vấn các cấu trúc, thiết kế giải pháp Cloud tối ưu cho bạn. Để biết được hỗ trợ về mặt chuyên môn kỹ thuật, bạn có thể liên hệ Gimasys – Premier Partner của Google tại Việt Nam theo thông tin:

Nguồn: Gimasys

Trở lại đầu trang
0974 417 099