k8s之滚动更新及pod流量分析

一、LB Service流量

LoadBalancer 负责接收 K8s 集群外部流量并转发到 Node 节点上，ipvs/iptables 再负责将节点接收到的流量转发到 Pod 中（kube-proxy 组件会更新各节点的 ipvs/iptables 规则，即nodeIP:port）；

二、Nginx Ingress 提供的 SLB流量

默认情况下流量进入 Ingress Controller后会被直接转发到后端 podIP:端口，而非 Service 的 ClusterIP（ingress controller 在监听到 Service 的 Endpoint 变更后会自动更新到Nginx的网关上，当然也支持配置nginx的服务地址为clusterIP,当使用clusterIP时流量负载均衡均由K8s控制，一些 Ingress特性将会失效，如会话保持、重试策略等）；

三、微服务流量

流量进入后，消费者会根据服务地址列表载均衡转发到对应的 Provider Pod 中（Provider 启动后会将 podIP:port注册到注册中心，下线的 Pod 会从注册中心移除，且服务地址列表的变更会被消费者订阅）；

四、pod流量下线有损情况

Pod 被删除后，状态被 endpoint-controller 和 kubelet 订阅，并分别执行移除 Endpoint 和删除 Pod 操作，但是两个操作并非我们预期的先移除 Endpoint 后再删除 Pod，而是是同时进行的，因此有可能会出现在 Pod 已经接收到了 SIGTERM 信号但仍然有流量进入的情况。
因此，K8s 在 Pod 下线流程中提供了 preStop Hook 机制，可以让 kubelet 在发现 Pod 状态为 Terminating 时，不立即向容器发送 SIGTERM 信号，而允许其做一些停止前操作。通常会在 preStop 中设置 sleep 一段时间，让 SIGTERM 延迟一段时间再发送到应用中，可以避免在这段时间内流入的流量损失，同时也能允许等待已被 Pod 接收的流量继续处理完成。

五、pod流量上线有损情况

如果在 Pod 上线时，不对 Pod 中服务进行可用性检查，这会使得 Pod 启动后过早被添加到 Endpoint 后端，后被其他网关控制器添加到网关路由规则中，那么流量被转发到该 Pod 后就会出现连接被拒绝的错误。因此，K8s 为 Pod 提供了 readinessProbe 用于校验新 Pod 是否就绪，进而控制其在 Service 后端 Endpoint 中上线的时机。

六、deployment滚动更新策略
maxUnavailable控制滚动更新过程中最大不可用副本数，即最小可用副本数；
可以是具体的整数3，也可以是百分比（和期望副本数对比），向下取整，默认值25%。
比如期望副本数10，maxUnavailable=25%，最小可用副本数10-roundDown(10*25%)=8
比如期望副本数10，maxUnavailable=3，最小可用副本数10-3=7

maxSurge控制滚动更新过程中可超过期望的副本数，即最大副本总数；
可以是具体的整数3，也可以是百分比（和期望副本数对比），向上取整，默认值25%
比如期望副本数10，maxSurge=25%，最大副本总数10+roundUp(10*25%)=13
比如期望副本数10，maxSurge=2，最大副本总数10+2=12

举例，期望10个实例，maxUnavailable=25%，maxSurge=25%，则最小可用副本数=8，最大副本总数=13
1、首先创建3个新副本使副本总数达到13，
2、其次销毁2个旧副本使可用副本数降到8个，
3、当2个旧副本成功销毁后，可再创建2个新副本，使副本总数保持为13，
4、等3个新副本通过就绪探针后，使得可用副本数增加，变为11个超过8个，
5、进而销毁更多的旧副本，使得可用副本数回到8，
6、旧副本成功销毁后使得副本总数低于13，就再创建更多的新副本。