K8S-Demo集群实践14:部署集群监控服务Metrics Server

  • K8S资源使用情况的度量(如容器的 CPU 和内存使用)可以通过Metrics API获取
  • metrics-server通过调用Kubelet Summary API获取数据
  • 把master节点也加入集群进行调度,即master节点部署kubelet和kube-proxy,mertics-server组件才能够正常部署

一、下载并解压 Metrics-Server

[root@master1 ~]# cd /opt/install && mkdir -p metrics-server
[root@master1 install]# cd metrics-server
[root@master1 metrics-server]# wget https://github.com/kubernetes-sigs/metrics-server/archive/v0.3.6.tar.gz

二、修改Metrics-Server配置文件

[root@master1 ~]# cd /opt/install/metrics-server/metrics-server-0.3.6/deploy/1.8+/
[root@master1 1.8+]# cp metrics-server-deployment.yaml metrics-server-deployment.yaml.backup
[root@master1 1.8+]# vi metrics-server-deployment.yaml
[root@master1 1.8+]# diff metrics-server-deployment.yaml metrics-server-deployment.yaml.backup
32,38c32,33
<         image: harbor.demo/middleware/metrics-server-amd64:v0.3.6
<         imagePullPolicy: IfNotPresent
<         command:
<         - /metrics-server
<         - --requestheader-allowed-names=k8s-demo-aggregator
<         - --kubelet-insecure-tls
<         - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
---
>         image: k8s.gcr.io/metrics-server-amd64:v0.3.6
>         imagePullPolicy: Always
42,48c37
<         resources:
<           limits:
<             cpu: 500m
<             memory: 500Mi
<           requests:
<             cpu: 200m
<think>嗯,用户提供的日志看起来来自Kubernetes环境中运行的PyTorch Job,可能使用了类似Kubeflow的PyTorch Operator。我需要先解析每条日志的信息,然后逐步分析可能的问题。 首先看时间戳,都是2025年的,但可能是模拟或测试环境中的日志。第一条日志是DEBUG级别,提到没有指定ElasicPolicy或Metric,所以跳过了HPA的协调过程。这里的HPA应该是Horizontal Pod Autoscaler,通常根据指标自动调整Pod数量。没有指定策略或指标,意味着HPA没有被启用,这可能正常,但用户可能需要检查是否本应有HPA配置而遗漏了。 接下来是info级别的Reconciling信息,说明控制器在正常处理任务。然后有两个warning。第一个warning提到任务Master的优先级类找不到,可能是因为在Job配置中指定了PriorityClass名称,但集群中不存在该资源,需要检查YAML中的priorityClassName字段是否正确。第二个warning指出PodGroup处于不可调度状态,这可能涉及资源不足、节点选择器问题或亲和性规则限制,需要进一步查看集群资源状态和Pod的事件日志。 用户可能需要确认HPA配置是否正确,检查PriorityClass是否存在,以及排查Pod无法调度的原因。建议使用kubectl describe命令查看相关资源和事件,以获取更详细的信息。</think>这是一个与 **Kubernetes集群中PyTorch Job调度和弹性伸缩(HPA)** 相关的日志片段,我们可以分步骤解析问题: --- ### 1. 日志背景分析 - **环境**:日志来自Kubernetes集群中运行的PyTorch训练任务(`pytorch-deepspeed-demo`),可能使用了类似Kubeflow PyTorch Operator的框架。 - **时间戳**:`2025-03-14T15:53:59Z`(可能是模拟或测试环境的时间)。 --- ### 2. 关键日志逐条解析 #### (1) 跳过HPA协调 ```log DEBUG No ElasicPolicy or Metric is specified, skipping HPA reconciling process {"pytorchjob": "pytorch-deepspeed-demo"} ``` - **问题**:未配置弹性伸缩策略(`ElasticPolicy`)或指标(`Metric`),导致HPA(Horizontal Pod Autoscaler)无法生效。 - **可能原因**: - Job定义中未声明HPA相关参数(如目标CPU利用率或自定义指标)。 - 集群未安装HPA控制器或指标服务器(如Metrics Server、Prometheus Adapter)。 --- #### (2) 任务调度优先级问题 ```log WARNING Ignore task Master priority class : priorityclass.scheduling.k8s.io "" not found ``` - **问题**:尝试为Master节点设置优先级类(`priorityclass`),但未找到对应的资源。 - **可能原因**: - Job配置中引用了不存在的优先级类(例如YAML中设置了`priorityClassName: high-priority`,但集群未定义该PriorityClass)。 - 未正确配置Kubernetes的调度器(Scheduler)以支持优先级抢占。 --- #### (3) PodGroup不可调度 ```log WARNING PodGroup pipeline/pytorch-deepspeed-demo unschedulable ``` - **问题**:PodGroup(用于批量任务调度的资源组)无法被调度。 - **可能原因**: - **资源不足**:集群没有足够的CPU/GPU或内存资源。 - **节点选择器/亲和性**:Pod的节点选择条件(如`nodeSelector`)与现有节点标签不匹配。 - **污点(Taint)**:节点被标记了排斥性污点(如`NoSchedule`),且Pod未设置对应的容忍(`Toleration`)。 --- ### 3. 解决方案建议 #### 步骤1:检查HPA配置 - 确认Job定义中是否包含HPA策略: ```yaml apiVersion: kubeflow.org/v1 kind: PyTorchJob spec: elasticPolicy: minReplicas: 1 maxReplicas: 4 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 ``` - 安装并验证Metrics Server: ```bash kubectl top node # 检查指标是否可用 ``` #### 步骤2:修复优先级类问题 - 检查集群中已存在的PriorityClass: ```bash kubectl get priorityclass ``` - 在Job配置中移除或修正`priorityClassName`字段。 #### 步骤3:排查PodGroup调度失败 - 查看Pod事件详情: ```bash kubectl describe podgroup pytorch-deepspeed-demo -n pipeline ``` - 检查资源配额和节点状态: ```bash kubectl describe nodes | grep -i &#39;allocatable\|capacity&#39; ``` --- ### 4. 总结 日志表明当前PyTorch Job存在 **HPA配置缺失**、**优先级类引用错误** 和 **资源调度失败** 问题。需依次检查: 1. HPA策略是否正确定义, 2. PriorityClass是否存在, 3. 集群资源是否满足需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值