部署运维 FAQ

部署篇

Mongodb 和 Minio 处于 Pending 状态，安装失败？

ZadigX 系统安装的时候，不会介入到集群的存储细节中来，因此，在没有默认 storage class 或是没有指定 storage class 的时候， 需要事先创建 PV 来让 MinIO 和 Mongodb 正确运行。 以下是一个可以运行的 PV YAML 示例

点击查看

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4.   name: zadig-reserved-pv
  5. spec:
  6.   capacity:
  7.     storage: 20Gi
  8.   accessModes:
  9.     - ReadWriteOnce
  10.   hostPath:
  11.     path: "/mnt/zadig/data"
  12.     type: Directory
  13. ---
  14. apiVersion: v1
  15. kind: PersistentVolume
  16. metadata:
  17.   name: task-pv-volume
  18. spec:
  19.   capacity:
  20.     storage: 20Gi
  21.   accessModes:
  22.     - ReadWriteOnce
  23.   hostPath:
  24.     path: "/mnt/zadig/data2"
  25.     type: Directory

使用 hostpath 类型的 PersistentVolume 安装 ZadigX，MongoDB 容器一直提示权限有问题无法创建目录，Pod 启动失败

这是因为容器对于 PersistentVolume 中指定的 path 没有写入权限导致。可以手动执行创建文件目录并给予 777 权限模式即可，举例如下：

  1. mkdir /mnt/zadig/data
  2. chmod 777 /mnt/zadig/data

安装时 MySQL Pod startupProbe 报 warning 信息

mysql_pod_startup_probe_warning

在安装 ZadigX 时，MySQL Pod 创建 15s 后会开始对其进行启动探测检查。这样做的目的是保证有充分的时间来保护慢启动的应用，每次检测异常时会反馈 warning。系统最多会在 100s 内进行 10 次探测检查，遇到此种情况请耐心等待片刻。

扩展知识

关于 Kubernetes Startup Probe 的知识点可阅读 Configure Startup Probes部署运维 FAQ - 图2 (opens new window)

安装时 zadig-init Pod 状态为 Error

zadig_init_job_error

zadig-init Job 会做一些系统初始化的工作，完成内置用户以及角色和绑定数据的设置。该 Job 的完成依赖于慢启动的 MySQL / MongoDB 等基础组件，遇到此种情况请耐心等待片刻。该 Job 最多会被重试 10 次，最终有一个状态为 Completed 的 Job，ZadigX 系统即可正常使用。如果 10 次重试后 Job 仍未完成，请联系我们。

安装时报错 Error: failed to install CRD crds/enterprise.gloo.solo.io_v1_AuthConfig.yaml: …

完整报错信息：Error: failed to install CRD crds/enterprise.gloo.solo.io_v1_AuthConfig.yaml: unable to recognize “”: no matches for kind “CustomResourceDefinition” in version “apiextensions.k8s.io/v1”

ZadigX 系统对 Kubernetes 集群版本有要求。遇到此种错误请检查你的 Kubernetes 集群版本，需要集群版本在 1.16 及以上，才能正常安装使用。

运维篇

如何判断 Kubernetes 集群节点异常

第一步：查询节点状态

  1. kubectl get node -o wide

第二步：通过以下命令，查询高负载的节点，如果节点异常的话一般都可以使用该命令查询

  1. kubectl top node

如果有发现某个节点的状态为 unknown，则该节点已经存在异常，此时有以下几种解决办法

  • 将该节点设置封锁，将相关异常 Pod 从该节点删除，让其重新分配到正常的节点上
  • 重启该节点服务器，让该节点的 kubelet 正常和 master 上的 apiserver 通信

更多 kubernetes 集群异常诊断，详见 官方 kubernetes 集群诊断部署运维 FAQ - 图4 (opens new window)

工作流运行一直卡在准备环境阶段如何解决？

这是因为构建 Pod 未能正常启动导致。使用以下命令查询构建 Pod 的运行状态，并详细排查未能启动的具体原因。

常见原因包括但不限于：集群资源短缺、集群节点被配置污点…

  1. kubectl get pod -n <ZadigX 部署所在 Namespace>     # 查询异常状态的 Pod
  2. kubectl describe pod <PodName>                    # 查看异常状态 Pod 未能启动的详细原因

托管集群挂了如何解决？

恢复托管集群，在 Zadig 系统中重新连接挂接集群，参考文档：集群管理。

环境页面无法获取 workload 信息时如何解决？

可以从环境对应 Namespace 所在集群的连接状态入手排查：

  • 若使用代理模式连接集群，进行断开重连操作
  • 若使用直接连接模式连接集群，检查所配置的 kubeconfig 文件是否失效

集群管理参考文档：集群管理。

aslan 服务出现 crashloopbackoff 状态如何解决？

可以从以下思路排查：

  • 查看 aslan 所使用的 MongoDB / MySQL 实例连接信息是否正确
  • 检查数据库实例是否正常

如何安全 Patch 服务？

使用 K8s 滚动发布的方式更新，需要注意在变更 aslan、warpdrive 服务组件时，没有正在运行的工作流。

如何把 Pod 多个副本调度到不同区域的节点上

可以在写 YAML 的时候增加 Pod 的反亲和性调度策略利用 Kubernetes 本身的一些特性来解决。详见 Kubernetes 文档部署运维 FAQ - 图5 (opens new window)

系统创建出来的 Ingress 可以正常工作，本地用 kubectl apply 为什么不可以？

因为 ZadigX 创建的 Ingress 会自动添加 kubernetes.io/ingress.class，描述使用的 Ingress class，所以手动 kubectl apply 使用的 YAML 也需要加上这项。