OpenClaw生产级K8s部署实战：从架构设计到安全运维全解析

1. 项目概述与核心价值

最近在团队里折腾一个叫 OpenClaw 的开源项目，目标是把它从一个“能跑起来”的 Demo 状态，升级成一个能在真实生产环境里扛得住、管得好、还足够安全的服务。这项目本身挺有意思，但直接扔服务器上跑，总感觉心里没底，出点问题排查起来也麻烦。所以，我们决定把 Kubernetes 这套“组合拳”用上，目标很明确：构建一个安全、稳定、且能长期运维的 OpenClaw 生产实例。

简单来说，OpenClaw 可以理解为一个智能化的任务编排与执行引擎，它能处理各种自动化流程，比如数据处理、定时任务触发、与外部系统联动等。它的价值在于将复杂的、手动的操作流程化、自动化。但生产环境不是实验室，我们需要考虑的东西多了去了：服务挂了能不能自己恢复？流量大了能不能自动扩容？配置改了怎么无感更新？更重要的是，数据安不安全，权限控没控住？这些正是 Kubernetes 的强项。通过 K8s，我们不仅能给 OpenClaw 提供一个高可用的运行底座，还能把安全策略、监控告警、持续部署这些运维生命周期的关键环节都标准化、自动化起来。

这篇文章，我就来详细拆解我们是如何一步步实现的。无论你是正在考虑将类似应用容器化并上 K8s 的开发者，还是负责运维此类中间件的工程师，希望这里面趟过的路、踩过的坑，能给你一些实实在在的参考。我们会从整体架构设计思路讲起，深入到每个核心组件的配置细节，最后分享那些只有真正动手做过才会遇到的“坑”和解决技巧。

2. 整体架构设计与核心思路

把 OpenClaw 搬到 Kubernetes 上，绝不是简单写个 Dockerfile 然后kubectl apply就完事了。生产级部署需要系统的设计。我们的核心思路是：以 StatefulSet 和 Deployment 为基础工作负载，通过 ConfigMap 和 Secret 统一管理配置与敏感信息，利用 Service 和 Ingress 暴露服务，依托 PersistentVolume 持久化关键数据，最后用 NetworkPolicy、RBAC 和 PodSecurityContext 构建安全纵深防线。

2.1 工作负载选型：为什么是 StatefulSet + Deployment？

OpenClaw 的组件通常可以分为有状态和无状态两类。核心的服务进程，比如处理任务队列的 Worker、提供 API 的 Server，它们本身不持久化复杂状态（状态外置到数据库或消息队列），这类组件我们使用Deployment来部署。Deployment 提供了无缝滚动更新、回滚以及便捷的扩缩容能力，非常适合无状态服务。

然而，OpenClaw 很可能包含一些需要稳定网络标识或持久化存储的组件。例如，一个负责调度任务的 Master 节点，或者一个需要绑定特定数据卷的日志收集器 Sidecar。对于这类组件，我们选用StatefulSet。StatefulSet 能保证 Pod 拥有唯一的、持久的标识符（如openclaw-master-0,openclaw-master-1），并且每个 Pod 都能挂载自己专属的 PersistentVolumeClaim (PVC)。这对于需要稳定主机名、有序部署/扩展/删除的场景至关重要。

注意：不要盲目将所有组件都塞进 StatefulSet。只有真正需要稳定网络标识（用于服务发现）或独立持久化存储的组件才值得使用 StatefulSet，因为它比 Deployment 更“重”，管理也更复杂。

2.2 配置与敏感信息管理：ConfigMap 与 Secret 的最佳实践

生产环境避免将配置硬编码在镜像里。OpenClaw 的配置文件（如application.yaml,config.properties）我们通过ConfigMap来管理。将配置与镜像解耦后，修改配置只需更新 ConfigMap 并滚动重启 Pod，无需重新构建和推送镜像。

对于数据库密码、API Token、私钥等敏感信息，必须使用Secret。即使 Secret 在 K8s 内以 Base64 编码存储，也绝不能将其等同于加密。我们的原则是：

