1.2.3.2.4 集群运维¶
1 服务 Crash 情况下如何进入容器¶
在 K8s 环境中服务因为一些预期之外的事情会进入 CrashLoopBackOff 状态,通过 kubectl get pod --namespace ${namespace} 命令可以查看指定 namespace 下的 pod 状态和 pod_name 。在这种状态下,单纯通过 describe 和 logs 命令无法判定服务出问题的原因。当服务进入 CrashLoopBackOff 状态时,需要有一种机制允许部署服务的 pod 进入 running 状态方便用户通过 exec 进入容器内进行 debug 。
Doris Operator 提供了 Debug 的运行模式,下面描述了当服务进入 CrashLoopBackOff 时如何进入 Debug 模式进行人工 Debug ,以及解决后如何恢复到正常启动状态。
1.1 启动 Debug 模式¶
当服务一个 pod 进入 CrashLoopBackOff 或者正常运行过程中无法再正常启动时,通过以下步骤让服务进入 Debug 模式,进行手动启动服务查找问题。
-
通过以下命令给运行有问题的
pod进行添加annnotationBash 1kubectl annotate pod ${pod_name} --namespace ${namespace} selectdb.com.doris/runmode=debug当服务进行下一次重启时候,服务会检测到标识
Debug模式启动的annotation就会进入Debug模式启动,pod状态为running。 -
当服务进入
Debug模式,此时服务的pod显示为正常状态,用户可以通过如下命令进入pod内部Bash 1kubectl --namespace ${namespace} exec -ti ${pod_name} bash -
Debug下手动启动服务,当用户进入pod内部,通过修改对应配置文件有关端口进行手动执行start_xx.sh脚本,脚本目录为/opt/apache-doris/xx/bin下。FE需要修改query_port,BE需要修改heartbeat_service_port主要是避免Debug模式下还能通过service访问到crash的节点导致误导流。
1.2 退出 Debug 模式¶
当服务定位到问题后需要退出 Debug 运行,此时只需要按照如下命令删除对应的 pod ,服务就会按照正常的模式启动。
| Bash | |
|---|---|
1 | |
Tip
进入 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配置。
2 服务扩缩容¶
Doris 在 K8s 之上的扩缩容可通过修改 DorisCluster 资源对应组件的 replicas 字段来实现。修改可直接编辑对应的资源,也可通过命令的方式。
2.1 获取 DorisCluster 资源¶
使用命令 kubectl --namespace {namespace} get doriscluster 获取已部署 DorisCluster (简称 dcr )资源的名称。本文中,我们以 doris 为 namespace 。
| Bash | |
|---|---|
1 2 3 | |
2.2 扩缩容资源¶
K8s 所有运维操作通过修改资源为最终状态,由 Operator 服务自动完成运维。扩缩容操作可通过 kubectl --namespace {namespace} edit doriscluster {dcr_name} 直接进入编辑模式修改对应 spec 的 replicas 值,保存退出后 Doris Operator 完成运维,也可以通过如下命令实现不同组件的扩缩容。
2.2.1 FE 扩容¶
-
查看当前
FE服务数量Bash 1 2 3
$ kubectl --namespace doris get pods -l "app.kubernetes.io/component=fe" NAME READY STATUS RESTARTS AGE doriscluster-sample-fe-0 1/1 Running 0 10d -
扩容
FEBash 1kubectl --namespace doris patch doriscluster doriscluster-sample --type merge --patch '{"spec":{"feSpec":{"replicas":3}}}' -
检测扩容结果
Bash 1 2 3 4 5
$ kubectl --namespace doris get pods -l "app.kubernetes.io/component=fe" NAME READY STATUS RESTARTS AGE doriscluster-sample-fe-2 1/1 Running 0 9m37s doriscluster-sample-fe-1 1/1 Running 0 9m37s doriscluster-sample-fe-0 1/1 Running 0 8m49s
2.2.2 BE 扩容¶
-
查看当前
BE服务数量Bash 1 2 3
$ kubectl --namespace doris get pods -l "app.kubernetes.io/component=be" NAME READY STATUS RESTARTS AGE doriscluster-sample-be-0 1/1 Running 0 3d2h -
扩容
BEBash 1kubectl --namespace doris patch doriscluster doriscluster-sample --type merge --patch '{"spec":{"beSpec":{"replicas":3}}}' -
检测扩容结果
Bash 1 2 3 4 5
$ kubectl --namespace doris get pods -l "app.kubernetes.io/component=be" NAME READY STATUS RESTARTS AGE doriscluster-sample-be-0 1/1 Running 0 3d2h doriscluster-sample-be-2 1/1 Running 0 12m doriscluster-sample-be-1 1/1 Running 0 12m
2.3 节点缩容¶
关于节点缩容问题, Doris-Operator 目前并不能很好的支持节点安全下线,在这里仍能够通过减少集群组件的 replicas 属性来实现减少 FE 或 BE 的目的,这里是直接 stop 节点来实现节点下线,当前版本的 Doris-Operator 并未能实现 decommission 安全转移副本后下线。由此可能引发一些问题及其注意事项如下
-
表存在单副本情况下贸然下线
BE节点,一定会有数据丢失,尽可能避免此操作。 -
FE Follower节点尽量避免随意下线,可能带来元数据损坏影响服务。 -
FE Observer类型节点可以随意下线,并无风险。 -
CN节点不持有数据副本,可以随意下线,但因此会损失存在于该CN节点的远端数据缓存,导致数据查询短时间内存在一定的性能回退。
3 升级 Doris 集群¶
Doris 集群整体升级需要先升级 BE ,再升级 FE 。 Doris Operator 基于 Kubernetes 的滚动更新功能实现每个组件的滚动平滑升级。
3.1 升级前注意事项¶
-
升级操作推荐在业务低峰期进行。
-
滚动升级过程中,会导致连接到被关闭节点的连接失效,造成请求失败,对于这类业务,推荐在客户端添加重试能力。
-
升级前可以阅读常规升级手册,便于理解升级中的一些原理和注意事项。
-
升级前无法对数据和元数据的兼容性进行验证,因此集群升级一定要避免数据存在单副本情况和集群单
FE FOLLOWER节点。 -
升级过程中会有节点重启,所以可能会触发不必要的集群均衡和副本修复逻辑,先通过以下命令关闭
Bash 1 2 3
admin set frontend config("disable_balance" = "true"); admin set frontend config("disable_colocate_balance" = "true"); admin set frontend config("disable_tablet_scheduler" = "true"); -
Doris升级请遵守不要跨两个及以上关键节点版本升级的原则,若要跨多个关键节点版本升级,先升级到最近的关键节点版本,随后再依次往后升级,若是非关键节点版本,则可忽略跳过。具体参考升级版本说明
3.2 升级操作¶
升级过程节点类型顺序如下,如果某类型节点不存在则跳过:
| Bash | |
|---|---|
1 | |
建议依次修改对应集群组件的 image 然后应用该配置,待当前类型的组件完全升级成功状态恢复正常后,再进行下一个类型节点的滚动升级。
3.2.1 升级 BE¶
如果保留了集群的 crd ( Doris Operator 定义了 DorisCluster 类型资源名称的简写)文件,则可以通过修改该配置文件并且 kubectl apply 的命令来进行升级。
-
修改
spec.beSpec.image将
selectdb/doris.be-ubuntu:2.0.4变为selectdb/doris.be-ubuntu:2.1.0Bash 1vim doriscluster-sample.yaml -
保存修改后应用本次修改进行
be升级:Bash 1kubectl apply -f doriscluster-sample.yaml -n doris
也可通过 kubectl edit dcr 的方式直接修改。
-
查看
namespace为'doris'下的dcr列表,获取需要更新的cluster_nameBash 1 2 3
$ kubectl get dcr -n doris NAME FESTATUS BESTATUS CNSTATUS Doriscluster-sample available available -
修改、保存并生效
Bash 1kubectl edit dcr doriscluster-sample -n doris进入文本编辑器后,将找到
spec.beSpec.image,将selectdb/doris.be-ubuntu:2.0.4修改为selectdb/doris.be-ubuntu:2.1.0 -
查看升级过程和结果:
Bash 1kubectl get pod -n doris
当所有 Pod 都重建完毕进入 Running 状态后,升级完成。
3.2.2 升级 FE¶
如果保留了集群的 crd ( Doris-Operator 定义了 DorisCluster 类型资源名称的简写)文件,则可以通过修改该配置文件并且 kubectl apply 的命令来进行升级。
-
修改
spec.feSpec.image将
selectdb/doris.fe-ubuntu:2.0.4变为selectdb/doris.fe-ubuntu:2.1.0Bash 1vim doriscluster-sample.yaml -
保存修改后应用本次修改进行
be升级:Bash 1kubectl apply -f doriscluster-sample.yaml -n doris
也可通过 kubectl edit dcr 的方式直接修改。
-
修改、保存并生效
Bash 1kubectl edit dcr doriscluster-sample -n doris进入文本编辑器后,将找到
spec.feSpec.image,将selectdb/doris.fe-ubuntu:2.0.4修改为selectdb/doris.fe-ubuntu:2.1.0 -
查看升级过程和结果
Bash 1kubectl get pod -n doris
当所有 Pod 都重建完毕进入 Running 状态后,升级完成。
3.3 升级完成处理¶
3.3.1 验证集群节点状态¶
通过访问 Doris 集群文档提供的方式,通过 mysql-client 访问 Doris 。使用 show frontends 和 show backends 等 SQL 查看各个组件的版本和状态。
| SQL | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | |
若 FE 节点 alive 状态为 true ,且 Version 值为新版本,则该 FE 节点升级成功。
| SQL | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 | |
若 BE 节点 alive 状态为 true ,且 Version 值为新版本,则该 BE 节点升级成功
3.3.2 恢复集群副本同步和均衡¶
在确认各个节点状态无误后,执行以下 SQL 恢复集群均衡和副本修复:
| Bash | |
|---|---|
1 2 3 | |