是否可以将自动缩放/v2beta2 HPA 与 apiregistration.k8s.io/v1 APIService 一起使用？

Question

我创建了一个部署，它通过一个端点和一个注册此自定义指标的 APIService 公开自定义指标，因此我可以在 HPA 中使用它来自动扩展部署。为此，我关注了this tutorial。

在使用 apiregistration.k8s.io/v1beta1 APIService 时运行良好。该指标已正确公开，HPA 可以读取它并相应地进行缩放。我尝试将 APIService 更新为 apiregistration.k8s.io/v1 版本（因为 v1beta1 在 Kubernetes v1.22 中已被弃用并删除），但随后 HPA 无法再选择指标，与此消息：

Message
-------
unable to get metric threatmessages: Service on test services-metrics-service/unable to fetch 
metrics from custom metrics API: the server is currently unable to handle the request 
(get services.custom.metrics.k8s.io services-metrics-service)

如果我手动请求该指标，它仍然存在：

kubectl get --raw /apis/custom.metrics.k8s.io/v1/namespaces/test/services/services-metrics-service/threatmessages |jq .
{
  "kind": "MetricValueList",
  "apiVersion": "custom.metrics.k8s.io/v1",
  "metadata": {
    "selfLink": "custom.metrics.k8s.io/v1"
  },
  "items": [
    {
      "metricName": "threatmessages",
      "timestamp": "2021-02-09T14:43:39.321Z",
      "value": "0",
      "describedObject": {
        "kind": "Service",
        "namespace": "test",
        "name": "services-metrics-service",
        "apiVersion": "/v1"
      }
    }
  ]
}

这是我的 APIService 和 HPA 资源：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 1000
  versionPriority: 5
  service:
    name: services-metrics-service
    namespace: test
    port: 443
  version: v1
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: services-parallel-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: services-parallel-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Object
    object:
      describedObject:
        kind: Service
        name: services-metrics-service
      metric:
        name: threatmessages
      target:
        type: AverageValue
        averageValue: 4k
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 1
        periodSeconds: 30

我做错了什么？还是这 2 个版本出于某种原因不兼容？

Answer 1

根据APIService 1.22文档可以找到信息：

• 迁移清单和 API 客户端以使用 apiregistration.k8s.io/v1 API 版本，自 v1.10 起可用。
• 所有现有的持久化对象都可以通过新的 API 访问
• 没有显着变化

首先，v1 适用于您正在使用的版本 (v.1.19)。

其次，更重要的是All existing persisted objects are accessible via the new API 和No notable changes。这意味着使用v1beta1 创建的对象不需要更新或修改。即使它们是使用v1beta1 创建的，它们也将可用并正常工作。也就是说，在升级到版本v 1.22 之后，您应该没有问题，相同的对象将可以简单地访问（并且，我认为，由HPA 访问）就好像它们是使用v1 创建的一样。更重要的是，它们可能已经（在 1.19 版本中）可以作为 v1 访问，我将在下面解释，所以你现在可以检查一切是否正常。

我在v 1.19GKE cluster 上运行了一些快速测试，发现是否有东西包含apiVersion: apiregistration.k8s.io/v1beta1（实际上，使用的正是相关问题中提供的 OP：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 1000
  versionPriority: 5
  service:
    name: services-metrics-service
    namespace: test
    port: 443
  version: v1

除了使用v1beta1作为apiVersion)，然后使用get命令获取创建的 $ kubectl get apiservices/v1.custom.metrics.k8s.io --output=json，会得到一个标有apiVersionv1而不是v1beta1的对象( "apiVersion": "apiregistration.k8s.io/v1")。如果在创建过程中使用apiVersion .../v1 而不是apiVersion: apiregistration.k8s.io/v1beta1，则获得相同的结果。如果其中一个被删除，另一个就消失了。这是幕后的同一个对象。然而它被标记为v1。

鉴于以上所有情况，您应该简单地恢复到使用 v1beta1 部署时所做的工作，因为它可以正常工作，并且会根据 APIService 1.22 文档继续工作。您还可以运行 $ kubectl get apiservices/v1.custom.metrics.k8s.io --output=json 命令，$ kubectl get APIService --output=json 或 $ kubectl get APIService.apiregistration.k8s.io --output=json 一旦部署 v1beta1 版本，以了解对象是否已在幕后标记为使用 v1，尽管已使用 v1beta1 创建对象 - 像在我的情况下正在发生。

如果已经使用v1beta1 创建了对象，则无需使用v1 创建对象。