服务 Crash 情况下如何进入容器

在 k8s 环境中服务因为一些预期之外的事情会进入 CrashLoopBackOff 状态，通过 kubectl get pod --namespace ${namespace} 命令可以查看指定 namespace 下的 pod 状态和 pod_name。

在这种状态下，单纯通过 describe 和 logs 命令无法判定服务出问题的原因。当服务进入 CrashLoopBackOff 状态时，需要有一种机制允许部署服务的 pod 进入 running 状态方便用户通过 exec 进入容器内进行 debug。

doris-operator 提供了 debug 的运行模式，本质上是通过 debug 进程占用对应节点的探活端口，绕过 k8s 探活机制，制造一个平稳运行的容器环境来方便用户进入并定位问题。

下面描述了当服务进入 CrashLoopBackOff 时如何进入 debug 模式进行人工 debug，以及解决后如何恢复到正常启动状态。

启动 Debug 模式

当服务一个 pod 进入 CrashLoopBackOff 或者正常运行过程中无法再正常启动时，通过一下步骤让服务进入 debug 模式，进行手动启动服务查找问题。

1.通过以下命令给运行有问题的 pod 进行添加 annnotation

$ kubectl annotate pod ${pod_name} --namespace ${namespace} selectdb.com.doris/runmode=debug

当服务进行下一次重启时候，服务会检测到标识 debug 模式启动的 annotation 就会进入 debug 模式启动，pod 状态为 running。

2.当服务进入 debug 模式，此时服务的 pod 显示为正常状态，用户可以通过如下命令进入 pod 内部

$ kubectl --namespace ${namespace} exec -ti ${pod_name} bash

3. debug 下手动启动服务，当用户进入 pod 内部，通过修改对应配置文件有关端口进行手动执行 start_xx.sh 脚本，脚本目录为 /opt/apache-doris/xx/bin 下。

FE 需要修改 query_port，BE 需要修改 heartbeat_service_port 主要是避免debug模式下还能通过 service 访问到 crash 的节点导致误导流。

当服务定位到问题后需要退出 debug 运行，此时只需要按照如下命令删除对应的 pod，服务就会按照正常的模式启动。

$ kubectl delete pod ${pod_name} --namespace ${namespace}

进入 pod 内部后，需要修改配置文件的端口信息，才能手动启动相应的 Doris 组件

FE 需要修改默认路径为：/opt/apache-doris/fe/conf/fe.conf 的 query_port=9030 配置。
BE 需要修改默认路径为：/opt/apache-doris/be/conf/be.conf 的 heartbeat_service_port=9050 配置。