1. 最小权限：只为需要访问该 Secret 的 Pod 挂载。
2. 避免环境变量：尽量以 Volume 形式挂载为文件，而非注入环境变量。因为环境变量可能在日志、错误信息中泄露。
3. 结合外部方案：对于极高安全要求的场景，可以考虑集成外部的密钥管理服务，如 HashiCorp Vault，让 Pod 启动时动态从 Vault 拉取密钥。

2.3 网络与存储架构：服务发现与数据持久化

服务间通信通过 K8sService实现。我们为 OpenClaw 的 API Server 创建 ClusterIP 类型的 Service，供集群内其他组件访问。如果需要从集群外部访问，则通过Ingress资源（配合 Nginx Ingress Controller 或 Traefik 等）暴露 HTTP/HTTPS 服务，并在此层配置 TLS 终止、路由规则和基础限流。

存储方面，OpenClaw 的日志、临时工作数据、或者某些组件的本地状态，需要持久化。我们使用PersistentVolume (PV)和PersistentVolumeClaim (PVC)。对于云环境，通常动态供给（StorageClass）是最佳选择。关键点在于根据数据特性选择存储后端：高 IOPS 的 SSD 用于数据库，标准块存储用于日志，如果需要多 Pod 共享读取（如配置文件），则考虑 ReadWriteMany (RWX) 模式的存储，如 NFS 或云厂商提供的文件存储服务。

2.4 安全基线设计思路

安全不是某个开关，而是一套组合策略。我们从四个层面构建：

1. Pod 安全：使用securityContext配置容器以非 root 用户运行，设置只读根文件系统，丢弃不必要的 Linux Capabilities。
2. 网络隔离：利用NetworkPolicy实现微服务间的网络隔离，遵循最小连通原则。例如，只允许前端 Pod 访问 API Server 的特定端口，其他流量一律拒绝。
3. 访问控制：为 OpenClaw 相关的 ServiceAccount 配置精细的RBAC权限，遵循最小权限原则。避免使用cluster-admin这类过高权限的绑定。
4. 镜像安全：使用来自可信仓库的镜像，并定期扫描镜像漏洞。在 CI/CD 流水线中集成镜像扫描步骤。

3. 核心组件部署与配置详解

有了顶层设计，我们开始动手编写 Kubernetes 清单文件。这里以部署一个典型的 OpenClaw API Server（无状态）和一个假设的 OpenClaw Master Scheduler（有状态）为例。

3.1 准备命名空间与基础资源

首先，为 OpenClaw 创建一个独立的命名空间，实现逻辑隔离。

# 01-namespace.yaml apiVersion: v1 kind: Namespace metadata: name: openclaw-prod

然后，创建存储敏感信息的 Secret。假设我们需要数据库密码和一个 API 令牌。

# 02-secret.yaml apiVersion: v1 kind: Secret metadata: name: openclaw-secrets namespace: openclaw-prod type: Opaque data: # 使用 echo -n 'yourpassword' | base64 生成 database-password: eW91cnBhc3N3b3Jk # 示例，请替换 api-token: eW91cmFwaXRva2Vu # 示例，请替换

接着，创建应用配置 ConfigMap。

# 03-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: openclaw-config namespace: openclaw-prod data: application.yaml: | server: port: 8080 openclaw: task: worker-count: 4 storage: # 数据库地址通过环境变量或Service名注入 type: mysql logging: level: root: INFO com.example.openclaw: DEBUG

3.2 部署无状态 API Server (Deployment)

API Server 是无状态服务，适合用 Deployment。

