应用在发布或重启的期间会出现少量的 5xx 异常，应该如何解决？
我们发现导致流量有损的原因有很多，比如：
-
上线时，应用在就绪前收到流量，导致请求无法被处理；
-
下线时，应用没有做优雅退出导致请求中断，应用没有正确监听到终止信号导致优雅退出无效，平台路由规则更新不及时导致流量转发到已经销毁的副本等；
传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤，由人工操作实现客户端不对更新感知，这种方式简单而有效，但是限制较多。不仅需要使用借助网关的支持来摘流量，还需要在停应用前人工判断来保证在途请求已经处理完毕。
滚动更新机制
在容器上线时， ReplicaSet 控制器会向 kube-apiserver 组件发送创建 Pod 的请求，kube-scheduler 组件负责选择合适的节点的节点来运行新的 Pod，并将选择的节点写入 Pod 对象的 spec.nodeName 字段中。
部署在每个节点中的 kubelet 组件会监听 Pod 对象的变化，当新的 Pod 被调度到所在的节点时，kubelet 组件会使用 CRI 来启动容器，并在启动后对 Pod 内每个容器执行启动探测。
在启动探测通过后，再分别对每个容器周期性地执行存活探测和就绪探测，在 Pod 内所有容器都通过就绪探测之后，kubelet 组件会把 Pod 标记为 Ready 状态，同时上报给 kube-apiserver 组件。
而 Endpoint 控制器会监听 Pod 的变化，当 Pod 的状态变为Ready状态时，会将 Pod 的 IP 和端口添加到 Endpoint 对象中， kube-proxy 组件在监听 Endpoint 对象的变化后会使用 ipvs 或 iptables 在节点中生成流量转发的规则。
在容器下线时，ReplicaSet 控制器会向 kube-apiserver 组件发送删除 Pod 的请求，kube-apiserver 不会立即删除 Pod，而是在 Pod 的metadata 中添加 deletionTimestamp 字段，将 Pod 的状态标记为 Terminating。
当 kubelet 组件监听到 Pod 对象的 deletionTimestamp 被设置时，就会调用 CRI 向容器发起停止容器的请求，如果容器设置了 PreStop 钩子，kubelet 会在发送 SIGTERM 信号之前先执行 PreStop 钩子，等待 PreStop 钩子执行完成后再发送 SIGTERM 信号，接着在 terminationGracePeriodSeconds 后发送 SIGKILL 信号去杀死所有容器进程，完成容器的停止过程。
在 kubelet 停止容器的同时，Endpoint 控制器监听到 Pod 的状态变化，会将 Pod 的 IP 从相应的 Endpoint 对象中移除，kube-proxy 组件监听到 Endpoint 对象的变化后，会移除 Pod IP 的转发规则。kube-proxy 在不同的模式下移除转发规则的方式会有所不同，比如 ipvs 模式下会把规则的权重修改为0，iptable 模式下则是直接删除转发规则。
流量有损情况
1、没有配置就绪探测导致服务上线有损
如果没有配置就绪探测，Pod 在启动完成后会立即被视为Ready就绪状态，然后开始接收流量，如果此时容器内的进程还在初始化资源的状态就会造成流量有损。
2、就绪探测配置不当导致服务上线有损
就绪探测提供了三种探测方式：HTTP 探测、命令行探测、TCP 探测，对于常规的 Web 服务，我们应该首选 HTTP 探测、备选命令行探测，尽量避免使用 TCP 探测。
在使用 TCP 探测时，kubelet 组件会向指定端口发送 TCP SYN 包，如果 Pod 响应 TCP ACK包则表明监听的端口处于打开状态，则探测成功。但TCP 探测只能检测网络连接是否建立、服务端口是否打开，无法反应服务的真实健康状态，比如程序的端口虽然已经打开，但如果内部正在初始化资源或者出现了死锁等问题的话，也就无法正常处理流量，即流量打到表面健康但实际不健康的 Pod 上，造成流量有损。
3、没有配置优雅退出导致服务下线有损
服务下线过程中，已进入容器的流量如果没有被处理完，容器就被杀死，导致调用方收到502。
服务下线的过程中，Kubernetes 的 kubelet 和 kube-proxy 组件会同时监听 Pod 的变化，然后分别去清理容器和网络的路由转发规则，这个过程是同时进行的。在某些情况下，kubelet 有可能在 kube-proxy 更新完路由转发规则前就已经销毁了容器，这时新的流量被转发进来时，就会出现异常。
优雅退出可以让程序在退出前执行的一系列保证应用正常关闭的操作，这些操作往往包括等待已有请求执行完成、等待尚未完成的事务处理、清理资源（比如关闭文件描述符、关闭socket）、持久化内存数据（比如将内存中的数据落盘到文件中）等，同时能够让 kubelet 组件在等待一段时间后在执行回收容器的操作，给 kube-proxy 留够清理的时间。
优雅退出本质上是JVM即将关闭前执行的一些额外的处理代码。
4、监听SIGTERM信号但业务程序不是作为1号进程启动
如下代码，程序监听了SIGTERM信号，在收到SIGTERM信号时执行清理工作。
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
"time"
)
func main() {
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGTERM, syscall.SIGINT)
go func() {
for s := range c {
switch s {
case syscall.SIGINT, syscall.SIGTERM:
fmt.Println("退出", s)
ExitFunc()
default:
fmt.Println("other", s)
}
}
}()
fmt.Println("进程启动...")
time.Sleep(time.Duration(200000)*time.Second)
}
func ExitFunc() {
fmt.Println("正在退出...")
fmt.Println("执行清理...")
fmt.Println("退出完成...")
os.Exit(0)
}
（1）使用启动脚本启动
业务程序在容器中没有作为1号进程启动，而是作为启动脚本start.sh的子进程启动，容器中的 1 号进程 start.sh 收到了 SIGTERM 信号但并没有转发给它的子进程，导致业务程序没有办法做优雅退出，最后只能因为 SIGKILL 信号而被强制杀掉。
# 构建
FROM golang:alpine as build
WORKDIR /demo
ADD . .
RUN GOOS=linux CGO_ENABLED=0 GOARCH=amd64 go build -o app main.go
# 运行
FROM ubuntu:22.04 as prod
COPY --from=build /demo/app /demo/
COPY --from=build /demo/start.sh /demo/
# 启动服务
CMD ["/demo/start.sh"]
启动脚本
#!/bin/sh
# start.sh
# do something
/demo/app
（2）使用shell模式启动
在Dockerfile中CMD和ENTRYPOINT用来启动应用，有shell模式和exec模式。使用shell模式，PID为1的进程为shell；使用exec模式PID为1的进程为业务本身。
shell模式
CMD ./app
exec模式
CMD ["./app"]
需要注意的是 exec模式无法读取环境变量，仅shell模式能够读取环境变量。
（3）解决方式
1）配置prestop
容器在下线时的流程
deletionTimestamp -> prestop -> SIGTERM -> SIGKILL(terminationGracePeriodSeconds)
2）在 Dockerfile 中移除启动脚本 start.sh，让业务程序作为1号进程被启动。
# 让业务程序作为1号进程被启动
CMD ["/demo/app"]
3）保留启动脚本start.sh，使用 exec 命令启动业务程序，exec 用于执行新的命令，同时替换掉当前进程，即覆盖掉原来启动脚本 start.sh 的进程。
#!/bin/sh
# do something
exec /demo/app