问题一：腾讯云集群pod无法自动扩缩容

触发问题

在自建Prometheus部署完成之后，集群一直告警

Events:
  Type     Reason                        Age                       From                       Message
  ----     ------                        ----                      ----                       -------
  Warning  FailedComputeMetricsReplicas  7m54s (x182750 over 80d)  horizontal-pod-autoscaler  invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: n
o metrics returned from resource metrics API
  Warning  FailedGetResourceMetric       3m9s (x182769 over 80d)   horizontal-pod-autoscaler  failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API

事件里面报错 unable to get metrics for resource cpu，无法为 cpu 资源获取相应的指标数据。 集群获得指标数据是通过 HPA（Horizontal Pod Autoscaler，Pod 水平自动扩缩器）

问题定位

在上图中可以看到，前两条 API 服务 (v1alpha1.monitor.tencent.io 和 v1beta1.custom.metrics.k8s.io) 背后都指向同一个服务：hpa-metrics-service。意味着集群安装了腾讯云原生的 HPA Metrics 组件。正是这个组件，让你可以在 TKE 控制台和 YAML 里使用那些丰富的扩展指标（如网络流量、磁盘 IOPS 等）来配置 HPA。

v1beta2.metrics.k8s.io也是标准的 Kubernetes 资源指标 API，提供 Pod 和 Node 的 CPU、内存数据。但是它指向了 prometheus-adapter 。这是不合理的，因为自建的prometheus-adapter并没有做 Kubernetes 资源指标 API 的适配，无法提供相关指标。

HPA的核心工作原理

HPA（Horizontal Pod Autoscaler，Pod 水平自动扩缩器）是一项在容器服务 TKE 中实现自动化、弹性伸缩的功能。它能根据实时监控数据（如 CPU 利用率），自动调整服务实例（Pod）的数量，确保业务平稳应对流量波动，同时优化资源使用率。

可以通过下面这张流程图快速了解它的工作原理：

HPA 的工作依赖于三个核心环节的紧密配合：

• 数据采集：HPA 后台组件会每隔15秒向腾讯云可观测平台拉取一次Pod的监控指标数据。

• 动态计算：控制器会根据“期望副本数 = ceil[(当前副本数 × 当前指标值) / 目标指标值]”这个算法进行计算。例如，当前有2个Pod，平均CPU利用率为90%，如果设置的目标值是60%，系统就会尝试将Pod数量调整为 (90% * 2) / 60% = 3个。

• 执行调整：当计算出的期望副本数与当前运行的副本数不一致时，HPA会直接调整对应Deployment的Pod数量来达成目标。

解决方案

根据上文的问题定位（图 e9a9746a...），我们可以得出以下结论：

• v1beta2.metrics.k8s.io（标准资源指标 API）当前指向了自建的 monitoring/prometheus-adapter。

• 自建的 prometheus-adapter 默认并未实现 metrics.k8s.io 接口，因此无法提供 HPA 所需的 Pod CPU、内存指标，导致报错 no metrics returned from resource metrics API。

• 与此同时，集群中腾讯云原生的 HPA 指标组件 hpa-metrics-service (在 kube-system 命名空间下) 是正常运行的。它不仅支持自定义指标，也完全兼容标准的 metrics.k8s.io API。

因此，解决问题的核心思路是：将 v1beta2.metrics.k8s.io API 服务的后端，从错误的 prometheus-adapter 重新指向腾讯云自己的 kube-system/hpa-metrics-service。

步骤一：确认当前 APIService 状态及腾讯云 Metrics Service

输入以下命令进入v1beta1.metrics.k8s.io的配置文件

# 1. 查看所有 metrics 相关的 APIService，确认 v1beta2.metrics.k8s.io 的后端
kubectl get apiservice | grep metrics
​
# 2. 查看腾讯云 metrics service 的详细信息，确认其端口（通常是 443）
kubectl get service -n kube-system hpa-metrics-service

步骤二：修改 APIService 的后端指向

执行以下命令编辑 v1beta2.metrics.k8s.io 的配置：

kubectl edit apiservice v1beta2.metrics.k8s.io

