时间戳

首页 > 解决方案 > 试图了解多容器部署的资源和限制使用什么值

memory - 试图了解多容器部署的资源和限制使用什么值

问题描述

我正在尝试HorizontalPodAutoscaler为我的应用程序设置自动缩放器，以及DigitalOcean 的自动集群自动缩放

我将在下面添加我的部署 yaml，我也metrics-server按照上面链接中的指南进行了部署。目前我正在努力弄清楚如何确定用于我的 cpu 和内存requests和limits字段的值。主要是由于副本数量可变，即我是否需要考虑每个使用其资源的副本的最大数量或一般部署，我是按 pod 计划还是单独为每个容器计划？

在某些情况下，我在最多可以有两个节点的集群上运行它，每个节点有 1 个 vCPU 和 2GB 内存（因此总共可以是 2 个 vCPU 和 4 GB 内存）。

现在我的集群正在运行一个节点，我kubectl top的 pod 和节点统计信息如下所示：

kubectl 顶部吊舱

NAME                       CPU(cores)   MEMORY(bytes)   
graphql-85cc89c874-cml6j   5m           203Mi           
graphql-85cc89c874-swmzc   5m           176Mi

kubectl 顶级节点

NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
skimitar-dev-pool-3cpbj   62m          6%     1151Mi          73%

我尝试了各种 cpu 和资源的组合，但是当我部署我的文件时，我的部署要么卡在一个Pending状态，要么不断重新启动多次，直到它被终止。我的水平 pod 自动缩放器也将目标报告为<unknown>/80%，但我相信这是由于我resources从部署中删除，因为它不起作用。

考虑下面的部署，我应该查看/考虑什么以确定我的资源的requests最佳价值？limits

从环境变量/服务之类的内容中清除 yaml 后，它按原样工作，但在resources未注释字段时会导致上述问题。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: graphql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: graphql
  template:
    metadata:
      labels:
        app: graphql
    spec:
      containers:
        - name: graphql-hasura
          image: hasura/graphql-engine:v1.2.1
          ports:
            - containerPort: 8080
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          # resources:
          #   requests:
          #     memory: "150Mi"
          #     cpu: "100m"
          #   limits:
          #     memory: "200Mi"
          #     cpu: "150m"
        - name: graphql-actions
          image: my/nodejs-app:1
          ports:
            - containerPort: 4040
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /healthz
              port: 4040
          readinessProbe:
            httpGet:
              path: /healthz
              port: 4040
          # resources:
          #   requests:
          #     memory: "150Mi"
          #     cpu: "100m"
          #   limits:
          #     memory: "200Mi"
          #     cpu: "150m"

# Disruption budget
---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: graphql-disruption-budget
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: graphql

# Horizontal auto scaling
---
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: graphql-autoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: graphql
  minReplicas: 2
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 80

标签： memorykubernetescpudigital-oceanautoscaling

解决方案

如何确定用于我的 cpu 和内存请求和限制字段的值。主要是由于副本数可变，即我是否需要考虑每个使用其资源的副本的最大数量或一般部署，我是按每个 pod 计划还是单独为每个容器计划

请求和限制是 Kubernetes 用来控制 CPU 和内存等资源的机制。

  • 请求是容器保证得到的。如果容器请求资源，Kubernetes 只会将其调度到可以为其提供该资源的节点上。
  • 另一方面，Limits确保容器永远不会超过某个值。容器只允许上升到极限，然后被限制。

副本的数量将由ReplicaController.

当我部署我的文件时，我的部署要么卡在 Pending 状态，要么不断重启多次，直到它被终止。

  • pendingstate 意味着没有可用于调度新 pod 的资源。

  • restarting可能由其他问题触发，我建议您在解决缩放问题后对其进行调试。

我的水平 pod 自动缩放器也将目标报告为<unknown>/80%，但我相信这是由于我从部署中删除了资源，因为它不起作用。

  • 您是对的，如果您不设置请求限制，则所需的百分比将保持未知，并且自动缩放器将无法触发向上或向下缩放。

  • 在这里你可以看到算法负责。

  • Horizo​​ntal Pod Autoscaler将根据 Pod 上的请求使用百分比触发新的 Pod。在这种情况下，只要 pod 达到最大请求值的 80%，它就会触发新的 pod，直到指定的最大值。

有关一个好的 HPA 示例，请查看此链接：Horizo​​ntal Pod Autoscale Walkthrough

但是 Horizo​​ntal Pod Autoscaler 如何与Cluster Autoscaler 协同工作？

  • Horizo​​ntal Pod Autoscaler 根据当前 CPU 负载更改部署或副本集的副本数。如果负载增加，HPA 将创建新的副本，集群中可能有也可能没有足够的空间。

  • 如果没有足够的资源，CA 会尝试启动一些节点，以便 HPA 创建的 pod 有运行的地方。如果负载减少，HPA 将停止一些副本。结果，一些节点可能会变得未充分利用或完全空置，然后CA将终止这些不需要的节点。

注意：关键是根据您的应用程序可用的节点数量（和预算）在集群级别设置 HPA 的最大副本数，您可以开始设置非常高的最大副本数，监控然后根据需要进行更改使用指标和未来负载的预测。

如果您有任何问题，请在评论中告诉我。

推荐阅读