# 04-deployment-api.yaml apiVersion: apps/v1 kind: Deployment metadata: name: openclaw-api-server namespace: openclaw-prod labels: app: openclaw component: api-server spec: replicas: 2 # 至少2个副本保证高可用 selector: matchLabels: app: openclaw component: api-server template: metadata: labels: app: openclaw component: api-server spec: # 使用专用服务账户，而非default serviceAccountName: openclaw-sa securityContext: # Pod级别的安全上下文 runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 seccompProfile: type: RuntimeDefault containers: - name: api-server image: your-registry/openclaw-api:1.2.0-prod # 请使用具体版本标签，避免latest imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: http # 资源请求与限制，防止单个Pod占用过多资源影响邻居 resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" # 容器级别的安全上下文 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true # 根文件系统只读，增强安全 capabilities: drop: - ALL # 丢弃所有Linux capabilities # 存活探针与就绪探针 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 1 # 环境变量配置 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: openclaw-secrets key: database-password - name: JAVA_OPTS value: "-Xms256m -Xmx512m" # 配置文件通过Volume挂载 volumeMounts: - name: config-volume mountPath: /app/config readOnly: true - name: secret-volume mountPath: /app/secrets readOnly: true # 日志目录挂载，方便收集 - name: log-volume mountPath: /app/logs volumes: - name: config-volume configMap: name: openclaw-config - name: secret-volume secret: secretName: openclaw-secrets optional: false - name: log-volume emptyDir: {} # 使用emptyDir临时存储日志，由Sidecar或DaemonSet收集

关键点解析：

• securityContext：这是安全加固的核心。runAsNonRoot和runAsUser强制以非 root 用户运行。readOnlyRootFilesystem: true能极大减少攻击面，但需要确保应用将需要写的目录（如/tmp,/logs）挂载为可写卷。
• resources：必须设置。requests用于调度决策，limits防止容器失控。不设置limits可能导致某个 Pod 吃光节点内存，引发 OOM Killer 无差别“杀进程”。
• livenessProbe与readinessProbe：生产环境必备。就绪探针决定流量是否路由到 Pod，存活探针决定是否重启不健康的 Pod。路径/health和/ready需要你的应用提供。
• emptyDirfor logs：日志不推荐直接写入节点本地盘（除非使用hostPath，但管理复杂）。更好的做法是使用emptyDir，然后部署一个日志收集器 DaemonSet（如 Fluentd、Filebeat）来收集每个 Pod 的日志，并发送到中心化的 ELK 或 Loki 系统。

3.3 部署有状态 Master Scheduler (StatefulSet)

假设 OpenClaw Master 需要稳定的网络标识和独立存储。

# 05-statefulset-master.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: openclaw-master namespace: openclaw-prod labels: app: openclaw component: master spec: serviceName: "openclaw-master" # 必须，用于构造稳定的网络标识 replicas: 1 # 假设Master是单实例或需要主动-被动模式，先部署1个 selector: matchLabels: app: openclaw component: master template: metadata: labels: app: openclaw component: master spec: serviceAccountName: openclaw-sa securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 containers: - name: master image: your-registry/openclaw-master:1.2.0-prod imagePullPolicy: IfNotPresent ports: - containerPort: 9090 name: rpc resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1" livenessProbe: tcpSocket: port: 9090 initialDelaySeconds: 60 # Master启动可能较慢 periodSeconds: 20 readinessProbe: exec: command: - /bin/sh - -c - # 这里可以是一个检查Master是否就绪的脚本命令 "curl -s http://localhost:9090/health | grep -q 'OK'" initialDelaySeconds: 30 periodSeconds: 10 volumeMounts: - name: config mountPath: /app/config - name: data mountPath: /app/data # Master的持久化数据目录 volumeClaimTemplates: # StatefulSet的核心，为每个Pod自动创建PVC - metadata: name: data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "standard-ssd" # 指定StorageClass，根据云环境调整 resources: requests: storage: 10Gi

3.4 配置服务暴露与网络策略

创建 Service 供内部访问。

