云容器引擎提供了诸多类型的组件，涵盖容器核心组件、应用管理、日志监控、存储等方面，用户可以根据需求进行相应组件的安装、卸载、实例查看等。
本文所涉及组件可以在指定容器集群——“插件”——“插件市场”获取插件列表，主要介绍插件安装及使用过程中常见的问题及分析流程。
插件状态
云容器引擎插件状态如下：
| 插件状态名称 | 插件状态值 | 插件状态含义 |
|---|---|---|
| 安装中 | pending-install | 插件相关资源已提交到Kubernetes集群中，相关工作负载正在等待安装或安装中 |
| 已安装 | deployed | 插件相关资源已提交到Kubernetes集群中，相关工作负载(除DaemonSet外)的Pod在集群中已正常Running |
| 安装失败 | failed | 插件相关资源在提交到Kubernetes集群过程中出现异常，导致插件安装失败 |
| 卸载中 | uninstalling | 插件相关资源正在清理中 |
| 升级中 | pending-upgrade | 插件相关资源已提交到Kubernetes集群中，相关工作负载正在等待升级或升级中 |
| 回滚中 | pending-rollback | 插件相关资源已提交到Kubernetes集群中，相关工作负载正在等待回滚或回滚中 |
| 部分就绪 | available | 插件相关资源已提交到Kubernetes集群中，相关工作负载在集群中至少存在一个非Running状态的Pod |
| 不可用 | unavailable | 插件相关资源已提交到Kubernetes集群中，相关工作负载的所有Pod在集群中均未Running |
安装失败
插件实例状态为"安装失败"时，在插件实例列表中查看该插件的日志和事件可初步了解部署失败的原因。
常见的插件安装失败原因如下：
| 插件名称 | 插件安装日志 | 插件安装事件 | 安装失败原因 | 解决办法 |
|---|---|---|---|---|
| cstor-csi | no matches for kind “PodSecurityPolicy” in version “policy/v1beta1 | 无 | 在Kubernetes v1.25集群上安装cstor-csi v3.1.0版本报错，报错原因是cstor-csi插件安装会部署PodSecurityPolicy资源，但该PodSecurityPolicy资源在v1.25中已被k8s官方移除。 | 1、将cstor-csi升级至3.2.0，按原参数安装即可。 2、如不希望进行组件升级，可以在安装/重新安装时将value.yaml中podSecurityPolicy.enabled配置为false。 |
| cube-openkruise、cert-manager、coredns、kube-proxy等 | Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: annotation validation error: key "meta.helm.sh/release-name" must equal "xxxx": current value is "yyyy"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "xxxx": current value is "yyyy" rendered manifests contain a resource that already exists. Unable to continue with install | 无 | 该集群中已经存在通过其他方式创建的同名的工作负载。 | 检查该同名工作负载是否被业务正常使用，如果同名工作负载正常使用，且提供与插件一致的功能，可考虑无需安装插件，继续使用原有工作负载；如果同名工作负载未在使用，可考虑将其删除后重装插件。 |
部分就绪/不可用
插件实例状态为"部分就绪/不可用"时，说明插件中的工作负载至少有1个Pod未处于Running状态。可切换到工作负载-无状态/有状态/守护进程/任务/定时任务/容器组页面，切换命名空间查看插件工作负载的Pod状态，查看异常状态的Pod事件及日志中的报错信息。
常见的Pod未就绪原因如下：
| Pod状态 | Pod日志 | Pod事件 | 未就绪原因 | 解决办法 |
|---|---|---|---|---|
| Pending | 无 | 0/1 nodes are available: 1 node(s) were unschedulable. | 找不到合适的节点调度，如：节点开启了禁止调度、节点配置了污点、所有节点资源紧张、只有一个可调度节点但pod副本数大于1且开启了Pod强制反亲和(常见于nginx-ingress-controller) | 结合实际业务情况，可考虑关闭节点禁止调度、移除节点污点、扩容节点 |
| CrashLoopBackOff | failed to get auth info, please ensure that aksk is specified or delegate service is ready | Back-off restarting failed container | 一般是因为集群所在资源池不支持委托(常见于elb-ingress-controller、cloud-controller-manager、cstor-csi、cubecni、cube-cluster-autoscaler等需要与天翼云IAAS资源交互的插件) 可在集群主机上执行curl -v http://169.254.169.254/delegate-acquire 返回No delegate data in instance时表明该资源池不支持委托 | 重新安装插件，在values.yaml中填写租户ak/sk信息 |
| CrashLoopBackOff | Cloud provider could not be initialized: could not init cloud provider "ctyun": failed to get temp ak/sk from metadata: metadata service returned empty ak/sk | Back-off restarting failed container | 同上 | 同上 |
| CrashLoopBackOff | Get \"https://10.96.0.1:443/api?timeout=3s\": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) | Readiness probe failed: dial tcp [::1]:9081: connect: connection refused | pod内通过10.96.0.1:443访问集群kube-apiserver所在的service超时，一般为安全组/ACL未放通、kube-proxy异常或kube-apiserver异常导致 | 1、检查集群节点的安全组规则、ACL规则是否有拦截； 2、查看kube-proxy、kube-apiserver Pod日志，检查是否有异常错误日志； 3、结合业务实际情况尝试重启kube-proxy相关Pod |
| ContainerCreating | 无 | Pod sandbox changed, it will be killed and re-created. 或者 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "": plugin type="cubecni" failed (add): rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial unix /var/run/cubecni/cube.socket: connect: no such file or directory" | 原因是Pod创建过程中，网络插件初始化异常 | 检查网络插件如cubecni对应的状态Pod是否正常，Pod日志是否正常，如有异常请提交工单提供资源池、集群、Pod异常日志等信息联系值班同事排查，解决网络插件问题后重新安装即可 |
| ImagePullBackOff | 无 | dial tcp: lookup registry-vpc-crs-huadong1.cnsp-internal.ctyun.cn on 100.95.0.1:53: read udp 192.168.25.239:60233->100.95.0.1:53: i/o timeout | 拉镜像失败，节点尝试解析镜像仓库域名超时 | 检查Pod所在节点的安全组规则或ACL的出入方向是否有放通100.95.0.1 upd规则 |
组件使用常见问题
1、metrics-server组件常见无监控数据问题
分为两种情况：
执行kubectl top pod/node无监控数据输出
首先检查metrics-server的API Service是否正常，参见下属命令：
如果执行结果显示为true，表示metrics-server的API Service运行正常。
如果metrics-server的API Service不正常，在metrics-server所在的Node节点检查metrics-server的443端口是否可以在集群中正常访问。如果否，则尝试通过删除metrics-server的Pod的方式重启metrics-server。
执行kubectl top pod/node输出数据不全
根据输出结果检查是否某一特定node上无监控数据输出，如果是，请检查节点是否存在时区漂移，可以通过NTP服务器的date命令进行时区校验。
2、cube-node-local-dns组件使用中未自动注入DNSConfig至新创建pod中
请检查以下情况：
新建Pod如果位于kube-system和kube-public命名空间则不进行DNSConfig注入；
新建Pod所在命名空间的Labels标签包含node-local-dns-injection=enabled；
新建Pod的网络为hostNetwork且DNSPolicy为ClusterFirstWithHostNet，或Pod为非hostNetwork且DNSPolicy为ClusterFirst。
