istio: 解决istio-proxy使用了资源配额导致新建pod处于pending状态的问题

本文记录了在mac搭建的istio环境在创建了4个带有istio-proxy的pod后,无法再新建pod的问题,提示 FailedScheduling 0/1 nodes are available: 1 Insufficient cpu. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.,开始查找分析原因,最终找到解决方案。

一、问题背景

创建的pod一直在pending状态
在这里插入图片描述
使用 kubectl describe po 查看下原因

kubectl describe po istio-springboot-demo-b-v1-7cf6979bbd-ct8kr -n istio-demos

输出的原因部分如下:

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  3m    default-scheduler  0/1 nodes are available: 1 Insufficient cpu. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

从Message看,很明显是cpu不够不了,无法调度。为什么会这样呢?
通过下面的步骤查看下node的信息
先查看node

saleson@SalesondeMacBook-Pro demo-b % kubectl get nodes
NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   21d   v1.24.1

再通过下面的命令的查看po使用cpu和内在的情况

kubectl describe node docker-desktop
Capacity:
  cpu:                2
  ephemeral-storage:  61255492Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             8049416Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  56453061334
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             7947016Ki
  pods:               110
System Info:
  Machine ID:                 7679dc44-ba20-41de-afe7-6131f6cdfb01
  System UUID:                25cc4672-0000-0000-aaf7-f9f722a48b3c
  Boot ID:                    72f1a678-b1e3-435a-a235-409592f5bf2b
  Kernel Version:             5.10.104-linuxkit
  OS Image:                   Docker Desktop
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://20.10.17
  Kubelet Version:            v1.24.1
  Kube-Proxy Version:         v1.24.1
Non-terminated Pods:          (20 in total)
  Namespace                   Name                                               CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                               ------------  ----------  ---------------  -------------  ---
  istio-demos                 demo-istio-h5-latest-848b989c99-7rbv7              100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6m34s
  istio-demos                 demo-istio-h5-v1-7fc5575845-5r28k                  100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6m34s
  istio-demos                 istio-springboot-demo-a-latest-64d5cf969f-6r7pf    100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6m22s
  istio-demos                 istio-springboot-demo-a-v1-7d64cc6578-n6rs7        100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6m22s
  istio-system                grafana-6787c6fb46-jklbh                           0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d13h
  istio-system                istio-egressgateway-679565ff87-g8lq7               100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6d14h
  istio-system                istio-ingressgateway-b67d7948d-wfxgb               100m (5%)     2 (100%)    128Mi (1%)       1Gi (13%)      6d14h
  istio-system                istiod-645c8d8598-qmslz                            500m (25%)    0 (0%)      2Gi (26%)        0 (0%)         6d14h
  istio-system                jaeger-5b994f64f4-gvcqt                            10m (0%)      0 (0%)      0 (0%)           0 (0%)         6d13h
  istio-system                kiali-565bff499-bfrhr                              0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d13h
  istio-system                prometheus-74cd54db7f-flppp                        0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d13h
  kube-system                 coredns-6d4b75cb6d-5rqbc                           100m (5%)     0 (0%)      70Mi (0%)        170Mi (2%)     21d
  kube-system                 coredns-6d4b75cb6d-wdh6b                           100m (5%)     0 (0%)      70Mi (0%)        170Mi (2%)     6d14h
  kube-system                 etcd-docker-desktop                                100m (5%)     0 (0%)      100Mi (1%)       0 (0%)         21d
  kube-system                 kube-apiserver-docker-desktop                      250m (12%)    0 (0%)      0 (0%)           0 (0%)         21d
  kube-system                 kube-controller-manager-docker-desktop             200m (10%)    0 (0%)      0 (0%)           0 (0%)         21d
  kube-system                 kube-proxy-tnb9q                                   0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
  kube-system                 kube-scheduler-docker-desktop                      100m (5%)     0 (0%)      0 (0%)           0 (0%)         21d
  kube-system                 storage-provisioner                                0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
  kube-system                 vpnkit-controller                                  0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  --------           --------      ------
  cpu                1960m (98%)   12 (600%)
  memory             3056Mi (39%)  6484Mi (83%)
  ephemeral-storage  0 (0%)        0 (0%)
  hugepages-1Gi      0 (0%)        0 (0%)
  hugepages-2Mi      0 (0%)        0 (0%)
Events:              <none>

可以看到几个用于istio测试的demo的pod都有使用配额,从其中挑选一个pod进行查看

kubectl describe po istio-springboot-demo-a-latest-64d5cf969f-6r7pf -n istio-demos

