wxya（个人网站）Pod生命周期|服务质量
服务启动
（启动后的服务检查数据库连接、预热、一切ready才ok）可以延迟、或者结果返回处理
服务关闭
- kube-proxy 删除上游 iptables 中的目标 IP
这一步虽然一般来说会是一个相对比较快的操作，不会像图里所示这么夸张，但它的执行时间依然是不受保障的，取决于集群的实例规模，变更繁忙程度等多重因素影响，所以用了虚线表示。
这一步执行完毕后，只能确保新建立的连接不再连接到老容器 IP 上，但是已经存在的连接不会受影响。
- kubelet 执行 preStop 操作
由于后一步操作会立刻关闭 listener，所以这一步，我们最好是在 preStop 中，sleep N 秒的时间（这个时间取决于你集群规模），以确保 kube-proxy 能够及时通知所有上游不再对该 Pod 建立新连接。
- kubelet 发送 TERM 信号
- 停止接受新连接：Kitex 会立刻关闭当前监听的端口，此时新进来的连接会被拒绝，已经建立的连接不影响。所以务必确保前面 preStop 中配置了足够长的等待服务发现结果更新的时间。
- 等待处理完毕旧连接：
- 非多路复用下（短连接/长连接池）：
- 每隔 1s 检查所有连接是否已经都处理完毕，直到没有正在处理的连接则直接退出。
- 多路复用：
- 立即对所有连接发送一个 seqID 为 0 的 thrift 回包（控制帧），并且等待 1s（等待对端 Client 收到该控制帧 ）
- Client 接收到该消息后标记当前连接为无效，不再复用它们（而当前正在发送和接收的操作并不会受到影响）。这个操作的目的是，client 已经存在的连接不再继续发送请求。
- 每隔 1s 检查所有存量连接是否已经都处理完毕，直到没有活跃连接则直接退出
- 达到 Kitex 退出等待超时时间（ExitWaitTime，默认 5s）则直接退出，不管旧连接是否处理完毕。
此时才会真正进入到 Kitex 能够控制的优雅关闭流程：
- 达到 K8s terminationGracePeriodSeconds 设置的超时时间（从 Pod 进入 Termination 状态开始算起，即包含了执行 PreStop 的时间），则直接发送 KILL 信号强杀进程，不管进程是否处理完毕。 terminationGracePeriodSeconds , 默认是30s
Loading...