K8s常见问题分析&解决(未分类问题一)

本文汇总了Kubernetes中常见的16个问题及其解决方法,包括Pod状态异常、集群资源管理、命名空间删除、网络连接失败等,提供了解题思路、原因分析及具体步骤。

1: Pod始终处于pending状态

详细描述:
    Pod始终处于pending状态
解题思路:
    如果pod保持在pending的状态,意味着无法被正常的调度到节点上,由于系统的某些资源无法满足Pod的运行需求
原因分析:
    系统没有足够的资源或者用户指定了hostPort;通过hostPort用户能够将服务暴露到指定的主机端口上,会限制pod被调度到可运行节点上
解决步骤:
    系统没有足够资源的情况,需要清理一些不需要的Pod,调整它们所需的资源量或者向集群中新增加节点

2: Pod始终处于Waiting状态

详细描述:
    Pod始终处于Waiting状态
解题思路:
    Pod处于Waiting的状态,说明已经被调度到一个工作节点, 却无法在那个节点上运行
原因分析:
    可以使用kubectl describe 查看含有更详细的错误信息。一般导致Pod处于waiting的原因为镜像无法下载
解决步骤:
    查看镜像下载情况

3: Pod处于CrashLoopBackOff状态

详细描述:
    Pod处于CrashLoopBackOff状态
解题思路:
    无
原因分析:
    CrashLoopBackOff状态说明容器已经启动,但是又异常导致退出,这个时候Pod的restartCounts通常大于0;
    容器进程退出
    健康检查失败退出
    OOMKilled
解决步骤:
    无

4: Pod一直崩溃或者运行不正常

详细描述:
    Pod一直崩溃或者运行不正常
解题思路:
    可以使用kubectl describe以及kubectl logs排查问题,这个问题存在情况比较复杂
原因分析:
    可能的情况: 健康检测失败,OOM情况,或者容器运行生命周期结束
解决步骤:
    无

 

5:集群雪崩,kubelet预留资源不足

详细描述:
    集群雪崩,kubelet预留资源不足
解题思路:
    无
原因分析:
    原因分析参见网上blog:https://my.oschina.net/jxcdwangtao/blog/1629059
解决步骤:
    为kubelet等进程预留相应的资源,具体操作参加上面的网址

 

6: nfs挂载错误wrong fs type, bad option, bad superblock

详细描述:
    nfs挂载错误wrong fs type, bad option, bad superblock
解题思路:
    无
原因分析:
    根据错误提示, 查看/sbin/mount.<type>文件,果然发现没有/sbin/mount.nfs文件
解决步骤:
    安装nfs-utils 即可

 

7:kube-apiserver accept4: too many open files

详细描述:
    kube-apiserver accept4: too many open files
    http: Accept error: accept tcp 0.0.0.0:6443: accept4: too many open files; retrying in 1s
解题思路:
    无
原因分析:
    查看apiserver 进程, lsof -p $pid, 发现占有65540, 查看cat /proc/$pid/limits发现限制在65536, 查看占用的一大堆10250的某个kubelet,发现如下“device is busy”的错误
解决步骤:
    目前解决方案
    kubectl delete --grace-period=0 --force
    https://github.com/kubernetes/kubernetes/issues/51835

8: kubernetes pod 无法删除,Docker: Device is busy

详细描述:
    kubernetes pod 无法删除,Docker: Device is busy
解题思路:
    登录对应的Node节点,采用docker ps -a 查看对应的docker容器状态,发现容器的状态处于Dead状态,同样使用docker rm <container id>, 提示Device is busy。
原因分析:
    出现Docker: Device is busy 已经停止的docker容器无法删除,可能的原因存在systemd unit file 中带有 PrivateTmp=true 的 serivce,例如ntpd.service,nginx.service,当时在使用docker comose的时候是因为碰巧那台机器上安装了nginx。nginx的systemd文件中有下面的配置:

    [Service]
    PrivateTmp=true 
    这会导致nginx运行在私有挂载命名空间,而docker容器在销毁时需要卸载挂载的磁盘信息,此时出现冲突引起销毁docker容器失败。 当把引起这个问题的nginx关闭后,再使用docker rm <container id>可以将Dead的容器删除,但是当重新启动nginx容器后,后边可能还会出现这个问题。 这个是CentOS/RedHat 3.10.0内核NameSpace的bug;正常由于某个systemd服务PrivateTmp=true引起的
