1

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

它在使用 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

我究竟做错了什么？还是这两个版本由于某种原因不兼容？

4

1 回答 1

0

根据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. 也就是说，升级到 version 之后v 1.22，您应该没有问题，相同的对象将可以简单地访问（并且，我认为，可以通过 访问HPA），就好像它们是使用v1. 更重要的是，它们可能已经（在 version 中1.19）可以访问v1，正如我将在接下来解释的那样，因此您现在可以检查一切是否正常。

我已经对 a 进行了一些快速测试v 1.19 GKE 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

除了使用v1beta1as apiVersion) ，然后使用 get 命令获取创建 $ kubectl get apiservices/v1.custom.metrics.k8s.io --output=json的内容，将获取标记为 apiVersion 的对象v1，而不是v1beta1( "apiVersion": "apiregistration.k8s.io/v1")。如果apiVersion .../v1在创建过程中使用 intead 而不是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- 就像在我的情况下发生的那样。

如果已经使用 .创建对象，v1则不需要创建对象v1beta1。

于 2021-03-09T11:35:53.163 回答