Hướng dẫn cắt giảm chi phí Cloud cho Kubernetes Clusters

toannm

Giới thiệu: Tiết kiệm chi phí Kubernetes clusters

Kubernetes là một nền tảng tuyệt vời để deploy ứng dụng. Nó cung cấp một framework tiện dụng để làm việc, đồng thời đảm bảo rất nhiều cơ sở hạ tầng cấp thấp. Các developers dễ dàng deploy các ứng dụng trên đó. Tuy nhiên, luôn có những sự đánh đổi đi kèm với sự dễ dàng này. Nó rất tiện lợi vì dễ sử dụng và tương thích khi deploy các ứng dụng, người dùng có thể bật ứng dụng mà không tốn nhiều công sức hay cân nhắc. Rất nhiều người dùng cài đặt nhu cầu ở mức cao nhưng thực tế sử dụng lại quá thấp.

Do tính chất chia sẻ vốn có của Kubernetes, thật khó có thể thấy điều gì đang đẩy chi phí cloud lên cao để có thể tìm ra giải pháp.. Bài viết này sẽ phác thảo các phương án tốt nhất giúp giảm chi tiêu trên cloud, bao gồm từ các chiến thuật nguồn mở đến các công cụ trả phí.

Điều cốt lõi cần nắm rõ: chi phí cho cloud đang được tính như thế nào

Bước đầu tiên trong việc kiểm soát chi phí là dành thời gian để hiểu cơ sở hạ tầng và chi phí hiện như thế nào. Cần đánh giá tình hình và sau đó đưa ra quyết định dựa trên dữ liệu thực tế. “ Bạn đo lường được cái gì, bạn quản lý được cái đó”. Cần phải biết những gì diễn ra một cách toàn diện để lập kế hoạch khả thi nhằm cắt giảm chi phí. Điều gì xảy ra nếu chi phí chính không phải từ các phiên bản mà thay vào đó là do người dùng yêu cầu các đĩa EBS rất lớn và nhanh? Nếu không có dữ liệu sử dụng thực tế, việc lập kế hoạch tối ưu hóa có thể sai.

Dashboard hóa đơn của nhà cung cấp cloud có thể chỉ ra chi phí phát sinh hàng tháng trên từng service hoặc bằng các thẻ dựa trên chỉ một hoặc tất cả các cụm Kubernetes:


costs-walkthrough-1-aws-dashboard-1.png


Đây là một điểm khởi đầu tốt để có thông tin tổng thể. Ví dụ trên chỉ ra mức chi đang khoảng 100 đô la / ngày cho tất cả các service trên AWS, hóa đơn hàng tháng tương đương ~ $ 3k. Thông tin này dù sao vẫn khá chung chung, cần tiếp tục đào sâu vào chi tiết.

costs-walkthrough-2-aws-dashboard (2).png


Phân nhóm theo “Service” cung cấp một biểu đồ chi tiết về chi phí hàng ngày chi trả cho từng service. Từ đây có thể thấy rằng “EC2-Other” và “EC2-Instances” chiếm tới hơn 80% chi phí hàng ngày, phần còn lại phân bổ cho một vài mục khác không đáng kể.

Từ điều này, đối tượng cần cắt giảm chính đã được tìm ra là EC2, hãy cùng xem xét kỹ hơn các trường hợp EC2 của tôi.

Vậy “EC-Other” và “Other” thì sao? Tùy thuộc vào chế độ xem, AWS dồn các mục như snapshots, cân bằng tải hoặc NAT gateways vào các danh mục này.

Nếu nhóm theo “User type”, có thể biết thông tin về loại phiên bản và spot nào được tính phí trong một ngày:

costs-walkthrough-3-spot pricing-1.png


Đây là thông tin rất tốt ở phương diện tổng thể nhưng vẫn chưa có thông tin chi tiết nhóm người dùng nào trong Kubernetes cluster đang sử dụng nhiều tài nguyên nhất. Giả sử rằng $ 80 / ngày là quá cao => cần tối ưu hóa chi tiêu trên cloud. Những biểu đồ này chỉ có thể chỉ ra chi phí lớn nhất là gì, nhưng không đưa ra được thông tin nhóm hoặc khách hàng nào chịu trách nhiệm cho nó.

Điều này là do Kubernetes là một hệ thống cluster cho nhiều người thuê. Khối lượng công việc từ các ứng dụng hoặc nhóm khác nhau có thể chạy trên cùng một node, mang lại hiệu quả và khả năng phục hồi tốt hơn bằng cách sử dụng một node cho nhiều mục đích. Tuy nhiên, điều này cũng làm cho việc thanh toán hóa đơn và cơ sở hạ tầng phức tạp hơn.

Để có được thông tin bổ sung cần thiết, cần truy cập Kubernetes và tìm ra rằng: “Cái gì đang chạy trên các node này và nó đang sử dụng bao nhiêu CPU, bộ nhớ và (các) đĩa?”

Công cụ tìm hiểu cách tính hóa đơn cloud

Có nhiều cách khác nhau để hiểu cách phân bổ chi phí Kubernetes:

• Các công ty giám sát cloud lớn như CloudHealth, CloudCheckr và Cloudability cung cấp chức năng giám sát. Họ tính phí theo tỷ lệ thuận với chi tiêu (2,5% chi tiêu) và không cho phép tách rời tính năng này khỏi sản phẩm tổng thể.

