Linkerd 2.10(Step by Step)—优雅的 Pod 关闭

Linkerd 2.10 系列

• 快速上手 Linkerd v2.10 Service Mesh（服务网格）
• 腾讯云 K8S 集群实战 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 应用
• 详细了解 Linkerd 2.10 基础功能，一起步入 Service Mesh 微服务架构时代
• Linkerd 2.10—将您的服务添加到 Linkerd
• Linkerd 2.10—自动化的金丝雀发布
• Linkerd 2.10—自动轮换控制平面 TLS 与 Webhook TLS 凭证
• Linkerd 2.10—如何配置外部 Prometheus 实例
• Linkerd 2.10—配置代理并发
• Linkerd 2.10—配置重试
• Linkerd 2.10—配置超时
• Linkerd 2.10—控制平面调试端点
• Linkerd 2.10—使用 Kustomize 自定义 Linkerd 的配置

Linkerd 2.10 中文手册持续修正更新中：

• linkerd.hacker-linner.com

当 Kubernetes 开始终止一个 Pod 时，它首先向该 Pod 中的所有容器发送一个 TERM 信号。 当 Linkerd 代理 sidecar 收到此信号时， 它将立即开始正常关闭， 拒绝所有新请求并允许现有请求在关闭之前完成。

这意味着如果 Pod 的主容器在代理收到 TERM 信号后尝试进行任何新的网络调用， 这些网络调用将失败。 这也会对终止 Pod 的客户端和作业资源(job resources)产生影响。

客户端更新缓慢

在 Kubernetes 终止一个 Pod 之前，它首先从该 Pod 所属的任何服务的端点资源中删除该 Pod。 这意味着该服务的客户端应该在终止之前停止向 Pod 发送流量。 但是，某些客户端接收端点更新的速度可能很慢， 并且可能会在 Pod 的代理已经收到 TERM 信号并开始正常关闭后尝试向终止 Pod 发送请求。 这些请求将失败。

为了缓解这种情况，使用 --wait-before-exit-seconds 标志 和 linkerd inject 来使用 preStop 钩子将 Linkerd 代理对 TERM 信号的处理延迟给定的秒数。 在开始正常关闭之前，此延迟为慢速客户端提供了额外的时间来接收端点更新。 为了从该选项中获得最大收益，主容器应该有自己的 preStop 钩子， 其中的 sleep 命令的周期小于为代理 sidecar 设置的周期。 并且它们都不能大于为整个 pod 配置的 terminationGracePeriodSeconds。

例如，

       # application container
        lifecycle:
          preStop:
            exec:
              command:
                - /bin/bash
                - -c
                - sleep 20

    # for entire pod
    terminationGracePeriodSeconds: 160

Job Resources

作为 job resource 一部分的 Pod 会一直运行，直到 Pod 中的所有容器都完成。 但是，Linkerd 代理容器会持续运行，直到收到 TERM 信号。 这意味着已注入的 job pods 将继续运行，即使主容器已完成。

已经提议更好地支持 sidecar containers in Kubernetes， Linkerd 将在该支持可用时利用该支持。

我是为少
微信：uuhells123
公众号：黑客下午茶
加我微信（互相学习交流），关注公众号（获取更多学习资料~）