部署运维 FAQ

部署篇

Mongodb 和 Minio 处于 Pending 状态,安装失败?

Zadig 系统安装的时候,不会介入到集群的存储细节中来,因此,在没有默认 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 安装 Zadig,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

在安装 Zadig 时,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,Zadig 系统即可正常使用。如果 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”

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

安装完成访问 Zadig 报错 405 Method Not Allowed

使用了错误的入口导致的。 访问 Zadig 系统的统一流量入口在 gateway-proxy 服务上,只需要将流量打入 gateway-proxy 服务中即可, 不要将流量直接打入 zadig-portal 服务中。

运维篇

如何判断 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 <Zadig 部署所在 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 为什么不可以?

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