# 06-service-internal.yaml apiVersion: v1 kind: Service metadata: name: openclaw-api-service namespace: openclaw-prod spec: selector: app: openclaw component: api-server ports: - port: 80 targetPort: 8080 name: http type: ClusterIP # 集群内访问 --- apiVersion: v1 kind: Service metadata: name: openclaw-master-service namespace: openclaw-prod spec: clusterIP: None # Headless Service，用于StatefulSet Pod的DNS发现 selector: app: openclaw component: master ports: - port: 9090 name: rpc

如果需要从公网访问 API，配置 Ingress。

# 07-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: openclaw-ingress namespace: openclaw-prod annotations: kubernetes.io/ingress.class: "nginx" cert-manager.io/cluster-issuer: "letsencrypt-prod" # 使用cert-manager自动管理TLS证书 spec: tls: - hosts: - openclaw.yourdomain.com secretName: openclaw-tls-secret rules: - host: openclaw.yourdomain.com http: paths: - path: / pathType: Prefix backend: service: name: openclaw-api-service port: number: 80

实施网络隔离策略，例如只允许 Ingress Controller 访问 API Server。

# 08-networkpolicy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-ingress-to-api namespace: openclaw-prod spec: podSelector: matchLabels: app: openclaw component: api-server policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: ingress-nginx # 假设Ingress Controller在这个命名空间 ports: - protocol: TCP port: 8080

3.5 配置 RBAC 权限

创建专属的 ServiceAccount 和最小化 Role/RoleBinding。

# 09-rbac.yaml apiVersion: v1 kind: ServiceAccount metadata: name: openclaw-sa namespace: openclaw-prod --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: openclaw-prod name: openclaw-pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] # 只允许读取Pod信息，例如用于服务发现 --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: openclaw-sa-binding namespace: openclaw-prod subjects: - kind: ServiceAccount name: openclaw-sa namespace: openclaw-prod roleRef: kind: Role name: openclaw-pod-reader apiGroup: rbac.authorization.k8s.io

4. 高可用与稳定性保障策略

部署上去只是第一步，如何保证它长期稳定运行才是挑战。

4.1 多副本与 Pod 反亲和性

对于无状态服务，通过 Deployment 的replicas设置多个副本。但光有副本还不够，如果所有副本都调度到同一个节点，该节点故障会导致服务全挂。因此需要配置Pod 反亲和性，尽量让副本分散在不同节点。

# 在Deployment的spec.template.spec中添加 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - openclaw - key: component operator: In values: - api-server topologyKey: kubernetes.io/hostname

这段配置表示“尽量（preferredDuringScheduling）不要将标签为app=openclaw, component=api-server的 Pod 调度到同一个主机（topologyKey: hostname）上”。对于关键服务，可以考虑使用requiredDuringSchedulingIgnoredDuringExecution（硬反亲和性）来强制分散。

4.2 优雅终止与生命周期钩子

K8s 在删除 Pod 前会发送 SIGTERM 信号。我们的应用必须正确处理这个信号，完成正在执行的任务、关闭连接、释放资源后再退出。在 Dockerfile 中，应使用ENTRYPOINT的 exec 形式，确保进程成为 PID 1，能接收到信号。

此外，可以利用preStop 钩子在收到 SIGTERM 后、容器终止前执行一些清理命令，例如从服务注册中心注销。

lifecycle: preStop: exec: command: ["/bin/sh", "-c", "echo '收到终止信号，开始清理...'; sleep 5"] # 示例，实际应为注销脚本

sleep 5可以给负载均衡器足够的时间将 Pod 从后端列表中移除，避免流量损失。

4.3 资源管理与服务质量

前面提到了resources.requests/limits。这不仅是限制，也决定了 Pod 的 QoS 等级。设置了limits和requests（且两者相等）的 Pod 属于Guaranteed级别，在节点资源紧张时最不容易被驱逐。对于核心服务，建议设置为Guaranteed。

同时，要合理设置HPA。根据 CPU/内存使用率或自定义指标（如 QPS）自动扩缩容。

# 10-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: openclaw-api-hpa namespace: openclaw-prod spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: openclaw-api-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU平均使用率超过70%时触发扩容

