K8s 集群里 ByConity 起不来？先查这几处
ByConity 在 K8s 集群里跑不起来，绝大多数情况不是 ByConity 本身的问题，而是 Pod 调度、存储挂载、Service 发现或资源配额这四个环节出了偏差。
排错时不要一上来就翻 ByConity 源码，先把 kubectl get pods 的输出看明白，再顺着事件和日志往下查，基本能覆盖八成以上的故障场景。
先确认 Pod 卡在哪个阶段
执行下面的命令，拿到所有 ByConity 相关 Pod 的状态和重启次数：
kubectl get pods -n byconity -o wide重点关注三列：STATUS、RESTARTS、NODE。
- Pending：Pod 没有被调度到节点上，通常是资源不足、节点选择器不匹配或 PVC 没绑定。
- CrashLoopBackOff：容器启动后崩溃，需要看日志和事件。
- Running 但 RESTARTS 很高：容器反复重启，可能是健康检查失败或内存被 OOM Kill。
- ContainerCreating 长时间不变：多半是镜像拉取慢或存储挂载卡住。
接着看具体原因：
kubectl describe pod -n byconity 重点看 Events 部分。
如果出现 FailedScheduling，会直接告诉你哪个节点资源不够；
如果出现 FailedMount，通常是 PVC 或 ConfigMap 的问题。
日志和事件怎么读才有效
看日志不要只看尾部，ByConity 组件启动阶段的报错往往在前面几行。
kubectl logs -n byconity --tail=200 如果容器已经重启过，加上 --previous 看上一次崩溃前的输出：
kubectl logs -n byconity --previous 常见的日志关键词和对应方向：
Connection refused：目标组件还没起来，或者 Service 名称/端口配错了。No such file or directory：挂载路径不对，或者 ConfigMap 没有正确挂载到容器里。OutOfMemory或进程被 kill：检查 Pod 的resources.limits.memory是否给得太小。Authentication failed：检查用户名密码 Secret 是否和 ByConity 配置一致。
网络与服务发现是高频故障点
ByConity 的多个组件之间需要互相通信，K8s 里靠 Service 做服务发现。
如果组件日志里反复出现连接超时，先验证 Service 是否正常。
kubectl get svc -n byconity
kubectl get endpoints -n byconity如果某个 Service 的 ENDPOINTS 是
用下面的命令核对标签：
kubectl get pods -n byconity --show-labels把 Pod 的标签和 Service 的 spec.selector 对照，不一致就改回来。
另外，如果用了 NetworkPolicy，确认没有把组件之间的流量挡掉。
存储和配置挂载检查清单
ByConity 依赖持久化存储保存数据，PVC 没绑定会导致 Pod 一直 Pending。
kubectl get pvc -n byconitySTATUS 必须是 Bound。
如果是 Pending，用 kubectl describe pvc 看是 StorageClass 不存在还是容量不足。
ConfigMap 挂载错误也很常见，尤其是把配置文件挂成目录时路径写错。
确认挂载点：
kubectl describe pod -n byconity | grep -A5 Mounts 然后进容器里确认文件确实存在：
kubectl exec -it -n byconity -- ls /etc/byconity/ 资源限制与健康检查的坑
ByConity 的某些组件启动时内存占用较高，如果 limits 给得太紧，容器会被 OOM Kill，表现为反复重启但日志里看不到明显错误。
kubectl describe pod -n byconity | grep -A3 Limits 同时检查 livenessProbe 和 readinessProbe 的 initialDelaySeconds。
ByConity 组件启动可能需要几十秒，如果探针初始延迟太短，容器还没准备好就被判为失败，也会触发重启。
适当调大这个值往往能解决“启动一半就被杀”的问题。
几个容易被忽略的细节
- 镜像架构不匹配：如果节点是 ARM 架构，而镜像只有 amd64 版本，Pod 会一直处于
ErrImagePull或崩溃状态。用kubectl describe pod确认拉取的是哪个镜像标签。 - 命名空间搞混：所有命令都要带
-n byconity，否则查的是 default 命名空间，什么都看不到。 - 时间不同步：节点之间时间差异过大可能导致组件握手失败，用
date在节点上核对一下。
验证修复是否生效
修复后不要只看 Pod 是否 Running，还要确认服务真正可用：
kubectl get pods -n byconity
kubectl logs -n byconity --tail=50 如果 ByConity 提供了客户端或健康检查端口，尝试在集群内用 curl 或自带客户端连接一下，确认能正常响应。
只有业务查询能跑通，才算排错完成。
常见疑问
Pod 一直 Pending，但节点资源看起来够用？
检查节点是否有污点（Taint），以及 Pod 是否配置了对应的容忍（Toleration）。
另外确认 PVC 是否绑定成功，存储没就绪也会导致 Pending。
日志里没有明显错误，但容器就是反复重启？
优先看 kubectl describe pod 里的 Last State 和 Reason，OOM Kill 和探针失败通常不会在应用日志里留明显痕迹。
改了 ConfigMap 之后 Pod 没变化？
以 Volume 方式挂载的 ConfigMap 更新后，容器内文件会延迟同步，但已经运行的进程不会自动重载。
最稳妥的方式是重启对应的 Pod。
排错的核心思路是：先看 Pod 状态和事件，再看日志，最后核对网络、存储和资源限制。
按这个顺序走，大部分 K8s 集群里 ByConity 的启动和运行问题都能定位到具体原因。
