注意事项：
部署失败后重新部署前一定先重置环境
执行部署时开启debug日志，方便后续问题排查，开启方式：proton-cli apply -f <cluster.yaml> -l debug 或 proton-cli server -l debug
常规问题排查思路
原则：关注服务状态，查看日志，根据日志排错
查看部署日志：journalctl | grep kubesuite、journalctl _COMM=proton-cli
启动初始化向导操作报错(proton-cli server)
open service-package/chart：no such file or directory
**排查及解决思路：**执行初始化时需要在proton依赖包的解压目录下执行，请进入解压目录再执行初始化
Kubernetes集群初始化报错排查思路
- 查看后台具体错误信息，尝试执行出错的命令
- 查看日志：journalctl ，根据报错信息排查网络、docker、k8s
- 若无有用信息，可尝试查看系统日志：/var/log/messages
- 基础服务部署过程中出错：
helm list / kubectl get pod -A 找到部署失败的服务
kubectl describe pod / logs 查看具体错误，根据报错修正问题 - 部署工作台激活/更新过程中出错：
界面上查看详细日志或者查看deploy-service日志：kubectl -n anyshare logs -f -l app=deploy-installer
查看deploy_tools日志：/var/log/deploy_tools/deploy_tools.log
Kubernetes集群初始化报错：push docker images fail
排查及解决思路：未知原因偶现镜像推送失败，重试可解决，出现该错误时，可尝试重新执行初始化（https://devops.aishu.cn/AISHUDevOps/ICT/_workitems/edit/377705）
https://{ip}:6443 connection refused
进行初始化时，未进行k8s初始化，直接报错如下
排查及解决思路：出现该问题多数情况下为之前执行过初始化操作并且最终未成功，此时~/.kube/config中存在有残余信息，再次进行初始化时被作为已存在外置k8s处理，从而导致初始化失败，此时需要删除配置文件~/.kube/config后，再次进行初始化
Kubernetes集群初始化报错：docker 无法启动
初始化时报错如下：
排查及解决思路：
-
查看docker状态：
-
docker未启动，systemctl start docker启动docker服务
-
若启动成功则可重新进行初始化；若启动失败，查看docker启动日志，报错如下：
-
-
tail -f /var/log/messages 查看系统日志，报错如下：
-
firewall-cmd --list-all-zones 查看zones，public中存在 docker0：
- 从public中删除docker0：
firewall-cmd --zone=public --remove-interface=docker --permanent
firewall-cmd --get-zone-of-interface=docker
firewall-cmd --reload - 启动docker服务：systemctl start docker，docker启动成功
- 重新执行proton-cli apply -f cluster.yaml 初始化集群
- 从public中删除docker0：
Kubernetes集群初始化报错：设置高可用失败
kubesuite.client.CalledSSHError: Command 'crictl stop $(crictl ps --name kube-apiserver -q)'
排查及解决思路：在集群初始化过程中需要设置集群高可用，此过程需要重启kube-apiserver，超时导致重启失败，一般出现该问题是由于服务器磁盘io性能太差导致，请更换磁盘性能较好的服务器（海量虚拟机环境常见此类错误）
Kubernetes集群初始化报错：tiller服务未启动
报错：helm tiller is not ready
排查及解决思路：tiller服务未正常启动，kubectl get pod -A查看tiller服务状态和日志，日志显示 i/o timeout类似错误，一般出现该问题是由于服务器磁盘io性能太差导致，请更换磁盘性能较好的服务器（海量虚拟机环境常见此类错误）
Kubernetes集群初始化报错：update chrony config fail
排查及解决思路：
- 查看报错节点上的chronyd服务状态：systemct status chronyd
- 服务未启动，执行systemct start chronyd启动服务
- 重新初始化
Kubernetes集群初始化报错：environment is not suitable
例如：抛错exception：environment is not suitable
排查及解决思路：图中抛错和环境的内存、cpu有关，查询一下环境的内存和cpu是否够用，一般mariadb的默认内存配置为24G，加上其他组件的内存和cpu，查看当前环境的资源大小是否满足，如果不满足则可以在初始化界面降低资源配置占用即可。（解决完配置之后再次初始化需要重置集群之后重新初始化）
Kubernetes集群初始化报错：kubesuite.client.CalledSSHError
例如：报错kubesuite.client.CalledSSHError： Command ‘kubeadm init --skip-phases=addon/coredns --config=/tmp/kubeadm-config.yaml’ returned non-zero exit status 1
排查及解决思路：
**方式一：**执行报错的命令，例如：如图报错中需要执行 kubeadm init --skip-phases=addon/coredns --config=/tmp/kubeadm-config.yaml’
根据命令执行报错排查问题
报错提示拉取镜像失败
此时可停止docker服务：systemctl stop docker，删除/sysvol/proton_data/cs_docker_data目录，然后启动docker服务：systemctl start docker，手动拉取某个镜像，正常可拉取后，进行集群reset，重新初始化
若报错为chart获取失败，请参考镜像拉取失败场景，停止、删除、启动cr（cr目录、proton-cr-chartmuseum）
若报错为端口被占用，此时可查看端口被哪些服务占用，释放端口后reset并重新初始化；若无端口被占用，可等待几分钟后重新执行reset和初始化
**方式二：**直接通过journalctl查看日志，找到报错位置进行错误信息分析排查（同方式一）
推送镜像失败
推动单个镜像包推送失败，抛错ssh: handshake failed：ssh: unbale to authenticate, attempted methods [none pulickey], no supported methods remain
如下图所示
排查及解决思路：集群节点之间初始化之后都是处于免密的，环境可以先ssh自己本身看看是否需要输入密码，如果需要输入密码，则免密丢了，需要重新把节点之间进行免密操作。
基础服务部署失败
k8s集群已初始化成功，基础服务报错
如下图所示，k8s集群已初始化成功，基础服务部署失败
排查及解决思路：
- 若为干净环境（仅安装过操作系统）第一次部署，查看对应服务状态
- 若为pending，则describe查看描述信息，大多数为资源不够导致，请增配或降低初始化资源配置（仅限于内存降配，web界面可调整mariadb和opensearch内存，若为CPU不足则需要服务器增配）后，重置集群再重新初始化
- 若为其他状态，则需要查看错误日志，根据错误日志进行初步排错，若无法解决请反馈到技术工程院系统测试部，需提供详细操作步骤及错误信息
- 若为非干净环境，比如：多次部署、单节点环境变为多节点、数据目录发生过变更、手动删除过数据等，请参考重置集群，重置后重新进行初始化
模块化服务安装失败
若【服务监控】页面显示服务安装失败，排错步骤如下：
第1步 点击对应模块化服务，在右侧窗口中点击【执行详情】，查看状态为「失败」的微服务
第2步 进入后台查看对应微服务状态和日志信息，根据错误日志进行进一步排查