删除pod的主要流程如下：
    1. 用户发送命令删除 Pod，使用的是默认的宽限期（30秒）
    2. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 “死亡”。
    3. 当使用客户端命令查询 Pod 状态时，Pod 显示为 “Terminating”。

    1. （和第 3 步同步进行）当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。
    • 如果 Pod 定义了 preStop 钩子，就在 Pod 内部调用它。如果宽限期结束了，但是 preStop 钩子还在运行，那么就用小的（2 秒）扩展宽限期调用步骤 2。
    • 给 Pod 内的进程发送 TERM 信号。请注意，并不是所有 Pod 中的容器都会同时收到 TERM 信号，如果它们关闭的顺序很重要，则每个容器可能都需要一个 preStop 钩子。
    1. （和第 3 步同步进行）从服务的端点列表中删除 Pod，Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器（如服务代理）会将其从轮换中删除，所以缓慢关闭的 Pod 无法继续为流量提供服务。
      6. 当宽限期到期时，仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。
      7. kubelet 将通过设置宽限期为 0 （立即删除）来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失，并且在客户端中不再可见。

    在这里就有一个不确定因素，那就是你无法判断到底是pod先终止还是endpoints列表先更新。
    这里简单说两种情况。
    1、pod删除了endpoints还未更新，这种情况下会导致丢包。不管是从ingress还是从service来的流量，由于它们的endpoints并未及时更新，就会导致调度到已经不存在的Pod上，这样就会导致请求丢失。
    2、endpoints更新了，pod还未删除，这种情况下也会丢包。虽然前面流量进不来了，但是自己还未处理完的请求也响应不了。当然，如果pod的停止时间超过了默认的宽限期，就会被强制终止。
    鉴于此，就需要使用优雅退出来处理这种情况。

    注意：
    pod被杀死30s期间,仍然可以访问其他服务和被其他服务访问(30s内，不确定具体时间，要看服务被service后端摘除的时间)。