• Các cụm trên GKE cung cấp công cụ đo lường chi phí miễn phí. Đây là một ví dụ dashboard trông như thế nào.

• CoreOS cung cấp tùy chọn đo nguồn mở

• ManagedKube cung cấp sản phẩm có tính phí giúp phân bổ chi phí Kubernetes.

Công cụ được sử dụng để đo lường hóa đơn cloud không quá quan trọng, điều quan trọng là xây dựng được khả năng hiển thị chi phí vào các cụm Kubernetes. Khi đã có thông tin chi phí cho mỗi pod, phiên bả và khối lượng liên tục, có thể:

• Tạo kế hoạch để kiểm soát chi tiêu trên cloud

• Nắm được lợi nhuận của sản phẩm trong tình huống nhiều người thuê

• Dự báo và lập kế hoạch ngân sách tốt hơn

Sử dụng Cluster AutoScaler để giảm chi phí Kubernetes


Cluster AutoScaler là một dự án của Kubernetes giúp bạn tự động mở rộng quy mô cloud. Đó là một quá trình được bật bên trong cluster để giao tiếp với API Kubernetes và theo dõi các tín hiệu nhất định. Một trong những tín hiệu đó là các pod trong trạng thái “pending” do không có node nào để Kubernetes lên lịch (chạy).

Bằng cách thực hiện một kubectl get pods, có thể thấy những gì đang được chờ xử lý.

costs-walkthrough-4-kubectl.png


Cluster AutoScaler tính đến những gì cần được bật và liệu các nhóm node có quyền truy cập vào để tăng số lượng node hay không. Nếu nó xác định rằng pod đang cố gắng lên lịch sẽ được lên lịch nếu nó bật một phiên bản mới, theo đó cluster autoscaler sẽ bật một phiên bản.

Bằng cách mô tả một pod chạy lệnh kubectl describe pod <pod name>

Có các sự kiện được liên kết với pod này. Sự kiện này cho biết rằng cluster-autoscaler 'đang mở rộng nhóm phiên bản từ 1 node thành 2 node”

costs-walkthrough-5-autoscaler.png


Làm thế nào là điều này có thể giúp tiết kiệm chi phí?

Đó là một câu hỏi rất hay. Cluster AutoScaler cũng thực hiện điều này ngược lại với các tham số scale-down-* . Cluster AutoScaler sẽ thu nhỏ các node không có gì chạy trên chúng hoặc, tùy thuộc vào việc cài đặt được cung cấp cho cluster autoscaler như thế nào, nó sẽ cố gắng ngưng tụ các pod đang chạy trong các phiên bản khác nhau xuống ít phiên bản hơn.

Đây là một service rất tốt cho cluster vì nó sẽ mở rộng số lượng phiên bản lên xuống theo yêu cầu. Mặc dù công cụ này hoạt động tốt, nhưng nó không phải là hoàn hảo. Cluster AutoScaler khá bảo thủ; hầu hết các lỗi giảm tỷ lệ được thực hiện khá cẩn trọng. Nếu vì bất kỳ lý do gì, nó nghĩ rằng không an toàn để thu nhỏ và nén các pod vào một node, thì nó sẽ không thực hiện. Vì vậy, đôi khi có thể nhìn thấy sự kiện và nghĩ rằng nó nên được giảm quy mô, thì Cluster AutoScaler lại không thực hiện. Cần điều chỉnh các tham số scale-down-* theo ý muốn. Sau đó, có thể tiếp tục tùy chỉnh các hành động Customer AutoScaler để phản ánh cách quản lý cluster

Sử dụng Horizontal Pod Autoscaler để giảm chi phí Kubernetes.

Kubernetes Horizontal Pod Autoscaler giúp mở rộng quy mô deploy dựa trên việc sử dụng CPU. Ở dạng cơ bản nhất, có thể thiết lập nó để mở rộng quy mô deploy khi mức sử dụng CPU tổng hợp vượt quá X và sau đó thu nhỏ lại khi nó đạt đến ngưỡng khác. Điều này cho phép tự động điều chỉnh khối lượng công việc trên CPU bằng cách sử dụng chức năng tích hợp của Kubernetes.

Điều này hoạt động thực sự tốt nếu khối lượng công việc bị ràng buộc CPU và điều chỉnh quy mô trên trục này. Ngoài giờ cao điểm, kỹ thuật này giúp thu nhỏ số lượng pod đang chạy xuống mức thấp nhất như đã cài đặt và sau đó vào giờ cao điểm, nó sẽ tăng lên số lượng tối đa đã đặt. Tất cả điều này được thực hiện tự động không cần tác động nhiều.

Nếu ứng dụng không mở rộng theo trục CPU, có thể sử dụng các thước đo tùy chỉnh. Có một vài tác động nhỏ cần thực hiện: phải chủ động tìm ra số liệu mong muốn và đưa nó ra Kubernetes để Kubernetes điều chỉnh tỷ lệ dựa trên số liệu này. Điều tuyệt vời là Kubernetes framework đã thực hiện hầu hết các công việc khó là hiển thị số liệu. Sau đó, khá đơn giản để sử dụng các cấu hình tương tự để thay đổi quy mô.

Sử dụng AWS Spot Instances để cắt giảm chi phí Kubernetes