在这里插入图片描述

找到了使用配额的容器,原来是istio的代理容器(sidecar) : istio-proxy

二、调整istio关于sidecar的资源配额参数

查找参数配置

后来在istio安装包找到关于proxy相关的资源配额参数,文件路径:istio-1.12.9/manifests/charts/istio-control/istio-discovery/values.yaml
resources相关参数:
在这里插入图片描述

动态调整

然后找到了参数所在的文件对于已经在运行的istio环境也无能为力,因为改文件中的参数并不能应用于正在运行的istio环境中,后面找了好久,终于找到一篇华为的文章: 如何调整istio-proxy容器resources requests取值?

这里记录一下

方法一:调整网格中的所有服务

调整后,对已经创建的istio-proxy并不会做改动,但是之后创建的istio-proxy将会使用调整后的参数。

  1. 执行以下命令修改comfigmap
    kubectl edit cm istio-sidecar-injector -n istio-system
    

在这里插入图片描述
可以调整配额大小,也可以删除掉。
本文的实验中,是将之删除掉了。

  1. 重启istio-system命名空间下的istio-sidecar-injector Pod。
    本文中的实验并没有按上述文章中的步骤重启istio-system命名空间下的istio-sidecar-injector,但之后创建的istio-proxy仍是使用调整后的参数。
    也是由于是实验关系,在使用环境建议还是按上述文章中的步骤重启。

  2. 重启业务服务Pod,多实例滚动升级不会断服。

方法二:调整网格中的某个服务
  1. 修改服务的yaml文件
    命令格式:

    kubectl edit deploy <nginx> -n <namespace>
    

    本次实验在namespace istio-demos进行,查看namespace下的deployment

    kubectl get deploy -n istio-demos
    

    输出如下:

    saleson@SalesondeMacBook-Pro istio-discovery % kubectl get deploy -n istio-demos
    NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
    demo-istio-h5-latest             1/1     1            1           3h59m
    demo-istio-h5-v1                 1/1     1            1           3h59m
    istio-springboot-demo-a-latest   1/1     1            1           3h58m
    istio-springboot-demo-a-v1       1/1     1            1           3h58m
    istio-springboot-demo-b-latest   1/1     1            1           27m
    istio-springboot-demo-b-v1       1/1     1            1           27m
    

    使用下命令进入istio-springboot-demo-b-v1的编辑面板:

    kubectl edit deploy istio-springboot-demo-b-v1 -n istio-demos
    
  2. 在spec.template.metadata.annotations下添加如下配置(大小仅供参考,请自行替换)

    	sidecar.istio.io/proxyCPU: 100m
        sidecar.istio.io/proxyCPULimit: 100m
        sidecar.istio.io/proxyMemory: 500Mi
        sidecar.istio.io/proxyMemoryLimit: 500Mi
    

    编辑保存后的结果如下:
    在这里插入图片描述

  3. 修改后服务滚动升级,确保不会断服
    执行如下命令重启deployment

    kubectl rollout restart deployment istio-springboot-demo-b-v1 -n istio-demos
    
  4. 查看修改后的结果
    使用下面的命令查看修改后的配额

    kubectl describe node docker-desktop
    

    在这里插入图片描述

三、提前规划

先调整istio-1.12.9/manifests/charts/istio-control/istio-discovery/values.yaml中关于proxy的配额,再安装istio-discovery

参考

如何调整istio-proxy容器resources requests取值?
Pod滚动重启方法 - 运维笔记

