每天分享最新软件开发，Devops，敏捷，测试以及项目管理最新，最热门的文章，每天花3分钟学习何乐而不为，希望大家点赞，评论，加关注，你的支持是我最大的动力。下方抖音有我介绍自动化测试，以及google cloud 相关视频课程，欢迎观看。
对于使用Kubernetes的团队来说，合理分配资源请求是一项日益严峻的挑战，在他们扩展环境时尤其重要。过度配置 CPU 和内存会导致代价高昂的超支，但如果请求的资源不足，则配置不足会导致 CPU 节流和内存不足错误。未彻底了解其容器的实时性能概况的开发和工程团队通常会安全行事，并要求比所需更多的 CPU 和内存资源，通常会造成大量预算浪费。
开源 Kubecost 工具 ( https://github.com/kubecost ) 有一个 Request Sizing 仪表板，可帮助 Kubernetes 用户为他们的资源请求带来更高的成本效率。该工具最受欢迎的优化功能之一是仪表板识别过度请求的资源，为每个容器的适当资源请求提供建议，并估计实施这些建议的成本节约影响。仪表板利用来自实时容器的实际使用数据来提供准确的建议。但是，利用仪表板存在一些障碍，需要用户手动更新 YAML 请求以使资源请求与 Kubecost 建议保持一致，或者使用 CD 工具引入集成。
新发布的 Kubecost v1.93 通过引入 1-Click Request Sizing 消除了这些障碍。通过将此功能添加到开源工具中，开发和工程团队可以单击一个按钮来自动应用容器请求正确调整大小的建议。
以下分步示例介绍了过度配置的 Kubernetes 工作负载，并使用 1-Click Request Sizing 将这些请求调整为优化大小。在我们开始之前，您需要使用 Kubernetes 集群。虽然此示例使用 Civo Kubernetes，但 Kubecost 请求大小调整可用于任何 Kubernetes 环境。
要创建示例集群（如果需要），请使用它使用 Civo CLI 创建 civo Kubernetes 集群：
壳
civo k3s 创建 request-sizing-demo --region LON1br集群 request-sizing-demo (84c6c595-505e-4e35-8e38-61364a1a80bc) 已创建现在，让我们开始吧。
如果使用以前的 Kubecost 安装，请使用下面的 helm 值启用集群控制器。
Kubecost 通过将所有集群修改功能保留在单独的集群控制器组件中来确保透明的权限模型。1-Click Request Sizing API 驻留在集群控制器中，因为编辑容器请求需要 Kubernetes API 写入权限。
在这里，我们将安装 Kubecost 并启用集群控制器：
壳
helm repo 添加 kubecost https://kubecost.github.io/cost-analyzer/br掌舵回购更新br掌舵升级\br -我\br --create-namespace kubecost \br kubecost/成本分析器\br --命名空间 kubecost \br --版本 “v1.94.0-rc.1” \br --set clusterController .enabled = true等待容器启动并运行几分钟后，检查 Kubecost 命名空间：
壳
→ kubectl获取部署-n kubecostbr姓名 准备好最新的可用年龄brkubecost 集群控制器 1 /1 1 1 2分12秒brkubecost 成本分析器 1 /1 1 1 2分12秒brkubecost-grafana 1 /1 1 1 2分12秒brkubecost-kube-state-metrics 1 /1 1 1 2分12秒brkubecost-prometheus-服务器 1 /1 1 1 2分12秒在这里，我们看到 Kubecost 已正确安装并运行。
我们将有目的地创建一个请求的资源超出其需要的工作负载，从而使一键式请求大小调整能够发挥作用。以下 bash 创建了一个“rsizing”命名空间，其中包含一个 2 副本 NGINX 部署，具有大量容器资源请求：
壳
brkubectl apply -f - <我们将检查此部署是否已安排并正确运行：
壳
→ kubectl获取pod -n调整大小br姓名 就绪状态 重新开始年龄brnginx-部署-bd6c697bf-qxtvk 1 /1 跑步 0 10sbrnginx-部署-bd6c697bf-b2zml 1 /1 跑步 0 11s接下来，我们将使用JSONPath表达式来检查正在运行的 Pod 及其容器的请求：
壳
→ kubectl get pod -n rsizing -o = jsonpath = "{range .items[*]}{.metadata.name}{' '}{range .spec.containers[*]}{.name}{'\ t'}{.resources.requests}{'
'}{end}{'
'}{end}"brbrnginx-deployment-bd6c697bf-qxtvk nginx { “cpu”：“300m”，“内存”：“500Mi” }brbrnginx-deployment-bd6c697bf-b2zml nginx { “cpu”：“300m”，“内存”：“500Mi” }正如我们计划的那样，容器正在发出超大的资源请求。接下来，我们将解决这些问题。
使用kubectl 的 port-forward访问 Kubecost 的前端：
kubectl port-forward -n kubecost service/kubecost-cost-analyzer 9090
让 Kubecost 有几分钟的时间来收集使用情况分析数据并为请求大小准备其建议。然后转到http://localhost:9090/request-sizing.html?filters=namespace%3Arsizing的请求大小推荐页面。请注意，此链接包含一个过滤器，仅显示“rsizing”命名空间的建议。启用集群控制器后，“自动实施建议”按钮也将在此页面上可用：
NGINX 部署没有获得任何流量，导致它被严重过度配置。Kubecost 认识到这一事实，并建议转向 10m CPU 请求和 20MiB RAM 请求。单击“自动实施建议”按钮，您将收到以下消息：
这些建议被过滤到“rsizing”命名空间，因此单击“是”选项将为该过滤集应用建议。
现在检查集群的状态：
壳
→ k get pod -n rsizing NAME READY STATUS 重新开始年龄brnginx-deployment-574cd8ff7f-5czgz 1 /1 跑步 0 16sbrnginx-deployment-574cd8ff7f-srt8j 1 /1 跑步 0 9sbrnginx-部署-bd6c697bf-qxtvk 0 /1 终止 0 53mbrnginx-部署-bd6c697bf-b2zml 0 /1 终止 0 53m旧 Pod 版本终止后，再次使用 JSONPath 表达式检查新 Pod：
壳
→ kubectl get pod -n rsizing -o = jsonpath = "{range .items[*]}{.metadata.name}{' '}{range .spec.containers[*]}{.name}{'\ t'}{.resources.requests}{'
'}{end}{'
'}{end}"brbrnginx-deployment-574cd8ff7f-5czgz nginx { “cpu”：“10m”，“内存”：“20971520” }brbrnginx-deployment-574cd8ff7f-srt8j nginx { “cpu”：“10m”，“内存”：“20971520” }Kubecost 已成功调整容器请求的大小！在 Pod 和 NGINX 部署级别：
壳
→ k get deploy -n rsizing nginx-deployment -o = jsonpath = '{.spec.template.spec.containers[0].resources}' | jqbr{br “请求”：{br “cpu”：“10m”，br “记忆”：“20971520”br }br}不要忘记在此演示后通过删除测试集群进行清理（避免任何不必要的成本）：
→ civo k3s remove request-sizing-demo --region LON1
此示例演示了 Kubernetes 用户如何通过开源 Kubecost 工具中的一键式请求调整轻松自动优化其资源利用率。要了解更多信息，可在此处获得其他文档：
Kubernetes 成本很容易大规模失控如果没有仔细监控，并且没有迅速解决和补救可能导致失控费用的意外成本中心或错误。使用 Kubernetes 的团队需要实时查看其 Kubernetes 支出的全貌。这种可见性必须包括缩小到考虑外部云服务和基础设施成本的整体视图的能力，以及放大并将成本分配给每个特定部署、服务和命名空间的能力。然后，团队需要工具来采取行动并成功地在其 Kubernetes 实施中追求成本效率优化。在这种情况下，1-Click Request Sizing 为 Kubernetes 用户的武器库添加了一个强大的工具，使得控制 Kubernetes 预算变得更加简单。
| 留言与评论（共有 0 条评论） “” |