在编辑器中，找到 spec.service 部分，将其修改为指向腾讯云的 hpa-metrics-service。

修改前 (典型错误配置，指向 prometheus-adapter)：

spec:
  service:
    name: prometheus-adapter    # 错误的后端
    namespace: monitoring       # 错误的命名空间
    port: 443

修改后 (正确配置，指向腾讯云服务)：

spec:
  service:
    name: hpa-metrics-service   # 正确的服务名
    namespace: kube-system      # 正确的命名空间
    port: 443                   # 端口保持不变，通常是 443

保存并退出编辑器。

步骤三：验证修改生效并测试 HPA

1. 再次检查 APIService 状态：

   kubectl get apiservice v1beta2.metrics.k8s.io

   确保其状态 (AVAILABLE) 为 True。

2. 直接调用 API，测试能否获取到 CPU 指标：

   # 查询所有 Pod 的 CPU 指标
   kubectl get --raw "/apis/metrics.k8s.io/v1beta2/pods" | jq .

   如果配置成功，该命令应返回集群中 Pod 的 CPU 和内存使用数据（即使数据可能来自腾讯云监控转换）。如果返回空或报错，请检查 Service 名称和端口是否正确。

问题复盘分析

开始部署自建的高可用 Prometheus，其中包含一个关键组件：Prometheus Adapter。

• 它的目的：Prometheus Adapter 本身也可以实现 v1beta1.custom.metrics.k8s.io 和 v1beta2.metrics.k8s.io 这两个 API 接口，作用是将你自建的 Prometheus 里的数据（例如自定义业务指标）转换成 K8s 的 API 格式。

• 问题的关键：当前使用的 Prometheus 安装脚本和 Operator默认会启用 APIService 的自动注册功能。

当 Prometheus Adapter 启动后，它会向 Kubernetes API Server 发起请求，尝试注册 APIService，其中就包括 v1beta2.metrics.k8s.io。

• Kubernetes 的规则：对于同一个 API 服务名称（例如 v1beta2.metrics.k8s.io），集群中只能有一个 APIService 资源。如果新的注册请求来了，原有的 v1beta2.metrics.k8s.io 会被覆盖更新。

• 结果：原先指向 kube-system/hpa-metrics-service 的配置，被修改成了指向 monitoring/prometheus-adapter。

问题二：PVC可用存储告急

问题来源

在当前的Prometheus配置文件中，PVC（持久化存储声明）相关的部分是 spec.storage 字段：

spec:
  storage:
    volumeClaimTemplate:
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi
        storageClassName: cbs

当前的数据保存策略是30天，如下：

retention: 30d   //监控数据保留时间为 30 天，超过 30 天的数据会被自动删除

发现已经占用的存储达到 80GB，处于存储容量的危险边缘。因此急需扩容 PVC 至 200GB。

PVC扩容实现方案

1.1 核心原理

PVC扩容的本质是修改PVC的spec.resources.requests.storage字段，触发底层存储驱动对后端存储卷进行扩展。

1.2 扩容前置条件

在开始扩容之前，需要确保以下条件满足：

1.3 扩容操作流程

步骤一：确认PVC和StorageClass

kubectl get pvc -n monitoring -l prometheus=k8s
kubectl get sc

步骤二：设置StorageClass可扩容

kubectl patch sc <sc-name> -p '{"allowVolumeExpansion": true}'
kubectl get sc //再次查看并确认配置是否成功

步骤三：

编辑PVC对象，修改storage大小即可：

kubectl edit pvc <pvc-name>

将spec.resources.requests.storage修改为目标值后保存。

或者

输入patch指令修改

kubectl patch pvc prometheus-k8s-db-prometheus-k8s-0 -n monitoring \
  -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'
kubectl patch pvc prometheus-k8s-db-prometheus-k8s-1 -n monitoring \
  -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'
kubectl get pvc -n monitoring | grep prometheus-k8s-db

步骤四：

缩容验证清单

# 1. 确认PVC容量已更新
kubectl get pvc -n monitoring -o wide
​
# 2. 确认Prometheus Pod正常运行
kubectl get pods -n monitoring | grep prometheus