本文翻译自：https://learnk8s.io/graceful-shutdown
在Kubernetes中，创建和删除Pod是最常见的任务之一。
当执行滚动更新、扩展部署、发布新版本、执行作业和定时作业等操作时，会创建Pod。
但是，在发生驱逐事件后，例如将节点标记为不可调度，Pod也会被删除并重新创建。
如果这些Pod的特性是如此短暂，那么当一个Pod正在响应请求时被告知关闭会发生什么？
请求在关闭之前是否完成？那么后续的请求会被重定向到其他地方吗？
在讨论Pod被删除时会发生什么之前，有必要讨论一下Pod被创建时会发生什么。
假设您想在集群中创建以下Pod：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
您可以使用以下命令将YAML定义提交到集群：
kubectl apply -f pod.yaml
一旦您输入该命令，kubectl会将Pod定义提交给Kubernetes API。这就是旅程的开始。
将集群状态保存到数据库中
API接收并检查Pod定义，然后将其存储在数据库（etcd）中。Pod也会被添加到调度器的队列中。
调度器：
- 检查定义
- 收集有关工作负载的详细信息，例如CPU和内存请求
- 决定最适合运行Pod的节点（通过Filters和Predicates等过程）。
在此过程结束时：
- Pod在etcd中被标记为Scheduled。
- Pod被分配给一个节点。
- Pod的状态被存储在etcd中。
但是，Pod此时并不实际存在。
当您使用kubectl apply -f命令提交一个Pod的时候，YAML文件会被发送到Kubernetes API。 
API会将Pod保存在数据库(etcd)中。 
调度器会为该Pod分配最合适的节点，并将Pod的状态更改为Pending。此时，Pod仅存在于etcd中。 
kubelet — Kubernetes 代理
kubelet 的工作是轮询控制平面以获取更新。
你可以想象 kubelet 不断地向主节点询问：“我负责管理工作节点 1，有没有新的 Pod 给我？”
当有一个 Pod 时，kubelet 就会创建它。
kubelet 并不是直接创建 Pod。相反，它将工作委托给其他三个组件：
- 容器运行时接口（CRI） —— 用于为 Pod 创建容器的组件。
- 容器网络接口（CNI） —— 用于将容器连接到集群网络并分配 IP 地址的组件。
- 容器存储接口（CSI） —— 用于在容器中挂载卷的组件。
在大多数情况下，容器运行时接口（CRI）的工作类似于：
docker run -d <my-container-image>
容器网络接口（CNI）更有趣一些，因为它负责：
- 为 Pod 生成有效的 IP 地址。
- 将容器连接到网络的其余部分。
正如你可以想象的，有多种方法可以将容器连接到网络并分配有效的 IP 地址（可以选择 IPv4 或 IPv6，或者分配多个 IP 地址）。
如果你对 Linux 网络命名空间和 CNI 感兴趣，可以查看这篇关于追踪 Kubernetes 网络流量路径的文章。
例如，Docker 创建虚拟以太网对并将其连接到桥接器，而 AWS-CNI 则直接将 Pod 连接到虚拟私有云（VPC）的其余部分。
当容器网络接口完成其工作后，Pod 就会连接到网络的其余部分，并被分配一个有效的 IP 地址。
但有一个问题，**kubelet 知道 IP 地址（因为它调用了容器网络接口），但控制平面不知道。**没有人告诉主节点该 Pod 已经分配了一个 IP 地址，并且准备好接收流量。
在控制平面看来，该 Pod 仍在创建中。**kubelet 的工作是收集 Pod 的所有细节，例如 IP 地址，并将它们报告给控制平面。**你可以想象，检查 etcd 将不仅会显示 Pod 运行的位置，还会显示其 IP 地址。
Kubelet会定期向控制平面轮询更新。 
当一个新的Pod被分配到节点上时，kubelet会检索相关的详细信息。 
kubelet本身不会创建Pod，它依赖于三个组件：容器运行时接口（CRI）、容器网络接口（CNI）和容器存储接口（CSI）。 
当这三个组件都成功完成后，Pod将在节点上处于Running状态，并被分配了一个IP地址。 
kubelet会将IP地址报告给控制平面。 
如果该 Pod 不是任何 Service 的一部分，这就是任务的结束。Pod 已经创建并准备好使用。当 Pod 是 Service 的一部分时，还需要进行一些额外的步骤。
Pod 和 Service
当你创建一个 Service 时，通常需要注意两个信息：
- label 选择器，用于指定将接收流量的 Pod。
targetPort—— Pod 用于接收流量的端口。
Service 的典型 YAML 定义如下：
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- port: 80
targetPort: 3000
selector:
name: app
当你使用 kubectl apply 将 Service 提交到集群时，Kubernetes 会找到与选择器（name: app）相同标签的所有 Pod，并收集它们的 IP 地址 —— 但仅当它们通过了就绪探针。
然后，对于每个 IP 地址，它将 IP 地址和端口连接起来。如果 IP 地址是 10.0.0.3，targetPort 是 3000，Kubernetes 将这两个值连接起来，并称之为一个端点。
IP 地址 + 端口 = 端点
---------------------------------
10.0.0.3 + 3000 = 10.0.0.3:3000
这些端点存储在 etcd 中，另一个名为 Endpoint 的对象中。
Kubernetes 中的术语区分如下：
- endpoint（在本文和 Learnk8s 材料中以小写的
e表示）是 IP 地址 + 端口对（10.0.0.3:3000）。 - Endpoint（在本文和 Learnk8s 材料中以大写的
E表示）是一组端点。
Endpoint 对象是 Kubernetes 中的一个真实对象，对于每个 Service，Kubernetes 自动创建一个 Endpoint 对象。
你可以通过以下命令验证：
kubectl get services,endpoints
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
service/my-service-1 ClusterIP 10.105.17.65 <none> 80/TCP
service/my-service-2 ClusterIP 10.96.0.1 <none> 443/TCP
NAME ENDPOINTS
endpoints/my-service-1 172.17.0.6:80,172.17.0.7:80
endpoints/my-service-2 192.168.99.100:8443
Endpoint 收集了来自 Pod 的所有 IP 地址和端口。
每当发生以下情况时，Endpoint 对象会使用新的端点列表进行刷新：
- 创建一个 Pod。
- 删除一个 Pod。
- 修改 Pod 上的标签。
因此，每次创建一个 Pod 并在 kubelet 将其 IP 地址提交给主节点后，Kubernetes 都会更新所有的端点以反映这些变化：
kubectl get services,endpoints
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
service/my-service-1 ClusterIP 10.105.17.65 <none> 80/TCP
service/my-service-2 ClusterIP 10.96.0.1 <none> 443/TCP
NAME ENDPOINTS
endpoints/my-service-1 172.17.0.6:80,172.17.0.7:80,172.17.0.8:80
endpoints/my-service-2 192.168.99.100:8443
在这张图片中，您的集群中部署了一个Pod。该Pod属于一个Service。如果您检查etcd，您会发现Pod和Service的详细信息。 
当部署一个新的Pod时会发生什么？ 
Kubernetes需要跟踪Pod及其IP地址。Service应该将流量路由到新的端点，因此IP地址和端口应该被传播。 
当部署另一个Pod时会发生什么？ 
完全相同的过程。在数据库中创建一个新的Pod记录，并传播端点。 
但是，当删除一个Pod时会发生什么？ 
Service会立即删除该端点，并最终从数据库中删除该Pod。 
Kubernetes对您的集群中的每一个小变化都做出反应。 
端点存储在控制平面中，并且 Endpoint 对象已经更新了。你准备好开始使用你的 Pod 了吗？
在Kubernetes中使用终端点
终端点在Kubernetes中被多个组件使用。
Kube-proxy使用终端点在节点上设置iptables规则。因此，每当终端点（对象）发生更改时，kube-proxy会检索新的IP地址和端口列表，并编写新的iptables规则。
让我们考虑一个有两个Pod和没有Service的三节点集群。Pod的状态存储在etcd中。 
当您创建一个Service时会发生什么？ 
Kubernetes会创建一个Endpoint对象，并从Pod中收集所有端点（IP地址和端口对）。 
kube-proxy守护进程订阅对Endpoint的更改。 
当一个Endpoint被添加、删除或更新时，kube-proxy会检索新的端点列表。 
kube-proxy使用这些端点在集群中的每个节点上创建iptables规则。 
Ingress控制器也使用相同的终端点列表。Ingress控制器是集群中将外部流量路由到集群的组件。当您设置Ingress清单时，通常会将服务指定为目标：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
paths:
- backend:
service:
name: my-service
port:
number: 80
path: /
pathType: Prefix
实际上，流量不会路由到服务。相反，Ingress控制器设置一个订阅，以便在服务的终端点发生更改时得到通知。**Ingress直接将流量路由到Pod，跳过了服务。**可以想象，每当终端点（对象）发生更改时，Ingress会检索新的IP地址和端口列表，并重新配置控制器以包括新的Pod。
在这张图片中，有一个带有两个副本的Deployment和一个Service的Ingress控制器。 
如果您想通过Ingress将外部流量路由到Pod，您应该创建一个Ingress清单（一个YAML文件）。 
当您使用kubectl apply -f ingress.yaml命令时，Ingress控制器会从控制平面检索文件。 
Ingress YAML具有serviceName属性，用于描述应该使用哪个Service。
Ingress控制器会从Service中检索端点列表并跳过它。流量直接流向端点（Pod）。 
当创建一个新的Pod时会发生什么？ 
您已经知道Kubernetes如何创建Pod并传播端点。\n 
Ingress控制器会订阅对端点的更改。由于有一个新的更改，它会检索新的端点列表。 
Ingress控制器将流量路由到新的Pod。 
还有更多的Kubernetes组件示例订阅终端点的更改。CoreDNS是集群中的DNS组件的另一个示例。如果您使用的是无头服务（Headless）类型的服务，CoreDNS将需要订阅终端点的更改，并在添加或删除终端点时重新配置自身。
同样的终端点也被服务网格（如Istio或Linkerd）使用，被云提供商用于创建type: LoadBalancer类型的服务，以及无数的操作者。
您必须记住，有多个组件订阅终端点的更改，并且它们可能在不同的时间接收到有关终端点更新的通知。
快速回顾一下创建Pod时发生的情况：
- Pod被存储在etcd中。
- 调度器分配一个节点。它将节点写入etcd。
- kubelet收到新的已调度Pod的通知。
- kubelet委托容器的创建给容器运行时接口（CRI）。
- kubelet委托将容器附加到容器网络接口（CNI）。
- kubelet委托将容器中的卷挂载到容器存储接口（CSI）。
- 容器网络接口分配一个IP地址。
- kubelet将IP地址报告给控制平面。
- IP地址被存储在etcd中。
如果您的Pod属于一个服务：
- kubelet等待成功的就绪探测。
- 所有相关的终端点（对象）都会收到更改的通知。
- 终端点将新的终端点（IP地址+端口对）添加到它们的列表中。
- Kube-proxy收到终端点更改的通知。Kube-proxy在每个节点上更新iptables规则。
- Ingress控制器收到终端点更改的通知。控制器将流量路由到新的IP地址。
- CoreDNS收到终端点更改的通知。如果服务是无头服务类型，DNS条目将被更新。
- 云提供商收到终端点更改的通知。如果服务是
type: LoadBalancer类型，新的终端点将被配置为负载均衡器池的一部分。 - 安装在集群中的任何服务网格都会收到终端点更改的通知。
- 订阅终端点更改的任何其他操作者也会收到通知。
对于一个看似常见的任务-创建Pod来说，这个列表如此之长。Pod处于运行状态。现在是讨论删除Pod时会发生什么的时候了。
删除Pod
您可能已经猜到了，但是当删除Pod时，您需要按相同的步骤反向操作。
首先，应该从终端点（对象）中删除终端点。
这次忽略就绪探测，并立即从控制平面中删除终端点。
这反过来会触发kube-proxy、Ingress控制器、DNS、服务网格等所有事件。
这些组件将更新其内部状态，并停止将流量路由到该IP地址。
由于这些组件可能正在忙于其他任务，无法保证从其内部状态中删除IP地址需要多长时间。
如果您使用kubectl delete pod命令删除一个Pod，该命令首先会到达Kubernetes API。 
该消息会被控制平面中的特定控制器（Endpoint控制器）拦截。 
Endpoint控制器会向API发出命令，从Endpoint对象中删除IP地址和端口。 
谁监听Endpoint的更改？kube-proxy、Ingress控制器、CoreDNS等都会收到更改的通知。 
一些组件（如kube-proxy）可能需要一些额外的时间来进一步传播更改。 
对于某些组件而言，可能只需要不到一秒钟，而对于其他组件可能需要更长时间。
同时，etcd中Pod的状态被更改为Terminating（终止）。
kubelet收到更改通知并进行以下操作：
- 从容器中卸载任何卷到容器存储接口（CSI）。
- 从网络中分离容器，并释放IP地址给容器网络接口（CNI）。
- 销毁容器给容器运行时接口（CRI）。
换句话说，Kubernetes按照创建Pod的相同步骤进行反向操作。然而，有一个微妙但重要的区别。当您终止一个Pod时，终端点的删除和向kubelet发出的信号同时发生。
如果您使用kubectl delete pod命令删除一个Pod，该命令首先会到达Kubernetes API。 
当kubelet轮询控制平面以获取更新时，它注意到Pod已被删除。 
kubelet将销毁Pod的任务委托给容器运行时接口（CRI）、容器网络接口（CNI）和容器存储接口（CSI）。 
当您首次创建Pod时，Kubernetes等待kubelet报告IP地址，然后开始终端点传播。**然而，当您删除Pod时，事件同时并行发生。**这可能会导致一些竞态条件。如果在终端点传播之前删除Pod会怎样？
删除端点和删除Pod同时发生。 
因此，您可能会在kube-proxy更新iptables规则之前删除端点。 
或者您可能更幸运，只有在端点完全传播后才删除Pod。 
优雅关闭
在终端点从kube-proxy或Ingress控制器中删除之前终止Pod时，可能会出现业务中断时间。如果仔细考虑，这是有道理的。Kubernetes仍然将流量路由到IP地址，但Pod已经不存在了。
Ingress控制器、kube-proxy、CoreDNS等没有足够的时间将IP地址从内部状态中删除。理想情况下，Kubernetes应该等待集群中的所有组件都有更新的终端点列表，然后再删除Pod。
**但是Kubernetes并不是这样工作的。**Kubernetes提供了强大的原语来分发终端点（例如Endpoint对象和更高级的抽象，如Endpoint Slices）。然而，Kubernetes不会验证订阅终端点更改的组件是否与集群的状态保持同步。
那么，为了避免这种竞态条件并确保在终端点传播后删除Pod，你应该做什么呢？
你应该等待。
**当Pod即将被删除时，它会接收到一个SIGTERM信号。**您的应用程序可以捕获该信号并开始关闭。由于在Kubernetes中不太可能立即从所有组件中删除终端点，您可以：
- 等待更长的时间再退出。
- 尽管收到SIGTERM信号，仍然处理传入的流量。
- 最后，关闭现有的长连接（例如数据库连接或WebSockets）。
- 终止进程。
你应该等待多久？
默认情况下，Kubernetes会发送SIGTERM信号，并在强制终止进程之前等待30秒。
因此，您可以使用前15秒继续运行，就好像什么都没有发生。希望这个时间间隔足够传播终端点的删除到kube-proxy、Ingress控制器、CoreDNS等组件。随着时间的推移，越来越少的流量将到达您的Pod，直到停止。
在15秒之后，可以安全地关闭与数据库的连接（或任何持久连接）并终止进程。如果您认为需要更多时间，可以在20或25秒时停止进程。
但是，请记住，Kubernetes将在30秒后强制终止进程（除非您在Pod定义中更改了terminationGracePeriodSeconds）。
如果无法更改代码以等待更长时间怎么办？
您可以调用一个脚本等待固定的时间，然后让应用程序退出。在调用SIGTERM之前，Kubernetes在Pod中提供了一个preStop钩子。您可以将preStop钩子设置为等待15秒。
让我们看一个示例：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
lifecycle:
preStop:
exec:
command: ["sleep", "15"]
preStop钩子是Pod生命周期钩子之一。
15秒的延迟是推荐的时间吗？
这取决于具体情况。
您已经知道，当删除一个Pod时，kubelet会收到更改的通知。 
如果Pod有一个preStop钩子，它会首先被调用。 
当preStop完成后，kubelet向容器发送SIGTERM信号。从那时起，容器应该关闭所有长连接并准备终止。 
默认情况下，该进程有30秒的时间退出，其中包括preStop钩子。如果进程在此期间没有退出，kubelet会发送SIGKILL信号并强制终止进程。 
kubelet会向控制平面通知成功删除Pod。 
以下是您可以选择的选项总结。
优雅停机和滚动更新
优雅停机适用于被删除的 Pod。但如果你不删除 Pod 呢？即使你不删除，Kubernetes 也会删除 Pod。特别是，每当你部署应用程序的新版本时，Kubernetes 都会创建和删除 Pod。
当你在 Deployment 中更改镜像时，Kubernetes 会逐步滚动更新。
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
replicas: 3
selector:
matchLabels:
name: app
template:
metadata:
labels:
name: app
spec:
containers:
- name: app
# image: nginx:1.18 旧版本
image: nginx:1.19
ports:
- containerPort: 3000
如果你有三个副本，并且在提交新的 YAML 资源后，Kubernetes：
- 创建一个带有新容器镜像的 Pod。
- 销毁一个现有的 Pod。
- 等待 Pod 准备就绪。
它会重复上述步骤，直到所有的 Pod 都迁移到新版本。
Kubernetes 只有在新 Pod 准备好接收流量（也就是通过了就绪检查）后，才会重复每个周期。
Kubernetes 是否会等待 Pod 被删除后再进行下一个操作？
不会。
如果你有 10 个 Pod，并且 Pod 需要 2 秒才能准备就绪，20 秒才能关闭，那么情况如下：
- 创建第一个 Pod，并终止一个现有的 Pod。
- 新 Pod 需要 2 秒才能准备就绪，之后 Kubernetes 创建一个新的 Pod。
- 同时，正在终止的 Pod 保持终止状态 20 秒。
20 秒后，所有新的 Pod 都处于活动状态（10 个 Pod，在 2 秒后准备就绪），而之前的 10 个 Pod 正在终止中（第一个终止的 Pod 即将退出）。
总共，在短时间内你会有两倍数量的 Pod（10 个运行中，10 个终止中）。
优雅期相对于就绪探针的时间越长，你将同时拥有更多运行中（和终止中）的 Pod。
这是不好的吗？
不一定，只要你小心不丢失连接即可。
终止长时间运行的任务
那么长时间运行的任务呢？如果你正在转码一个大视频，有没有办法延迟关闭Pod？
假设你有一个包含三个副本的部署。每个副本被分配了一个需要转码的视频，这个任务可能需要几个小时才能完成。
当你触发滚动更新时，Pod在被终止之前有30秒的时间完成任务。
如何避免延迟关闭Pod呢？你可以将terminationGracePeriodSeconds增加到几个小时。然而，在这个时间点，Pod的终端点是无法访问的。
如果你暴露指标来监控你的Pod，你的监控工具将无法访问你的Pod。为什么？**诸如Prometheus之类的工具依赖于终端点来抓取集群中的Pod。**然而，一旦你删除Pod，终端点的删除就会在集群中传播 — 即使是到Prometheus！
与其增加宽限期，你应该考虑为每个新版本创建一个新的部署。
当你创建一个全新的部署时，现有的部署保持不变。
长时间运行的任务可以继续像往常一样处理视频。
一旦它们完成，你可以手动删除它们。
如果你希望自动删除它们，你可能想要设置一个自动缩放器，在任务用尽时将你的部署缩放为零副本。
这样的Pod自动缩放器的一个例子是Osiris — 一个通用的、用于Kubernetes的零副本组件。这种技术有时被称为 彩虹部署，在你需要将之前的Pod保持运行时间超过宽限期时非常有用。
另一个很好的例子是WebSockets。如果你正在向用户实时推送更新，你可能不希望每次发布时都终止WebSockets。如果你在一天内频繁发布，那可能会导致实时数据流中断多次。
为每个发布创建一个全新的部署是一个不太明显但更好的选择。 现有用户可以继续接收更新，同时最新的部署为新用户提供服务。当用户从旧的Pod断开连接时，你可以逐渐减少副本并淘汰过去的部署。
总结
你应该注意从集群中删除的 Pod，因为它们的 IP 地址可能仍然用于路由流量。与立即关闭 Pod 相比，你应该考虑在应用程序中等待更长的时间，或者设置一个 preStop 钩子。
只有在集群中的所有端点都被传播并从 kube-proxy、Ingress 控制器、CoreDNS 等中删除后，才应该删除 Pod。如果你的 Pod 运行长时间的任务，比如转码视频或使用 WebSockets 提供实时更新，你应该考虑使用彩虹部署。
在彩虹部署中，你为每个发布创建一个新的 Deployment，并在连接（或任务）被清空时删除之前的 Deployment。你可以在长时间运行的任务完成后手动删除旧的部署。或者你可以自动将部署的副本数缩减为零，以自动化这个过程。