<think>嗯,用户遇到了Milvus的etcd启动报错,显示健康检查失败,连接被拒绝。首先,我需要回忆一下Milvus和etcd的关系。Milvus依赖etcd作为元数据存储,如果etcd出问题,整个系统可能无法正常运行。 接下来,看错误信息里的关键点:Liveness probe failed,还有连接被拒绝。可能的原因有很多,比如etcd服务没有正确启动,网络问题导致无法访问,资源不足,或者配置错误。 先考虑etcd本身的状态。用户可能没有检查etcd的Pod状态,需要确认Pod是否处于Running状态,是否有频繁重启的情况。如果Pod没有运行,可能是资源不足,比如内存或CPU不够,或者存储卷的问题。 然后是网络问题。错误中提到无法建立TCP连接到2379端口,可能etcd的Service没有正确暴露端口,或者网络策略阻止了连接。需要检查Service和Endpoints是否正确,以及网络策略是否允许流量通过。 另外,etcd的日志也很重要。用户应该用kubectl logs命令查看etcd Pod的日志,看看有没有启动时的错误,比如证书问题、节点间通信失败等。如果是集群部署,节点间的网络连通性也需要检查。 资源限制也是一个常见问题。etcd对资源比较敏感,如果内存不足,可能会导致进程被OOMKilled。需要确认Pod资源请求和限制是否合理,适当调整。 还有健康检查的配置。有时候liveness probe的超时时间设置太短,导致在etcd启动较慢时误判为失败。可以适当增加initialDelaySeconds或timeoutSeconds,看看是否有改善。 安全配置方面,etcd可能启用了TLS,而客户端没有正确配置证书,导致连接失败。需要检查etcd的证书配置和Milvus的连接参数是否匹配。 最后,建议用户按照步骤逐一排查:检查Pod状态和日志,确认网络连通性,调整资源限制和健康检查参数,验证安全配置。如果问题依然存在,可能需要更深入的集群诊断,比如检查kube-proxy或CNI插件的问题。</think>以下是针对该问题的逐步分析及解决方案: ============================ ### 关键错误信息解析 ``` Liveness probe failed: {"level":"warn","ts":"2025-03-24T09:05:46.222578Z","logger":"client",...,"error":"rpc error: code = DeadlineExceeded desc = ... connection refused\""} ``` 核心错误为 **etcd 2379端口连接被拒绝**,表明健康检查探测失败。 ============================ ### 第一步:检查etcd基础状态 ```bash kubectl get pods -l app=etcd -o wide # 确认Pod状态是否为Running kubectl describe pod my-release-etcd-0 # 查看Events中是否有异常事件 kubectl logs my-release-etcd-0 # 直接查看etcd容器的日志 ``` *常见现象*:OOMKilled(内存不足)、CrashLoopBackOff(持续崩溃)、Pending资源不足) ============================ ### 第二步:排查网络连通性问题 ```bash kubectl get svc my-release-etcd # 检查Service类型和端口映射 kubectl get endpoints my-release-etcd # 验证Endpoint是否包含正确IP kubectl exec -it busybox -- nc -zv 10.244.70.177 2379 # 测试跨节点网络连通性 ``` *常见问题*:Service未正确暴露端口、节点防火墙规则限制、CNI插件异常 ============================ ### 第三步:检查资源限制配置 ```yaml # 检查Helm values.yaml中etcd资源配置示例 etcd: resources: requests: memory: "4Gi" cpu: "1000m" limits: memory: "8Gi" cpu: "2000m" ``` *注意*:etcd对内存敏感,建议至少分配4GB内存,生产环境需更高配额 ============================ ### 第四步:调整健康检查参数(临时方案) ```yaml # 在Helm values.yaml中添加探针调优 etcd: livenessProbe: initialDelaySeconds: 60 # 延长初始化等待时间 timeoutSeconds: 10 # 适当增加超时阈值 readinessProbe: initialDelaySeconds: 60 timeoutSeconds: 10 ``` *注意*:此调整仅用于缓解健康检查误判,需同步解决根本问题 ============================ ### 第五步:检查证书配置(TLS场景) ```bash kubectl exec -it my-release-etcd-0 -- ls /etc/etcd/tls # 验证证书文件存在性 kubectl describe secret etcd-certs # 检查证书Secret是否有效 ``` *典型错误*:证书过期、SAN列表不包含服务域名、证书链不完整 ============================ ### 高级排查建议 1. 检查etcd数据持久化状态: ```bash kubectl exec -it my-release-etcd-0 -- etcdctl --endpoints=localhost:2379 endpoint status ``` 2. 验证集群节点时钟同步: ```bash kubectl exec -it my-release-etcd-0 -- date && date -u # 检查时区与时钟偏差 ``` 3. 检查内核参数: ```bash sysctl fs.file-max # 建议值 >100000 sysctl fs.inotify.max_user_watches # 建议值 >524288 ``` ============================ ### 典型解决方案汇总 | 问题类型 | 解决方案 | |---------|----------| | 资源不足 | 增加CPU/Memory配额,添加NodeSelector调度到高配节点 | | 网络故障 | 检查Calico/Flannel日志,验证kube-proxy是否正常 | | 数据损坏 | 清理持久化卷并重建StatefulSet(会丢失数据!) | | 配置错误 | 检查Helm values.yaml中的endpoints配置是否包含完整FQDN | 建议按照上述步骤依次排查,重点关注**Pod事件日志**和**etcd容器日志**中的时序关联信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值