以声明方式（在 yaml 中）自动扩展 google Cloud-Endpoints 后端部署？

Posted 2023-03-04

【中文标题】以声明方式（在 yaml 中）自动扩展 google Cloud-Endpoints 后端部署？

【英文标题】：Autoscaling a google Cloud-Endpoints backend deployment declaratively (in the yaml)?

【发布时间】：2019-05-06 05:57:16

【问题描述】：

我已成功按照文档 here 和 here 将 API 规范和 GKE 后端部署到 Cloud Endpoints。

这给我留下了一个如下所示的 deployment.yaml：

apiVersion: v1
kind: Service
metadata:
  name: esp-myproject
spec:
  ports:
  - port: 80
    targetPort: 8081
    protocol: TCP
    name: http
  selector:
    app: esp-myproject
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: esp-myproject
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: esp-myproject
    spec:
      containers:
      - name: esp
        image: gcr.io/endpoints-release/endpoints-runtime:1
        args: [
          "--http_port=8081",
          "--backend=127.0.0.1:8080",
          "--service=myproject1-0-0.endpoints.myproject.cloud.goog",
          "--rollout_strategy=managed",
        ]
        ports:
        - containerPort: 8081
      - name: myproject
        image: gcr.io/myproject/my-image:v0.0.1
        ports:
        - containerPort: 8080

这会在后端创建应用的单个副本。到目前为止，一切都很好......

我现在想更新 yaml 文件以以声明方式指定自动缩放参数，以便在到端点的流量证明不止一个时，使应用的多个副本能够彼此并排运行。

我已经阅读过（O'Reilly 的书：Kubernetes Up & Running、GCP 文档、K8s 文档），但有两件事让我很困惑：

我已多次阅读有关 Horizo​​ntalPodAutoscaler 的信息，但我不清楚部署是否必须使用它才能享受自动缩放的好处？ 如果是这样，我在文档中看到了如何在 yaml 中定义 Horizo​​ntalPodAutoscaler 规范的示例，如下所示 - 但我如何将其与现有的 deployment.yaml 结合起来？

Horizo​​ntalPodAutoscaler 示例 (from the docs)：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

提前感谢任何可以为我阐明这一点的人。

【参考方案1】：

我已多次阅读有关 Horizo​​ntalPodAutoscaler 的信息，但我不清楚部署是否必须使用它才能享受自动缩放的好处？

不必这样做，但建议使用它，并且它已经内置。您可以构建自己的自动化来扩大和缩小规模，但问题是为什么，因为它已经受到 HPA 的支持。

如果是这样，我在文档中看到了如何在 yaml 中定义 Horizo​​ntalPodAutoscaler 规范的示例，如下所示 - 但我如何将其与现有的 deployment.yaml 结合起来？

应该是直截了当的。您基本上在 HPA 定义中引用了您的部署：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-esp-project-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: esp-myproject  <== here
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

【参考方案2】：

我遇到了同样的问题，对我有用的是

如果您使用 GKE 并遇到启用 API 的问题

autoscaling/v1
autoscaling/v2beta1

虽然 GKE 版本在 1.12 to 1.14 左右，但您将无法应用 autoscaling/v2beta2 的清单，但是您可以应用类似的东西

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: core-deployment
  namespace: default
spec:
  maxReplicas: 9
  minReplicas: 5
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: core-deployment
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageValue: 500m

如果你想基于利用率

    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    metadata:
      name: core-deployment
      namespace: default
    spec:
      maxReplicas: 9
      minReplicas: 5
      scaleTargetRef:
        apiVersion: extensions/v1beta1
        kind: Deployment
        name: core-deployment
      metrics:
      - type: Resource
        resource:
          name: cpu
          targetAverageUtilization: 80