Nếu cụm Kubernetes đang chạy trên AWS, có thể sử dụng các Spot instances. Đây là phiên bản dự phòng của AWS, họ cung cấp chúng với mức giá thấp hơn đáng kể. Giá của các Phiên bản Spot dao động dựa trên nhu cầu về một instance type trong một khu vực địa lý và khu vực AWS cụ thể.

Cơ sở của việc hình thành AWS Spot Instance là: Vào các mùa mua sắm cao điểm như Black Friday hoặc Amazon Prime Day, người dùng AWS rất có thể sẽ cần mở rộng hệ thống của họ và yêu cầu nhiều phiên bản EC2 hơn. Điều này có nghĩa là capacity trong một khu vực địa lý / khu vực AWS sẽ thấp. Đổi lại, giá giao ngay tại thời điểm này (Spot price) của các phiên bản sẽ tăng vì nhu cầu tăng trong khi nguồn cung cố định. Nó thậm chí có thể tăng cao hơn giá của EC2 on-demand. Nếu điều này xảy ra, AWS đang gửi tín hiệu giá rất mạnh để người dùng tắt phiên bản Spot!

costs-walkthrough-6-spot-pricing.png


Nếu biết cách tận dụng phiên bản này, khoản tiết kiệm được có thể khá lớn. Từ biểu đồ Lịch sử Spot Instance Pricing (có thể xem được trong bảng điều khiển AWS), giá on-demand cho phiên bản m5.xlarge bình thường là $ 0,1920 / giờ. Giá trung bình trong ba tháng qua trên Spot Instance là khoảng $ 0,090 / giờ. Điều đó có nghĩa là có thể tiết kiệm ~ 50% giá on-demand với Spot Instance nếu người dùng cảm nhận được sự lên xuống của giá cả. Một cách quan trọng để chuẩn bị cho sự biến động của giá Spot Instance là có một kế hoạch để nếu Spot price vượt xa mức muốn đặt giá thầu (có thể xảy ra bất cứ lúc nào), người dùng có cơ chế tự động để chuyển từ sử dụng Spot Instance sang On-Demand Instance hoặc tìm Spot Instance khác để bật.

Sử dụng SpotInst.com

SpotInst.com (không liên kết với AWS Spot Instances) là một tùy chọn trả phí rất tốt để quản lý Spot Instances và On-Demand Instances. Đây là công ty độc quyền Spot Instances. Họ tính phí 10-12% (các giao dịch lớn có thể thương lượng về mức <5%) số tiền tiết kiệm từ việc sử dụng Spot Instances. Mặt khác, nếu cơ sở hạ tầng để sử dụng Spot Instances không được thiết lập sẵn sàng, thì bản chất SpotInst.com chỉ là một service “miễn phí” vì nó làm giảm số tiền tiết kiệm được khi sử dụng Spot Instances. Nếu đã thiết lập cơ sở hạ tầng riêng để sử dụng Spot Instances, câu hỏi chính cần đặt ra là liệu nó có nhiều hơn khoản 10-12có thể tiết kiệm được không?

SpotInst.com giúp duy trì một nhóm các server, có thể là sự pha trộn của Spot hoặc On-Demand Instances. Nếu Spot price vượt quá mức người dùng muốn trả, họ sẽ bật On-Demand lên. Họ có các thuật toán dự đoán rất lạ để dự báo khi Spot price tăng hay giảm. SpotInst.com sau đó sử dụng thông tin này để quản lý, bằng cách bật Spot hoặc On-Demand Instances để thực hiện những gì người dùng đã chỉ định là duy trì số lượng phiên bản ở mức tối thiểu. Chúng cũng được tích hợp với Kubernetes, vì vậy chúng có thể nói cho Kubernetes cluster biết khi chúng lấy một phiên bản ngoại tuyến bằng cách xâu chuỗi nó và rút các pod ra khỏi node đó một cách an toàn thay vì chỉ tắt nó. SpotInst.com là một lựa chọn tốt nếu muốn mua một giải pháp. Nó được xây dựng rất tốt và cung cấp rất nhiều tính năng tuyệt vời.

Nếu muốn tự quản lý thì cũng có các lựa chọn tốt nhưng đòi hỏi khá nhiều về mặt kỹ thuật.

EKS và Spot Fleets

EKS và Spot - Nếu người dùng đang ở trên AWS, có thể đang sử dụng EKS. Với EKS, có thể sử dụng Spot Fleets. Điều này tương tự như tính năng của SpotInst.com. Người dùng cung cấp cho nó số lượng và loại phiên bản mong muốn và Spot Fleet sẽ cố gắng đảm bảo rằng điều đó sẽ xảy ra. Sự khác biệt giữa điều này và sử dụng SpotInst là EKS có nhiều điểm tiếp xúc tích hợp hơn mà người dùng phải tự làm và duy trì. Nếu người dùng có một nhóm DevOps, đây có thể là một dự án tốt để họ đảm nhận.

Bất kể cách deploy như thế nào, sử dụng Spot Instances có thể làm giảm đáng kể chi phí vận hành Kubernetes Cluster. Điều quan trọng cần nhớ là phải chuẩn bị đầy đủ để thực hiện việc này một cách an toàn mà không gây ra gián đoạn khối lượng công việc.

Sử dụng Quotas để giảm chi phí Kubernetes

