这是我的第101篇原创文章

【背景】

kafka基于k8s容器化部署后,对容器设置了存活探针,即检测监听端口是否存在。然而一次kill kafka进程的操作,服务的重启时间(supervisor会自动再拉起kafka进程)超过了存活探针的监测时间,导致pod重启。本文就该问题展开进行分析。

【kill背后的逻辑】

对于以SIGTERM信号(不带参数的默认发送信号)进行的kill操作,kafka broker会捕获该信号,进行服务停止的相关处理动作,其中比较重要的两个动作为:

1)controlledShutdown

这一步的具体流程包括:

a. 待停止的broker节点向zk(2.8.0以前版本)获取controller节点的信息

b. 向controller建立连接并发送controlledShutdown请求,

c. controller收到请求后,对leader位于该broker上的分区进行必要的迁移动作,即分区副本数大于1,且有存活的其他broker节点中选出新的leader,然后发送请求通知被选中的broker成为新的分区leader;对待停止的broker上处于follower状态的分区以rpc请求形式告知停止进行fetch动作。

d. 最后controller给待停止的broker节点进行controlledShutdown请求响应。

之所以要这么做,是可以将分区不可服务的时间缩短为毫秒级别。否则,zk需要一段时间才能感知到该节点的离线,而controller的broker监听了对应znode目录的变化,因此感知broker的离线后才触发进行相应的处理动作,在controller未感知到其他节点离线的这段时间内,leader位于停止的broker节点上的分区是不可服务的,因此不可服务时间基本上就取决于kafka与zk之间连接的超时时长。

2)关闭所有打开的日志文件,并创建相关文件以标记文件是正常关闭。

关闭所有打开的文件,并在目录中写入".kafka_cleanshutdown"文件。在启动后,加载segment时,会判断是否存在".kafka_cleanshutdown"文件,从而决定是否需要进行日志的恢复动作(这里暂不展开)。

这种关闭服务的方式被称之为优雅的关闭服务,而不是kill -9强行结束。在官方文档中,也有相关的介绍。

ca681814952f22cdefaff5bf1a041b3b.png

另外,"kafka-server-stop.sh"脚本本质上也是这么操作的。

SIGNAL=${SIGNAL:-TERM}
PIDS=$(ps ax | grep -i 'kafka\.Kafka' | grep java | grep -v grep | awk '{print $1}')

if [ -z "$PIDS" ]; then
  echo "No kafka server to stop"
  exit 1
else
  kill -s $SIGNAL $PIDS
fi

正常情况下, controlledShutdown这个操作都是非常快的。但是由于该操作细化后的各个步骤都会涉及网络的交互,那么,在一些异常情况下,比如与zk的tcp连接异常、与controller的网络连接异常、controller触发的分区leader重新选举异常等,这都会导致controlledShutdown请求的重试,直到请求成功或者达到最大重试次数才结束,这时,controlledShutdown请求的整体耗时可能会超过30s,甚至更长。这也是我们业务中导致pod重启的原因。

[2023-04-10 14:18:03,597] INFO [KafkaServer id=1] shutting down (kafka.server.KafkaServer)
[2023-04-10 14:18:03,599] INFO [KafkaServer id=1] Starting controlled shutdown (kafka.server.KafkaServer)
[2023-04-10 14:18:11,010] WARN [KafkaServer id=1] Retrying controlled shutdown after the previous attempt failed... (kafka.server.KafkaServer)
[2023-04-10 14:18:16,049] WARN [KafkaServer id=1] Retrying controlled shutdown after the previous attempt failed... (kafka.server.KafkaServer)
[2023-04-10 14:18:21,081] WARN [KafkaServer id=1] Retrying controlled shutdown after the previous attempt failed... (kafka.server.KafkaServer)
[2023-04-10 14:18:21,084] WARN [KafkaServer id=1] Proceeding to do an unclean shutdown as all the controlled shutdown attempts failed (kafka.server.KafkaServer)
[2023-04-10 14:18:27,279] INFO [KafkaServer id=1] shut down completed (kafka.server.KafkaServer)

实际上,controlledShutdown这个请求操作是可选进行的(由配置参数进行控制)。也就是说,在关闭时可以控制不进行controlledShutdown请求。这样,可以一定程度上加速服务的重启,甚至可能在zk感知到broker节点离线前,就已经完成了重启流程。

涉及的相关配置包括:

// 与controller的socket超时时间, 默认为30000, 即30秒
controller.socket.timeout.ms
// controlled shutdown请求的最大重试次数, 默认3次
controlled.shutdown.max.retries
// controlled shutdown请求的重试间隔, 默认5000, 即5s
controlled.shutdown.retry.backoff.ms
// 是否启用 controlled shutdown, 默认为true
controlled.shutdown.enable

【总结】

本文通过一个重启耗时较长的问题,讲述了一个简单的知识点:kafka优雅关闭时的controlledShutdown请求操作。当然是否要禁用该请求,需要结合实际业务的可用性、zk连接超时时长等因素一并考虑。

另外,重启过程中的另外一个耗时操作,日志的加载与恢复,这里没有展开讲解,下篇文章我们再来聊聊该内容。

好了,这就是本文的全部内容,如果觉得本文对您有帮助,请点赞+转发,如果觉得有不正确的地方,也可以拍砖指点,最后,欢迎加我微信交流~

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