4.4 配置与密钥的动态更新

ConfigMap 或 Secret 更新后，默认不会主动通知 Pod。为了让 Pod 使用新配置，常见做法有：

1. 滚动更新：在 Deployment 的 Pod 模板中，将 ConfigMap/Secret 作为环境变量或 Volume 挂载。更新 ConfigMap 后，修改 Pod 模板的一个注解（如version: v2），触发 Deployment 滚动更新。
2. Sidecar 监听与热重载：运行一个 Sidecar 容器（如Reloader），监听 ConfigMap 变化，然后向主容器发送信号（如 SIGHUP）触发应用内部重载配置。这需要应用支持热重载。
3. 使用 Operator：更高级的做法是使用像Kubernetes External Secrets或定制 Operator 来管理密钥和配置的同步。

5. 可观测性与长期运维实践

系统跑起来之后，如何知道它是否健康？出了问题怎么快速定位？

5.1 集中式日志收集

我们采用DaemonSet 部署 Fluent Bit + 中心化 Loki的方案。Fluent Bit 作为轻量级日志收集器，跑在每个节点上，收集/var/log/containers/下的容器日志，并通过标签过滤出namespace=openclaw-prod的日志，发送到 Loki 集群。Grafana 则用于查询和展示 Loki 中的日志。

关键配置在于 Fluent Bit 的过滤和解析，确保日志字段（如 Pod 名称、容器名、命名空间）被正确提取为标签，便于在 Grafana 中高效查询。

5.2 指标监控与告警

使用Prometheus Operator一键部署 Prometheus 监控栈。我们需要做的是让 OpenClaw 应用暴露 Prometheus 格式的指标端点（通常是在/metrics路径）。如果 OpenClaw 是 Java 应用，可以集成 Micrometer；如果是 Go 应用，可以集成 Prometheus client library。

然后，通过 ServiceMonitor CRD 来告诉 Prometheus 抓取我们的服务。

# 11-servicemonitor.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: openclaw-api-monitor namespace: openclaw-prod spec: selector: matchLabels: app: openclaw component: api-server endpoints: - port: http # 对应Service端口名称 path: /actuator/prometheus # 假设Spring Boot Actuator的端点 interval: 30s namespaceSelector: matchNames: - openclaw-prod

基于收集到的指标（如请求延迟、错误率、JVM 内存使用率），在 Prometheus 中配置记录规则，并在 Alertmanager 中设置告警规则，通过钉钉、企业微信或邮件通知。

5.3 分布式追踪

对于复杂的任务流水线，一个请求可能经过多个 OpenClaw 组件。集成分布式追踪（如 Jaeger 或 SkyWalking）能帮助我们可视化请求链路，快速定位性能瓶颈或故障点。这通常需要在应用代码中植入追踪 SDK，并在 K8s 中部署对应的 Collector 和 Query 服务。

5.4 备份与灾难恢复

对于有状态数据（如 Master 的 PVC 数据、外部数据库），必须定期备份。

• PVC 备份：可以使用 Velero 这样的工具，对整个命名空间进行备份，包括 PV 数据（需要云存储插件支持快照）。
• 应用配置备份：所有 K8s 清单文件（YAML）应使用 Git 进行版本控制。
• 恢复演练：定期在测试集群进行灾难恢复演练，验证备份的有效性。

6. 安全加固进阶与常见问题排查

6.1 镜像安全扫描与供应链安全

将镜像安全扫描集成到 CI/CD 流程中。使用 Trivy、Aqua Security 或 Clair 等工具扫描镜像中的已知漏洞。设置策略，禁止存在高危漏洞的镜像被部署到生产环境。同时，考虑使用镜像签名与验证，确保部署的镜像来自可信源且未被篡改。

6.2 Pod 安全策略与安全上下文深化

虽然 PodSecurityPolicy (PSP) 在较新版本中已被 Pod Security Admission 取代，但安全上下文的原则不变。除了之前提到的runAsNonRoot和readOnlyRootFilesystem，还可以：