Hạn ngạch Kubernetes là chức năng riêng cho phép người dùng đặt giới hạn hạn ngạch trên một namespace. Namespace là một cấu trúc logic trong Kubernetes, cho phép tách cluster thành các không gian ‘bán tách biệt’ nhỏ hơn, sau đó cung cấp cho một nhóm một hoặc một vài namespace như: dev, qa, staging, v.v. Sau đó, có thể ủy thác name space đó cho nhóm này toàn quyền kiểm soát nhưng hạn chế bằng cách sử dụng hạn ngạch để họ không thể yêu cầu một nghìn CPU hoặc hàng trăm terrabyte của đĩa.

Các cách giới hạn:

  • Cấu hình
  • Khiếu nại khối lượng liên tục
  • Pods
  • Bộ điều khiển nhân rộng
  • Service
  • Cân bằng tải
  • Nodeports
  • Secrets
Điều cần quan tâm nhất trong bài này là các khoản có tính phí.

Có thể cho rằng các mặt hàng tốn nhiều tiền nhất là CPU, bộ nhớ và đĩa. Có thể đặt một cài đặt giống như trên một namespace:

Mã:
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-one-limit
spec:
   pod: 50
   hard:
   cpu: "10000"
   memory: 200Gi
Điều này sẽ đặt tối đa 10 lõi CPU, 200 GB bộ nhớ và giới hạn tối đa 50 pod trên namespace. Nhóm sẽ có thể yêu cầu số lượng này mà không có vấn đề gì và sau khi vượt qua con số này, sẽ có thông báo lỗi cho nhóm biết rằng họ đã vượt quá hạn ngạch.

Có nhiều tùy chọn khác nhau về cài đặt giới hạn đĩa và thậm chí giới hạn CPU cloud trên namespace.

Nếu thực sự cần kiểm soát chi phí trên Kubernetes, sử dụng Quotas chắc chắn là một trong những công cụ hữu ích để đảm bảo không ai có thể vô tình hoặc cố tình tạo ra 1000 pod với yêu cầu 10 CPU cho mỗi pod!

Sử dụng Pod Request và Limits để giảm chi phí Kubernetes

Kubernetes có các cài đặt cho từng loại deploy có thể đặt yêu cầu tài nguyên (thấp) và giới hạn (cao) cho những gì mỗi pod muốn cho CPU và bộ nhớ. Điều này gián tiếp giúp kiểm soát chi phí trên cụm Kubernetes.

Mã:
apiVersion: v1
kind: Pod | Deployment | Statefulset | Daemonset | etc
metadata:
  name: my-app
spec:
  containers:
  - name: web
    image: web:1.0
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
1028Mi tương đương với 1GB; 500m tương đương với lõi CPU 0,5

Bằng cách thiết lập các “yêu cầu”, mặt hàng này sẽ được đảm bảo ở ngưỡng giới hạn thấp mà nó đã yêu cầu. Kubernetes sẽ không lên lịch (chạy) đơn vị này trừ khi phiên bản có ít nhất là dung lượng miễn phí này.

Các “giới hạn” được cài đặt là một giới hạn cao cho những gì mặt hàng này có thể tiêu thụ. Cần nhớ một số sắc thái của Linux. Mặc dù bộ nhớ được đặt là giới hạn cứng tại số đã cho, CPU thì không. CPU đơn vị có thể sử dụng hết CPU cho đến khi có sự tranh chấp. Sự tranh chấp có nghĩa là các quá trình khác đang yêu cầu thời gian CPU. Khi có sự tranh chấp thì số “giới hạn” này đã bắt đầu có hiệu lực đối với số lượng chu kỳ CPU mà nó sẽ nhận được.

Bằng cách sử dụng hai cài đặt này, số lượng định sẵn được cài đặt vượt mức chấp nhận cho cluster này. Ví dụ và để làm cho mọi thứ đơn giản, giả sử đang chạy 1 node cluster có 1 CPU và 1 GB bộ nhớ.

Để đặt ví dụ về “my-app” trên đây thành cài đặt thận trọng nhất mà không cần cài đặt mặc định quá nhiều cho node, cần cài đặt các yêu cầu tài nguyên thành:

Mã:
resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"
Điều này có nghĩa là trong phiên bản hiện có, có thể lên lịch chính xác 2 trong số các mục này (chỉ là một ví dụ, không tính toán cho các service cluster). Kubernetes sẽ không và không thể lên lịch nhiều hơn hai trong số các mục này trên loại node này.

Nếu muốn làm sâu hơn khi biết rằng hầu hết thời gian ứng dụng này không sử dụng tất cả các tài nguyên được chỉ định và cài đặt sẵn đang có thể cung cấp quá mức:

