HPA的target显示unknown

最新推荐文章于 2024-07-17 19:59:37 发布
原创 最新推荐文章于 2024-07-17 19:59:37 发布 · 2.7k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #HPA

本文详细讲述了如何解决Kubernetes HPA显示unknown的问题，重点在于确认metrics-server运行状态并补全资源请求，确保istio和jaeger-collector的Deployment配置正确。

背景

HPA显示异常，TARGETS部分显示unknown。

[root@a1 ~]# kubectl get hpa -n istio-system 
NAME                   REFERENCE                         TARGETS                        MINPODS   MAXPODS   REPLICAS   AGE
istio-ingressgateway   Deployment/istio-ingressgateway   7%/80%                         1         5         1          11d
istiod-1-11-2          Deployment/istiod-1-11-2          1%/80%                         1         5         1          11d
jaeger-collector       Deployment/jaeger-collector       <unknown>/90%, <unknown>/90%   1         5         1          11d

分析

HPA，全称为Horizontal Pod Autoscaler，是kubernet

最低0.47元/天 解锁文章
【K8S问题系列 | 6】Kubernetes pod节点Unknown 问题【已解决】
颜淡慕潇
11-09 5740
在 Kubernetes 中，Pod 的状态为 **`Unknown`** 表示无法获取 Pod 的当前状态。这通常意味着 Kubernetes API 服务器无法与 Pod 所在的节点通信，或者 Kubelet 进程遇到问题。以下将详细介绍 Unknown 状态的原因、解决方案以及如何配置健康检查以提高系统的稳定性。
k8s之HPA（Pod水平自动伸缩）
jialiu111111的博客
05-10 1722
CPU utilization的计算方法是用cpu usage（最近一分钟的平均值，通过metrics可以直接获取到）除以cpu request（这里cpu request就是我们在创建容器时制定的cpu使用核心数）得到一个平均值，这个平均值可以理解为：平均每个Pod CPU核心的使用占比。如上，设置了f1的deployment控制的pod的HPA限制，当cpu使用超过设置的80%，内存使用超过30Mi时就触发自动扩容，副本数最小为1，最大为2。autoscaling/v1只支持基于CPU指标的缩放；
k8s平台实现HPA过程中问题排查
日常不知道起昵称的博客
10-18 922
k8s平台实现HPA过程中问题排查背景问题描述问题分析解决问题 背景 最近在着手学习HPA的过程，HPA需要metric-service进行采集数据。在实现过程中，遇到了一些问题，进行解决。 问题描述 查看当前HPA的情况。 (base) root@gzk8s-master1:/home/cyye# kubectl get hpa -A NAMESPACE NAME REFERENCE TARGETS
HPA TARGETS目标显示的unknown
heiwa110的博客
12-06 872
原因是没有为pod设置资源配额 CPU、内存的的单位有： 正实数，代表分配几颗CPU，可以是小数点，比如0.5代表0.5颗CPU，意思是一 颗CPU的一半时间。2代表两颗CPU。 正整数m，也代表1000m=1，所以500m等价于0.5。 Mem表示如下： Mi表示(1Mi=10242014)，M表示(1M=10001000)，其他单位类推(K、M、G、T、P、E) deploy.yam...
记录一条HPA：TARGETS ＜unknown＞/50%解决方法
cuiwangfeng的博客
08-19 1967
前言：我已经安装了metrics-server可以正常获取到pod资源分配情况如下： 这里我已经加入了PHA弹性伸缩但是查看结果如下： 于是我查看了一下pod详细信息发现：HPA无法通过API获取到metrics值。 使用kubectl describe命令：信息如下 解决方法如下： 在 /opt/kubernetes/cfg/kube-controller-manager.conf 配置文件中新增 --horizontal-pod-autoscaler-use-rest-clients=false 配置参
hpa的target为unknown
阿白，
03-03 513
hpa对应的下层RS或Deployment的pod模板下de1container设置要写上requests和limits的配置， 最重要的，控制器不要使用通用标签，着点很容易报错 hpa需要metrics server获取的数据来计算，而这些对象间的匹配底层应该就是通过标签来匹配，不是简单的在hpa配置文件中指定控制器就可以(没有深究,记录个坑) hpa其实一般，建议使用别的方案 ...
[AWS]EKS启动HPA，HPA指标＜unknown＞，报错：error: Metrics API not available
China_Yanhy的博客
07-17 854
（Metrics Server 是 Kubernetes 集群的一个关键组件，它负责收集和提供节点和 Pod 的资源使用数据）只需要requests字段就可以成功，不需要limit字段，重新部署之后可以看到<unknown>消失了。背景：在AWS上创建的EKS集群，想要对于deployment部署HPA，来autoscling副本数。部署完成之后，使用命令：kubectl get hap -n 命名空间，就可以查看了。如何查看集群有无：Metrics Server。不用尝试其他办法了，就是这个原因。
配置hpa后，target显示＜unknown＞/50%
u012140251的博客
10-16 935
大意是说hpa是按照pod label查找的，于是根据bill的pod label查询出来发现还多了一个pre-job pod，这个pre-job是升级的时候用来更新数据库/crd等资源的pod。网上查了hpa的文档后，发现是Deployment里面没有配置resource request/limit。然后给对应的这个pre-job 模板里也加上resource request/limit后，确实可以了。
K8S（5）HPA
礁之的博客
07-30 555
K8S中HPA水平Pod自动伸缩器的概述以及使用方法，其中包含创建metrices-server的步骤以及完整yaml文件
解决kubernetes中hpa没生效问题
u012803274的博客
12-09 5693
前言 今天我正在专心致志的敲go代码的bug，突然同事问到我们现在的服务数量太多了，同一个服务的实例pod数可能达到了十几个，能不能放在一个pod中，跑多个container的形式运行。当时我想了一下，就回答了：放在一个pod里边，这些container管理起来可能比较复杂一些，pod挂掉，所有的container都卒了，粒度太大。然后正准备继续写bug的时候，突然想到同事这么问的目的可能是性能优化，自然而然的就想到hpa了，联想到istio和knative的hpa问题还没解决，卒，好吧，来解决问题吧。 问
通过prometheus实现k8s hpa自定义指标 (二)
polarwu的博客
11-26 2276
上一篇通过prometheus实现k8s自定义hpa (一)，部署了prometheus和k8s-prometheus-adapter，实现基于prometheus的hpa自定义指标扩缩容。通过安装组件和演示应用podinfo，最后再配置podinfo的hpa yaml文件，再配合我们的压测程序就能实现pod自动扩缩容。虽然k8s的hpa controller能够实现我们的预期，但是在跟着教程验证...
部署k8s报错：unknown container “/system.slice/kubelet.service”
sfdst的博客
03-07 926
部署k8s报错：unknown container “/system.slice/kubelet.service” 原因：kubernetes和docker版本兼容性问题（有可能是k8s版本太高,docker版本太低的问题） 解决方法：修改kubelet配置文 因为我是用kubeadm装的，所以不是这样配置的，通过查看/etc/systemd/system/kubelet.service.d/10-kubeadm.conf 得出结论： vim /var/lib/kubelet/kubeadm-fl
关于本地k8s部署metrics-server的no such host问题
为梦想奋斗
02-25 5123
我的k8s版本是1.17.0，本地k8s部署metrics-server无法度量到数据，HPA显示unknow。 通过命令 kubectl logsmetrics-server-dc6fb55f4-z88lm -n kube-system 可以看到类似如下错误 E0225 02:30:52.433523 1 manager.go:111] unable to fully coll...
Kubernetes Pod水平自动伸缩（HPA）
运维相关技术闲聊，专业背锅内容媒体
09-30 368
HPA简介 HAP，全称 Horizontal Pod Autoscaler， 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 除了 CPU 利用率，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。 Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性的调整副本控制器或
k8s hpa无法获取数据问题
砚墨
12-08 2168
问题：k8s hpa failed to get cpu utilization: missing request for cpu HPA的监控数据current字段显示为unknown kubectl describe hpa activator -n knative-serving Name: activator Namespace:
Kubernetes实录-第一篇-集群部署配置(19) Kubernetes配置HPA实现应用横向扩展（autoscale）
新梦易明
02-14 4768
容器平台Kubernetes当前已经1.13.x版本了，将原来的1.11.3文档进行更新，希望把 K8S实录 写成一个系列（希望能坚持下来），希望完成2个目标：1. 记录下自己学习K8S的过程,为之后的学习使用差缺补漏 2.如果能为新接触K8S的朋友提供些帮助那就更好了 第一篇：配置企业级镜像仓库Harbor 第二篇：配置企业级镜像仓库harbor升级版本 第三篇：Kubernetes中一些...
k8s- unknown问题排查
lanwp5302的博客
03-13 4618
一、问题描述 kubernetes pod NodeLost 分析 环境 系统: centOS7 k8s 1 master, 2 node IP k8s master 176 k8s node 175 k8s node 176 kubelet、kube-proxy、kube-dns直接安装在linux系统上 问题 卸载监控时,一直一些组件未删除（正常是所有相关组...
k8s学习(九) 使用metrics-server 进行hpa扩容
文若书生的专栏
08-30 2048
Horizontal Pod Autoscaling（Pod水平自动伸缩），简称HPA。HAP通过监控分析RC或者Deployment控制的所有Pod的负载变化情况来确定是否需要调整Pod的副本数量，这是HPA最基本的原理。 当你创建了HPA后，HPA会从metrics-server或者用户自定义的监控获取每一个一个Pod利用率或原始值的平均值，然后和HPA中定义的指标进行对比，同时计算出需要伸...
k8s自定义指标hpa
最新发布
04-20
<think>好的，我现在需要帮助用户解决在Kubernetes中为HPA配置自定义指标的问题，并提供YAML示例和配置教程。首先，我应该回顾用户提供的引用内容，确保我的回答符合他们的需求。 用户引用了四篇资料，其中提到HPA的自定义指标需要从Prometheus获取，使用Prometheus Adapter，并且HPA的API版本需要注意。用户之前的提问涉及到VPA的配置，现在转向HPA的自定义指标，所以需要区分两者的不同，避免混淆。 首先，用户想要YAML示例和教程，所以需要分步骤讲解。根据引用[1]，搭建自定义指标HPA需要部署Prometheus、ServiceMonitor、Prometheus Adapter，配置规则，然后创建HPA。引用[4]提到Custom Metrics APIServer的作用，这应该是关键部分。 接下来，我应该确保使用正确的HPA API版本。引用[2]指出autoscaling/v2beta2支持外部指标，所以用户需要这个版本。在YAML中，必须指定apiVersion: autoscaling/v2beta2或更高，如果用户集群支持v2的话。 然后，自定义指标的类型在HPA中如何定义？引用[3]提到Pod自定义指标和Object自定义指标，因此在YAML中需要选择正确的类型（Pods或Object）。例如，使用类型Pods来扩缩基于每个Pod的请求数。 Prometheus Adapter的配置规则是关键，引用[4]说明需要将Prometheus查询映射到Kubernetes的指标。需要提供一个示例规则，比如将http_requests_total转换为requests_per_second，并展示如何编写configMap。 部署步骤需要详细列出，包括安装Prometheus、配置ServiceMonitor、部署Adapter，然后创建HPA。用户可能需要知道如何验证配置是否生效，如使用kubectl get --raw命令检查指标是否可用。 注意事项部分，需要提到HPA和VPA的冲突（用户之前的问题涉及VPA），所以需要强调不要同时使用基于CPU/内存的HPA和VPA，引用之前的回答内容。另外，指标名称的匹配和Prometheus查询的正确性也很重要。 最后，生成相关问题，帮助用户进一步探索，比如如何验证指标是否生效、如何调试、与VPA的协同等。这些问题需要基于用户可能遇到的后续疑问来设计。 现在需要整合这些信息，确保结构清晰，步骤明确，YAML示例正确，并且引用相关的参考资料。同时，使用用户提到的微服务场景，让示例更贴近实际应用。</think>#### Kubernetes HPA 自定义指标配置详解与 YAML 示例 以下是基于 **Prometheus 的自定义指标 HPA 配置全流程**，结合引用[1][3][4]的实践要点，包含完整 YAML 和关键步骤说明： --- ### 一、核心组件架构 ``` Prometheus（采集指标） ↓ Prometheus Adapter（转换指标为 Kubernetes API 格式） ↓ HPA Controller（根据指标触发扩缩容） ``` --- ### 二、完整配置流程（含 YAML 示例） #### 步骤 1：部署 Prometheus（使用 Helm） ```yaml # values-prometheus.yaml（关键配置） alertmanager: enabled: false pushgateway: enabled: false serviceMonitor: # 自动创建 ServiceMonitor 对象 interval: 15s scrapeTimeout: 10s ``` 部署命令： ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus prometheus-community/prometheus -f values-prometheus.yaml ``` #### 步骤 2：配置 ServiceMonitor（引用[1]） ```yaml # service-monitor.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: myapp-monitor spec: endpoints: - port: web # 对应 Service 的端口名称 interval: 15s # 与 HPA 探测周期对齐[^3] path: /metrics # 应用暴露指标的路径 selector: matchLabels: app: myapp # 关联目标 Service 的标签 ``` #### 步骤 3：部署 Prometheus Adapter（关键配置） ```yaml # prometheus-adapter-values.yaml rules: default: false custom: - seriesQuery: 'http_requests_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)' ``` 部署命令： ```bash helm install prometheus-adapter prometheus-community/prometheus-adapter -f prometheus-adapter-values.yaml ``` #### 步骤 4：创建 HPA（核心 YAML） ```yaml # hpa-custom-metrics.yaml apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second # 与 Adapter 配置的 name.as 匹配 target: type: AverageValue averageValue: 100 # 当单个 Pod 的 QPS > 100 时触发扩容 ``` --- ### 三、关键验证命令 1. **检查指标是否暴露**（引用[4]）： ```bash kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta2/namespaces/default/pods/*/http_requests_per_second" ``` 2. **查看 HPA 状态**： ```bash kubectl describe hpa myapp-hpa # 观察 Metrics 和 Events ``` --- ### 四、注意事项 1. **API 版本选择**（引用[2]）： - 必须使用 `autoscaling/v2beta2` 或更高版本以支持自定义指标 - 旧版本 `v1` 仅支持 CPU 扩缩 2. **指标命名规范**： - Prometheus Adapter 的 `name.as` 字段决定最终指标名称 - 必须与 HPA YAML 中的 `metric.name` 完全匹配 3. **与 VPA 的冲突**（引用历史回答）： - 禁止同时使用基于 CPU/内存的 HPA 和 VPA - 替代方案：HPA 使用业务指标（如 QPS），VPA 管理资源请求 --- ### 五、典型问题排查 | 现象 | 可能原因 | 解决方案 | |-----------------------|----------------------------|----------------------------------| | HPA 显示 `<unknown>` | Prometheus Adapter 未配置正确 | 检查 Adapter 日志和 metrics API 可用性 | | 指标数值为 0 | ServiceMonitor 选择器错误 | 验证 Service 标签与 ServiceMonitor 匹配 | | 扩缩延迟高 | Prometheus 采集间隔过长 | 调整 `serviceMonitor.interval` 至 ≤15s[^3] | ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值