• 设置seccompProfile为RuntimeDefault或自定义配置文件，限制系统调用。
• 对于极度敏感的应用，考虑使用securityContext.allowPrivilegeEscalation: false并设置更严格的capabilities.drop。

6.3 网络策略精细化

最初的 NetworkPolicy 只允许了 Ingress 流量。随着组件增多，需要绘制服务间的依赖关系图，编写更精细的策略。例如：

• 只允许 API Server 访问数据库的特定端口。
• 禁止所有 Pod 对 K8s API Server 的访问（除非必要）。
• 设置默认拒绝所有入站和出站流量，然后按需开放。

6.4 常见问题与排查实录

问题1：Pod 一直处于CrashLoopBackOff状态。

• 排查：首先kubectl logs <pod-name> --previous查看上一次崩溃的日志。常见原因：应用启动依赖（如数据库）未就绪；配置错误（ConfigMap 挂载路径不对）；镜像本身启动命令有问题；readOnlyRootFilesystem: true但应用尝试向根目录写文件。
• 技巧：在 Deployment 中为容器添加command: ["sh", "-c", "sleep 3600"]覆盖原有启动命令，然后kubectl exec进入容器手动调试，检查环境变量、配置文件、网络连通性。

问题2：服务内部访问不通。

• 排查：确认 Service 的selector与 Pod 的labels完全匹配。使用kubectl get endpoints <service-name>检查 Endpoints 列表是否正常。在客户端 Pod 内使用nslookup <service-name>.<namespace>.svc.cluster.local检查 DNS 解析。使用telnet <service-name> <port>或curl测试连通性。
• 注意：如果使用 Headless Service (clusterIP: None)，DNS 解析会返回所有 Pod IP，需要客户端具备负载均衡能力。

问题3：节点资源不足导致 Pod 无法调度。

• 排查：kubectl describe node <node-name>查看节点的Allocatable和已分配资源。检查是否有 Pod 设置了过高的requests或limits，或者存在资源泄漏。
• 解决：优化应用资源需求；清理不再需要的 Pod；考虑集群扩容；设置更合理的requests和limits。

问题4：HPA 不生效，没有自动扩容。

• 排查：kubectl describe hpa <hpa-name>查看事件和当前指标状态。确认metrics-server已正确安装且能提供资源指标。对于自定义指标，确认prometheus-adapter等组件已配置且指标可用。
• 注意：HPA 计算副本数需要时间，且有冷却窗口。瞬间的流量尖峰可能来不及反应，需要结合应用层面的限流和熔断。

问题5：Ingress 配置后访问返回 502/503。

• 排查：检查 Ingress Controller 的 Pod 日志。检查后端 Service 的 Endpoints 是否正常。检查 Pod 的就绪探针是否通过。使用kubectl port-forward直接映射到 Pod 端口，测试应用本身是否正常。

问题6：PersistentVolume 无法挂载或只读。

• 排查：kubectl describe pvc <pvc-name>查看 PVC 状态。kubectl describe pod <pod-name>查看 Pod 事件，常见错误是FailedMount。检查 StorageClass 配置是否正确，云平台配额是否足够。对于ReadWriteOnce卷，确保只被一个 Pod 挂载。

构建一个生产级的 OpenClaw on Kubernetes 实例，是一个从架构设计到细节打磨的系统工程。它不仅仅是“部署”，更是将安全、稳定、可观测、可运维的理念通过 K8s 的各项能力落地。这个过程会不断遇到新的挑战，但每解决一个，系统的韧性就增强一分。最重要的经验是：一切皆代码（IaC）。将所有的清单文件、配置、策略都纳入版本控制；监控先行，没有可观测性，稳定性无从谈起；安全左移，在镜像构建、配置编写的阶段就考虑安全，而不是事后补救。最后，保持耐心，善于利用kubectl describe、kubectl logs和kubectl exec这三个“神器”，大部分问题都能找到线索。