Mã:
resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
Hướng dẫn cắt giảm chi phí Cloud cho Kubernetes Clusters
Giới thiệu: tiết kiệm chi phí với Kubernetes clusters
Điểm cốt lõi cần nắm rõ: chi phí cho cloud đang được tính như thế nào
Công cụ để tìm hiểu cách tính hóa đơn cloud
Sử dụng Cluster AutoScaler để giảm chi phí Kubernetes
Sử dụng Horizontal Pod Autoscaler để giảm chi phí Kubernetes
Sử dụng AWS Spot Instances để giảm chi phí Kubernetes
Sử dụng SpotInst.com
EKS và Spot Fleets
Sử dụng Quotas để giảm chi phí Kubernetes
Sử dụng Pod Request và Limits để giảm chi phí Kubernetes
Kết luận: chi phí Kubernetes cluster có thể được cắt giảm tới 50-70%
Trợ giúp
Giới thiệu: Tiết kiệm chi phí Kubernetes clusters
Kubernetes là một nền tảng tuyệt vời để deploy ứng dụng. Nó cung cấp một framework tiện dụng để làm việc, đồng thời đảm bảo rất nhiều cơ sở hạ tầng cấp thấp. Các developers dễ dàng deploy các ứng dụng trên đó. Tuy nhiên, luôn có những sự đánh đổi đi kèm với sự dễ dàng này. Nó rất tiện lợi vì dễ sử dụng và tương thích khi deploy các ứng dụng, người dùng có thể bật ứng dụng mà không tốn nhiều công sức hay cân nhắc. Rất nhiều người dùng cài đặt nhu cầu ở mức cao nhưng thực tế sử dụng lại quá thấp.
Do tính chất chia sẻ vốn có của Kubernetes, thật khó có thể thấy điều gì đang đẩy chi phí cloud lên cao để có thể tìm ra giải pháp.. Bài viết này sẽ phác thảo các phương án tốt nhất giúp giảm chi tiêu trên cloud, bao gồm từ các chiến thuật nguồn mở đến các công cụ trả phí.
Điều cốt lõi cần nắm rõ: chi phí cho cloud đang được tính như thế nào

Bước đầu tiên trong việc kiểm soát chi phí là dành thời gian để hiểu cơ sở hạ tầng và chi phí hiện như thế nào. Cần đánh giá tình hình và sau đó đưa ra quyết định dựa trên dữ liệu thực tế. “ Bạn đo lường được cái gì, bạn quản lý được cái đó”. Cần phải biết những gì diễn ra một cách toàn diện để lập kế hoạch khả thi nhằm cắt giảm chi phí. Điều gì xảy ra nếu chi phí chính không phải từ các phiên bản mà thay vào đó là do người dùng yêu cầu các đĩa EBS rất lớn và nhanh? Nếu không có dữ liệu sử dụng thực tế, việc lập kế hoạch tối ưu hóa có thể sai.
Dashboard hóa đơn của nhà cung cấp cloud có thể chỉ ra chi phí phát sinh hàng tháng trên từng service hoặc bằng các thẻ dựa trên chỉ một hoặc tất cả các cụm Kubernetes:

Đây là một điểm khởi đầu tốt để có thông tin tổng thể. Ví dụ trên chỉ ra mức chi đang khoảng 100 đô la / ngày cho tất cả các service trên AWS, hóa đơn hàng tháng tương đương ~ $ 3k. Thông tin này dù sao vẫn khá chung chung, cần tiếp tục đào sâu vào chi tiết.

Phân nhóm theo “Service” cung cấp một biểu đồ chi tiết về chi phí hàng ngày chi trả cho từng service. Từ đây có thể thấy rằng “EC2-Other” và “EC2-Instances” chiếm tới hơn 80% chi phí hàng ngày, phần còn lại phân bổ cho một vài mục khác không đáng kể.
Từ điều này, đối tượng cần cắt giảm chính đã được tìm ra là EC2, hãy cùng xem xét kỹ hơn các trường hợp EC2 của tôi.
Vậy “EC-Other” và “Other” thì sao? Tùy thuộc vào chế độ xem, AWS dồn các mục như snapshots, cân bằng tải hoặc NAT gateways vào các danh mục này.
Nếu nhóm theo “User type”, có thể biết thông tin về loại phiên bản và spot nào được tính phí trong một ngày:

Đây là thông tin rất tốt ở phương diện tổng thể nhưng vẫn chưa có thông tin chi tiết nhóm người dùng nào trong Kubernetes cluster đang sử dụng nhiều tài nguyên nhất. Giả sử rằng $ 80 / ngày là quá cao => cần tối ưu hóa chi tiêu trên cloud. Những biểu đồ này chỉ có thể chỉ ra chi phí lớn nhất là gì, nhưng không đưa ra được thông tin nhóm hoặc khách hàng nào chịu trách nhiệm cho nó.
Điều này là do Kubernetes là một hệ thống cluster cho nhiều người thuê. Khối lượng công việc từ các ứng dụng hoặc nhóm khác nhau có thể chạy trên cùng một node, mang lại hiệu quả và khả năng phục hồi tốt hơn bằng cách sử dụng một node cho nhiều mục đích. Tuy nhiên, điều này cũng làm cho việc thanh toán hóa đơn và cơ sở hạ tầng phức tạp hơn.
Để có được thông tin bổ sung cần thiết, cần truy cập Kubernetes và tìm ra rằng: “Cái gì đang chạy trên các node này và nó đang sử dụng bao nhiêu CPU, bộ nhớ và (các) đĩa?”
Công cụ tìm hiểu cách tính hóa đơn cloud
Có nhiều cách khác nhau để hiểu cách phân bổ chi phí Kubernetes:
• Các công ty giám sát cloud lớn như CloudHealth, CloudCheckrCloudability cung cấp chức năng giám sát. Họ tính phí theo tỷ lệ thuận với chi tiêu (2,5% chi tiêu) và không cho phép tách rời tính năng này khỏi sản phẩm tổng thể.
• Các cụm trên GKE cung cấp công cụ đo lường chi phí miễn phí. Đây là một ví dụ dashboard trông như thế nào.
• CoreOS cung cấp tùy chọn đo nguồn mở
ManagedKube cung cấp sản phẩm có tính phí giúp phân bổ chi phí Kubernetes.
Công cụ được sử dụng để đo lường hóa đơn cloud không quá quan trọng, điều quan trọng là xây dựng được khả năng hiển thị chi phí vào các cụm Kubernetes. Khi đã có thông tin chi phí cho mỗi pod, phiên bả và khối lượng liên tục, có thể:
• Tạo kế hoạch để kiểm soát chi tiêu trên cloud
• Nắm được lợi nhuận của sản phẩm trong tình huống nhiều người thuê
• Dự báo và lập kế hoạch ngân sách tốt hơn
Sử dụng Cluster AutoScaler để giảm chi phí Kubernetes
Cluster AutoScaler là một dự án của Kubernetes giúp bạn tự động mở rộng quy mô cloud.( Nguồn dự án và tài liệu ở đây.) Đó là một quá trình được bật bên trong cluster để giao tiếp với API Kubernetes và theo dõi các tín hiệu nhất định. Một trong những tín hiệu đó là các pod trong trạng thái “pending” do không có node nào để Kubernetes lên lịch (chạy).
Bằng cách thực hiện một kubectl get pods, có thể thấy những gì đang được chờ xử lý.