解决步骤:
    网络上出现的Pod无法删除的解决方案:
    https://blog.terminus.io/docker-device-is-busy/
    Docker 故障(device or resource busy)
常见的解决思路:
    首先尝试使用docker rm <containerid>,一般会得到如下的错误:Error response from daemon: driver "overlay" failed to remove root filesystem for cb48a9914c6d9015eef2519f70bed648b070345e5acd271de0a03cb931d78a69: remove     /var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/merged: device or resource busy
    查看对应的挂载信息:
    grep docker /proc/*/mountinfo | grep     /var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/merged
    /proc/168793/mountinfo:3967 3441 0:639 /     /var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/merged rw,relatime shared:415 - overlay overlay rw,lowerdir=/var/lib/docker/overlay/125dad94af82485b8ea6cd3808df431f7180033d278bdadcbc21d7d7054678a4/root,upperdir=/var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/upper,workdir=/var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/work
    从上面的输出结果可以看出当前的进程168793,查看这个进程:
    ps -ef | grep 168793
    ntp      168793      1  0 Feb04 ?        00:00:00 /usr/sbin/ntpd -u ntp:ntp -g
    这里经确认这个进程是ntpd,重启ntpd后再次尝试使用docke rm <containerid>删除容器,一般情况下是可以删除的。
    当然上面在查看对应的挂载信息时,可以能会列出很多信息,这个时候挨个去找出冲突的进程太繁琐了,可以强制                umount无法删除的目录:
    umount -f             /var/lib/docker/overlay/cd38b6e94e55a36b43cefe9cb3a74050fdc485e233c72a1fa125277d6b3f630d/merged
    之后再重新尝试删除容器,重复上边的过程。
    当处于Dead状态的容器清理干净后,使用kubectl将处于Terminating的Pod删除掉即可

9: k8s无法删除namespace 提示Terminating

详细描述:
    k8s无法删除namespace 提示Terminating
解题思路:
    无
原因分析:
    无
解决步骤:
    kubectl get ns <namespace-name> -o json > ns-delete.json
    删除文件中spec.finalizers
    "spec":{},
    备注:在执行命令前,要先克隆一个新的会话,执行kubectl proxy --port=8081
    执行:
    curl -k -H "Content-Type: application/json" -X PUT --data-binary @ns-delete.json http://127.0.0.1:8081/api/v1/namespaces/<namespace-name>/finalize

 

10:Kubernetes: No Route to Host

详细描述:
    Kubernetes: No Route to Host
    Error getting server version: Get https://xx.xx.xx.xx:443/version?timeout=32s: dial tcp xx.xx.xx.xx:443: connect: no route to host
解题思路:
    无
原因分析:
    无
解决步骤:
    iptables -F

 

11: kubeadm kube-controller-manager does not have ceph rbd binary anymore

详细描述:
    kubeadm kube-controller-manager does not have ceph rbd binary anymore 
    Error: "failed to create rbd image: executable file not found in $PATH, command     output: "
解题思路:
    无
原因分析:
    无
解决步骤:
    解决参照文档:https://github.com/kubernetes/kubernetes/issues/56990
    yum install -y ceph-common

 

12: helm报这个错误 Helm: Error: no available release name found

详细描述:
    helm报这个错误 Helm: Error: no available release name found
解题思路:
    无
原因分析:
    因为tiller没有正确的角色权限
    解决步骤:
    kubectl create serviceaccount --namespace kube-system tiller
    kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
    kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

13:  K8s中 pv 无法删除问题

详细描述:
    K8s中 pv 无法删除问题
    Pv始终处于“Terminating”状态,而且delete不掉
解题思路:
    无
原因分析:
    无
解决步骤:
    删除k8s中的记录   kubectl patch pv xxx -p '{"metadata":{"finalizers":null}}'

14:  Error from server: Get https://master-node:10250/containerLogs/default/csi-hostpathplugin-0/node-driver-registrar: dial tcp: lookup master-node on 114.114.114.114:53: no such host

详细描述:
    Error from server: Get https://master-node:10250/containerLogs/default/csi-    hostpathplugin-0/node-driver-registrar: dial tcp: lookup master-node on 114.114.114.114:53: no such host
解题思路:
    无
原因分析:
    无
解决步骤:
    在/etc/hosts 添加192.168.x.x master-node

15:  calico/node is not ready: BIRD is not ready:BGP not established

详细描述:
    calico/node is not ready: BIRD is not ready:BGP not established
解题思路:
    无
原因分析:
    主要原因是calico,没有识别到网卡
解决步骤:
    modified calico.yaml file to include:
    - name: IP_AUTODETECTION_METHOD
    value: "interface=ens.*"

16: 无法删除image报rbd: error: image still has watchers解决方法

详细描述:
    无法删除image报rbd: error: image still has watchers解决方法
解题思路:
    无
原因分析:
    无
解决步骤:
    参照:https://www.cnblogs.com/sisimi/p/7776633.html

 

 

 

 

 

 

 

&lt;think&gt;嗯,用户之前问了后端系统的安全性,现在转向了Kubernetes的常见用法,看来他对系统架构和运维方面比较感兴趣。需要整理k8s的常见用法,可能用户刚开始接触k8s,或者想系统化自己的知识。用户可能是在准备面试,或者在实际工作中需要部署和管理容器化应用,所以需要份清晰的指南。 首先,我得确定用户对k8s的了解程度。之前的回答结构很详细,用户可能期待类似的层次结构。需要覆盖基本概念、核心功能、常用操作、网络存储、运维监控、安全、扩展和生态系统等方面。 要确保回答结构清晰,分点列出,每个部分有子项。例如,核心功能包括部署、扩缩容、配置管理、服务发现、存储管理、自动修复、滚动更新、任务调度。常用操作涉及kubectl命令,可能需要具体例子,但用户可能不需要太详细的命令,而是分类说明。 还要注意用户可能关心的实际应用场景,比如如何做CI/CD集成,监控方案选型,或者安全策略。之前的回答中有提到安全维度,所以在k8s这里也需要涉及RBAC、网络策略、密钥管理等内容。 用户可能还需要了解k8s的生态系统,比如Helm、Operators、Service Mesh等工具,这些能帮助他们扩展功能。另外,常见问题如Pod故障排查、资源优化、网络问题等也是实际使用中会遇到的问题,需要给出解决思路。 需要避免太技术化的术语,但保持专业性。比如解释Deployment和StatefulSet的区别时,要简明扼要。同时,结合之前的回答风格,可能用户喜欢表格和公式,比如在核心功能部分用表格区分控制器类型,或者在资源配额部分用数学表达式。 还要注意用户可能没提到的深层需求,比如如何选择存储类型,或者如何监控集群健康状态,这些在整理常见用法时也应涵盖。最后,确保回答有总结,强调k8s的优势和适用场景,帮助用户形成整体认识。&lt;/think&gt;以下是对Kubernetes常见用法的系统化整理,采用分层结构说明核心功能和应用场景: --- ### 、核心功能模块 | 功能分类 | 实现方式 | 典型应用场景 | 数学表达示例 | |----------------|---------------------------|----------------------------------|-----------------------------------| | **部署管理** | Deployment | 无状态应用滚动更新 | 副本数 $replicas = \lceil \frac{QPS}{1000} \rceil$ | | **有状态服务** | StatefulSet | 数据库集群部署 | 有序编号 $pod\_name = {sts-name}-{0..N-1}$ | | **配置注入** | ConfigMap/Secret | 环境变量动态配置 | 数据映射 $\forall k \in ConfigMap, v \to Pod$ | | **服务发现** | Service/Ingress | 内外网流量路由 | 负载均衡 $endpoints = \sum_{healthy\;pod} ip:port$ | | **存储管理** | PersistentVolume(PV) | 数据库持久化存储 | 容量规划 $PV_{size} \geq \sum_{pod} request_{storage}$ | | **自动扩缩容** | HPA(HorizontalPodAutoscaler) | 应对流量波动 | 扩缩规则 $desiredReplicas = \lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \rceil$ | --- ### 二、常用操作指令 ```bash # 声明式资源管理 $ kubectl apply -f deployment.yaml # 应用YAML配置(幂等操作) # 实时监控与调试 $ kubectl get pods -l app=nginx --watch # 标签筛选+实时状态监控 $ kubectl logs -f pod/nginx-7cdbd8cdc9-zwxrb # 流式日志跟踪 $ kubectl exec -it pod/nginx -- /bin/sh # 进入容器调试 # 集群状态诊断 $ kubectl describe node worker-01 # 节点资源详情分析 $ kubectl top pod --containers # 容器级资源消耗排名 ``` --- ### 三、网络模型实践 1. **Service类型选择矩阵** | 类型 | 流量特征 | 典型场景 | 网络开销 | |--------------|------------------------|---------------------------|----------| | ClusterIP | 集群内部通信 | 微服务间调用 | 低 | | NodePort | 单节点外部暴露 | 开发环境测试 | 中 | | LoadBalancer | 云厂商负载均衡集成 | 生产环境公网访问 | 高 | | Ingress | 七层路由规则管理 | 多域名HTTPS卸载 | 可变 | 2. **网络策略示例** ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy spec: podSelector: matchLabels: app=db ingress: - from: - podSelector: matchLabels: app=api ports: - protocol: TCP port: 5432 # 只允许api服务访问数据库的5432端口 ``` --- ### 四、存储方案选型 1. **存储类(StorageClass)配置维度** - 性能等级:$IOPS \propto \frac{1}{latency}$ - 数据持久性:$RPO \leq 15\text{min}, RTO \leq 5\text{min}$ - 挂载方式:ReadWriteOnce/ReadOnlyMany/ReadWriteMany 2. **典型存储方案对比** | 存储类型 | 适用场景 | 数据致性 | 扩容复杂度 | |----------------|-------------------|--------------|------------| | 本地SSD | 高性能数据库 | 强致性 | 不可扩容 | | Ceph RBD | 通用块存储 | 最终致性 | 动态扩容 | | NFS | 文件共享 | 弱致性 | 手动扩容 | | 云盘(如AWS EBS)| 云环境持久化存储 | 强致性 | 在线扩容 | --- ### 五、运维监控体系 1. **监控指标采集公式** - 节点健康度:$$ \text{NodeScore} = 0.4 \times \text{CPU\_free} + 0.3 \times \text{Mem\_free} + 0.3 \times \text{Disk\_IOPS} $$ - Pod驱逐预测:$$ \text{EvictRisk} = \begin{cases} 1 &amp; \text{if } \frac{current\_memory}{limit} &gt; 0.9 \\ 0.5 &amp; \text{if } \frac{current\_cpu}{limit} &gt; 0.8 \\ 0 &amp; \text{otherwise} \end{cases} $$ 2. **常用工具链组合** ```mermaid graph LR A(Prometheus) --&gt;|采集| B(Node Exporter) A --&gt;|告警| C(AlertManager) D(Grafana) --&gt;|可视化| A E(Fluentd) --&gt;|日志| F(Elasticsearch) ``` --- ### 六、安全加固措施 1. **RBAC权限矩阵** | 角色 | 权限范围 | API资源限制 | |-------------------|------------------------------|----------------------------| | dev-user | 特定namespace的Pod读写 | verbs: get, list, watch | | cluster-admin | 全集群管理权限 | resources: * | | storage-manager | PersistentVolumeClaims管理 | resourceNames: &quot;ssd-*&quot; | 2. **安全基线配置** ```yaml securityContext: runAsNonRoot: true capabilities: drop: [&quot;NET_RAW&quot;] seccompProfile: type: RuntimeDefault ``` --- ### 七、进阶使用模式 1. **Operator设计范式** ```go func Reconcile() error { current := GetCurrentState() desired := CalculateDesiredState() if !reflect.DeepEqual(current, desired) { return UpdateCluster(desired) # 实现声明式状态收敛 } return nil } ``` 2. **混合云调度策略** ```python def schedule_pod(pod): if pod.requires_gpu: return filter_nodes(has_gpu=True) elif pod.low_latency: return min_distance(user_region) else: return cheapest_zone() ``` --- **总结建议**: 生产环境建议采用$GitOps$模式(如Argo CD),配合$Service\;Mesh$(如Istio)实现细粒度流量治理。对于有状态服务,优先使用Operator模式封装领域知识。监控体系应满足$SLO = \frac{成功请求数}{总请求数} \geq 99.9\%$的服务级别目标。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值