Cluster AutoScaler tính đến những gì cần được bật và liệu các nhóm node có quyền truy cập vào để tăng số lượng node hay không. Nếu nó xác định rằng pod đang cố gắng lên lịch sẽ được lên lịch nếu nó bật một phiên bản mới, theo đó cluster autoscaler sẽ bật một phiên bản.
Bằng cách mô tả một pod chạy lệnh kubectl describe pod <pod name>
Có các sự kiện được liên kết với pod này. Sự kiện này cho biết rằng cluster-autoscaler 'đang mở rộng nhóm phiên bản từ 1 node thành 2 node”

Làm thế nào là điều này có thể giúp tiết kiệm chi phí?
Đó là một câu hỏi rất hay. Cluster AutoScaler cũng thực hiện điều này ngược lại với các tham số scale-down-* . Cluster AutoScaler sẽ thu nhỏ các node không có gì chạy trên chúng hoặc, tùy thuộc vào việc cài đặt được cung cấp cho cluster autoscaler như thế nào, nó sẽ cố gắng ngưng tụ các pod đang chạy trong các phiên bản khác nhau xuống ít phiên bản hơn.
Đây là một service rất tốt cho cluster vì nó sẽ mở rộng số lượng phiên bản lên xuống theo yêu cầu. Mặc dù công cụ này hoạt động tốt, nhưng nó không phải là hoàn hảo. Cluster AutoScaler khá bảo thủ; hầu hết các lỗi giảm tỷ lệ được thực hiện khá cẩn trọng. Nếu vì bất kỳ lý do gì, nó nghĩ rằng không an toàn để thu nhỏ và nén các pod vào một node, thì nó sẽ không thực hiện. Vì vậy, đôi khi có thể nhìn thấy sự kiện và nghĩ rằng nó nên được giảm quy mô, thì Cluster AutoScaler lại không thực hiện. Cần điều chỉnh các tham số scale-down-* theo ý muốn. Sau đó, có thể tiếp tục tùy chỉnh các hành động Customer AutoScaler để phản ánh cách quản lý cluster
Sử dụng Horizontal Pod Autoscaler để giảm chi phí Kubernetes.
Kubernetes Horizontal Pod Autoscaler giúp mở rộng quy mô deploy dựa trên việc sử dụng CPU. Ở dạng cơ bản nhất, có thể thiết lập nó để mở rộng quy mô deploy khi mức sử dụng CPU tổng hợp vượt quá X và sau đó thu nhỏ lại khi nó đạt đến ngưỡng khác. Điều này cho phép tự động điều chỉnh khối lượng công việc trên CPU bằng cách sử dụng chức năng tích hợp của Kubernetes.
Điều này hoạt động thực sự tốt nếu khối lượng công việc bị ràng buộc CPU và điều chỉnh quy mô trên trục này. Ngoài giờ cao điểm, kỹ thuật này giúp thu nhỏ số lượng pod đang chạy xuống mức thấp nhất như đã cài đặt và sau đó vào giờ cao điểm, nó sẽ tăng lên số lượng tối đa đã đặt. Tất cả điều này được thực hiện tự động không cần tác động nhiều.
Nếu ứng dụng không mở rộng theo trục CPU, có thể sử dụng các thước đo tùy chỉnh. Có một vài tác động nhỏ cần thực hiện: phải chủ động tìm ra số liệu mong muốn và đưa nó ra Kubernetes để Kubernetes điều chỉnh tỷ lệ dựa trên số liệu này. Điều tuyệt vời là Kubernetes framework đã thực hiện hầu hết các công việc khó là hiển thị số liệu. Sau đó, khá đơn giản để sử dụng các cấu hình tương tự để thay đổi quy mô.
Sử dụng AWS Spot Instances để cắt giảm chi phí Kubernetes
Nếu cụm Kubernetes đang chạy trên AWS, có thể sử dụng các Spot instances. Đây là phiên bản dự phòng của AWS, họ cung cấp chúng với mức giá thấp hơn đáng kể. Giá của các Phiên bản Spot dao động dựa trên nhu cầu về một instance type trong một khu vực địa lý và khu vực AWS cụ thể.
Cơ sở của việc hình thành AWS Spot Instance là: Vào các mùa mua sắm cao điểm như Black Friday hoặc Amazon Prime Day, người dùng AWS rất có thể sẽ cần mở rộng hệ thống của họ và yêu cầu nhiều phiên bản EC2 hơn. Điều này có nghĩa là capacity trong một khu vực địa lý / khu vực AWS sẽ thấp. Đổi lại, giá giao ngay tại thời điểm này (Spot price) của các phiên bản sẽ tăng vì nhu cầu tăng trong khi nguồn cung cố định. Nó thậm chí có thể tăng cao hơn giá của EC2 on-demand. Nếu điều này xảy ra, AWS đang gửi tín hiệu giá rất mạnh để người dùng tắt phiên bản Spot !

Nếu biết cách tận dụng phiên bản này, khoản tiết kiệm được có thể khá lớn. Từ biểu đồ Lịch sử Spot Instance Pricing (có thể xem được trong bảng điều khiển AWS), giá on-demand cho phiên bản m5.xlarge bình thường là $ 0,1920 / giờ. Giá trung bình trong ba tháng qua trên Spot Instance là khoảng $ 0,090 / giờ. Điều đó có nghĩa là có thể tiết kiệm ~ 50% giá on-demand với Spot Instance nếu người dùng cảm nhận được sự lên xuống của giá cả. Một cách quan trọng để chuẩn bị cho sự biến động của giá Spot Instance là có một kế hoạch để nếu Spot price vượt xa mức muốn đặt giá thầu (có thể xảy ra bất cứ lúc nào), người dùng có cơ chế tự động để chuyển từ sử dụng Spot Instance sang On-Demand Instance hoặc tìm Spot Instance khác để bật.






Sử dụng SpotInst.com

SpotInst.com (không liên kết với AWS Spot Instances) là một tùy chọn trả phí rất tốt để quản lý Spot Instances và On-Demand Instances. Đây là công ty độc quyền Spot Instances. Họ tính phí 10-12% (các giao dịch lớn có thể thương lượng về mức <5%) số tiền tiết kiệm từ việc sử dụng Spot Instances. Mặt khác, nếu cơ sở hạ tầng để sử dụng Spot Instances không được thiết lập sẵn sàng, thì bản chất SpotInst.com chỉ là một service “miễn phí” vì nó làm giảm số tiền tiết kiệm được khi sử dụng Spot Instances. Nếu đã thiết lập cơ sở hạ tầng riêng để sử dụng Spot Instances, câu hỏi chính cần đặt ra là liệu nó có nhiều hơn khoản 10-12có thể tiết kiệm được không?
SpotInst.com giúp duy trì một nhóm các server, có thể là sự pha trộn của Spot hoặc On-Demand Instances. Nếu Spot price vượt quá mức người dùng muốn trả, họ sẽ bật On-Demand lên. Họ có các thuật toán dự đoán rất lạ để dự báo khi Spot price tăng hay giảm. SpotInst.com sau đó sử dụng thông tin này để quản lý, bằng cách bật Spot hoặc On-Demand Instances để thực hiện những gì người dùng đã chỉ định là duy trì số lượng phiên bản ở mức tối thiểu. Chúng cũng được tích hợp với Kubernetes, vì vậy chúng có thể nói cho Kubernetes cluster biết khi chúng lấy một phiên bản ngoại tuyến bằng cách xâu chuỗi nó và rút các pod ra khỏi node đó một cách an toàn thay vì chỉ tắt nó. SpotInst.com là một lựa chọn tốt nếu muốn mua một giải pháp. Nó được xây dựng rất tốt và cung cấp rất nhiều tính năng tuyệt vời.
Nếu muốn tự quản lý thì cũng có các lựa chọn tốt nhưng đòi hỏi khá nhiều về mặt kỹ thuật.
EKS và Spot Fleets
EKS và Spot - Nếu người dùng đang ở trên AWS, có thể đang sử dụng EKS. Với EKS, có thể sử dụng Spot Fleets. Điều này tương tự như tính năng của SpotInst.com. Người dùng cung cấp cho nó số lượng và loại phiên bản mong muốn và Spot Fleet sẽ cố gắng đảm bảo rằng điều đó sẽ xảy ra. Sự khác biệt giữa điều này và sử dụng SpotInst là EKS có nhiều điểm tiếp xúc tích hợp hơn mà người dùng phải tự làm và duy trì. Nếu người dùng có một nhóm DevOps, đây có thể là một dự án tốt để họ đảm nhận.
Bất kể cách deploy như thế nào, sử dụng Spot Instances có thể làm giảm đáng kể chi phí vận hành Kubernetes Cluster. Điều quan trọng cần nhớ là phải chuẩn bị đầy đủ để thực hiện việc này một cách an toàn mà không gây ra gián đoạn khối lượng công việc.
Sử dụng Quotas để giảm chi phí Kubernetes

Hạn ngạch Kubernetes là chức năng riêng cho phép người dùng đặt giới hạn hạn ngạch trên một namespace. Namespace là một cấu trúc logic trong Kubernetes, cho phép tách cluster thành các không gian ‘bán tách biệt’ nhỏ hơn, sau đó cung cấp cho một nhóm một hoặc một vài namespace như: dev, qa, staging, v.v. Sau đó, có thể ủy thác name space đó cho nhóm này toàn quyền kiểm soát nhưng hạn chế bằng cách sử dụng hạn ngạch để họ không thể yêu cầu một nghìn CPU hoặc hàng trăm terrabyte của đĩa.
Các cách giới hạn:
• Cấu hình
• Khiếu nại khối lượng liên tục
• Pods
• Bộ điều khiển nhân rộng
• Service
• Cân bằng tải
• Nodeports
• Secrets
Điều cần quan tâm nhất trong bài này là các khoản có tính phí.
Có thể cho rằng các mặt hàng tốn nhiều tiền nhất là CPU, bộ nhớ và đĩa. Có thể đặt một cài đặt giống như trên một namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
name: team-one-limit
spec:
pod: 50
hard:
cpu: "10000"
memory: 200Gi
Điều này sẽ đặt tối đa 10 lõi CPU, 200 GB bộ nhớ và giới hạn tối đa 50 pod trên namespace. Nhóm sẽ có thể yêu cầu số lượng này mà không có vấn đề gì và sau khi vượt qua con số này, sẽ có thông báo lỗi cho nhóm biết rằng họ đã vượt quá hạn ngạch.
Có nhiều tùy chọn khác nhau về cài đặt giới hạn đĩa và thậm chí giới hạn CPU cloud trên namespace.
Nếu thực sự cần kiểm soát chi phí trên Kubernetes, sử dụng Quotas chắc chắn là một trong những công cụ hữu ích để đảm bảo không ai có thể vô tình hoặc cố tình tạo ra 1000 pod với yêu cầu 10 CPU cho mỗi pod!
Sử dụng Pod Request và Limits để giảm chi phí Kubernetes
Kubernetes có các cài đặt cho từng loại deploy có thể đặt yêu cầu tài nguyên (thấp) và giới hạn (cao) cho những gì mỗi pod muốn cho CPU và bộ nhớ. Điều này gián tiếp giúp kiểm soát chi phí trên cụm Kubernetes.
apiVersion: v1
kind: Pod | Deployment | Statefulset | Daemonset | etc
metadata:
name: my-app
spec:
containers:
- name: web
image: web:1.0
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"

1028Mi tương đương với 1GB; 500m tương đương với lõi CPU 0,5
Bằng cách thiết lập các “yêu cầu”, mặt hàng này sẽ được đảm bảo ở ngưỡng giới hạn thấp mà nó đã yêu cầu. Kubernetes sẽ không lên lịch (chạy) đơn vị này trừ khi phiên bản có ít nhất là dung lượng miễn phí này.
Các “giới hạn” được cài đặt là một giới hạn cao cho những gì mặt hàng này có thể tiêu thụ. Cần nhớ một số sắc thái của Linux. Mặc dù bộ nhớ được đặt là giới hạn cứng tại số đã cho, CPU thì không. CPU đơn vị có thể sử dụng hết CPU cho đến khi có sự tranh chấp. Sự tranh chấp có nghĩa là các quá trình khác đang yêu cầu thời gian CPU. Khi có sự tranh chấp thì số “giới hạn” này đã bắt đầu có hiệu lực đối với số lượng chu kỳ CPU mà nó sẽ nhận được.
Bằng cách sử dụng hai cài đặt này, số lượng định sẵn được cài đặt vượt mức chấp nhận cho cluster này. Ví dụ và để làm cho mọi thứ đơn giản, giả sử đang chạy 1 node cluster có 1 CPU và 1 GB bộ nhớ.
Để đặt ví dụ về “my-app” trên đây thành cài đặt thận trọng nhất mà không cần cài đặt mặc định quá nhiều cho node, cần cài đặt các yêu cầu tài nguyên thành:
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "512Mi"
cpu: "500m"

Điều này có nghĩa là trong phiên bản hiện có, có thể lên lịch chính xác 2 trong số các mục này (chỉ là một ví dụ, không tính toán cho các service cluster). Kubernetes sẽ không và không thể lên lịch nhiều hơn hai trong số các mục này trên loại node này.
Nếu muốn làm sâu hơn khi biết rằng hầu hết thời gian ứng dụng này không sử dụng tất cả các tài nguyên được chỉ định và cài đặt sẵn đang có thể cung cấp quá mức:

resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"

Các cài đặt này sẽ cho phép 4 trong số các mục này được lên lịch trên node. Hãy nhớ Kubernetes chỉ tìm kiếm các “yêu cầu” (thấp) để đảm bảo nó có thể hoàn thành các mục này trước khi nó lên lịch. Tăng gấp đôi công suất của những gì đang chạy trên node là điều tốt hay xấu? Rất khó để nói do không có nhiều ngữ cảnh như những gì ứng dụng đang làm và cách nó hoạt động. Có lẽ đây là một hệ thống cho phát triển và hiệu suất không phải là vấn đề lớn. Chỉ cần có các mục này và chạy để nó có thể trả lời một vài yêu cầu đi kèm. Điều này chỉ đơn giản thể hiện cách sử dụng các cài đặt này để đặt tỷ lệ over-provisioning.

Kết luận: chi phí Kubernetes cluster có thể được cắt giảm tới 50-70%

Các công cụ độc lập và phụ thuộc cũng có thể sử dụng để giảm đáng kể chi phí Kubernetes. Tóm lại, để có kết quả tốt nhất cần thực hiện:
  1. Hiểu chi tiêu cloud và xác định chi phí lớn nhất đến từ đâu
  2. Xác định công cụ có sẵn nào hữu ích nhất để giảm chi phí
  3. Đừng quên xem xét những yếu tố bất lợi của các công cụ trên để giúp cụm ổn định

 
Top