Kun

Kun

IT学徒、技术民工、斜杠青年,机器人爱好者、摄影爱好 PS、PR、LR、达芬奇潜在学习者

共 279 篇文章

链接

Kun's Blog

​

基本概念

Pod

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，创建，计划的最小单元.

Pod 中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络 IP，管理容器如何运行的策略选项。Pod 代表着部署的一个单位：kubernetes 中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

在 Kubernetes 集群中 Pod 有如下两种使用方式：

  • 一个 Pod 中运行一个容器。“每个 Pod 中一个容器” 的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成是单个容器的封装，kuberentes 管理的是 Pod 而不是直接管理容器。
  • 在一个 Pod 中同时运行多个容器。一个 Pod 中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个 Pod 中的容器可以互相协作成为一个 service 单位 —— 一个容器共享文件，另一个 “sidecar” 容器来更新这些文件。Pod 将这些容器的存储资源作为一个实体来管理。

Pod 中可以同时运行多个进程（作为容器运行）协同工作。同一个 Pod 中的容器会自动的分配到同一个 node 上。同一个 Pod 中的容器共享资源、网络环境和依赖，它们总是被同时调度。

注意在一个 Pod 中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为 web 服务器运行，需要用到共享的 volume，有另一个 “sidecar” 容器来从远端获取资源更新这些文件

网络

每个 Pod 都会被分配一个唯一的 IP 地址。Pod 中的所有容器共享网络空间，包括 IP 地址和端口。Pod 内部的容器可以使用 localhost 互相通信。Pod 中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）

存储

可以为一个 Pod 指定多个共享的 Volume。Pod 中的所有容器都可以访问共享的 volume。Volume 也可以用来持久化 Pod 中的存储资源，以防容器重启后文件丢失

使用Pod

你很少会直接在 kubernetes 中创建单个 Pod。因为 Pod 的生命周期是短暂的，用后即焚的实体。当 Pod 被创建后（不论是由你直接创建还是被其他 Controller），都会被 Kubernetes 调度到集群的 Node 上。直到 Pod 的进程终止、被删掉、因为缺少资源而被驱逐、或者 Node 故障之前这个 Pod 都会一直保持在那个 Node 上。

Pod 不会自愈。如果 Pod 运行的 Node 故障，或者是调度器本身故障，这个 Pod 就会被删除。同样的，如果 Pod 所在 Node 缺少资源或者 Pod 处于维护状态，Pod 也会被驱逐。Kubernetes 使用更高级的称为 Controller 的抽象层，来管理 Pod 实例。虽然可以直接使用 Pod，但是在 Kubernetes 中通常是使用 Controller 来管理 Pod 的

Pod Controller

Controller 可以创建和管理多个 Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个 Node 故障，Controller 就能自动将该节点上的 Pod 调度到其他健康的 Node 上。

安全策略

Pod 安全策略 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。 PodSecurityPolicy 对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。 它们允许管理员控制如下方面

控制面 字段名称
已授权容器的运行 privileged
为容器添加默认的一组能力 defaultAddCapabilities
为容器去掉某些能力 requiredDropCapabilities
容器能够请求添加某些能力 allowedCapabilities
控制卷类型的使用 volumes
主机网络的使用 hostNetwork
主机端口的使用 hostPorts
主机 PID namespace 的使用 hostPID
主机 IPC namespace 的使用 hostIPC
主机路径的使用 allowedHostPaths
容器的 SELinux 上下文 seLinux
用户 ID runAsUser
配置允许的补充组 supplementalGroups
分配拥有 Pod 数据卷的 FSGroup fsGroup
必须使用一个只读的 root 文件系统 readOnlyRootFilesystem

Pod 安全策略 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类：

  • 基于布尔值控制：这种类型的字段默认为最严格限制的值。
  • 基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。
  • 基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。

生命周期

Kubernetes 中 Pod 的生命周期，包括生命周期的不同阶段、存活和就绪探针、重启策略等。

Pod 的 status 字段是一个 PodStatus 对象，PodStatus 中有一个 phase 字段。

Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。该字段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。

Pod 相位的数量和含义是严格指定的。除了本文档中列举的状态外，不应该再假定 Pod 有其他的 phase 值。

下面是 phase 可能的值：

  • 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
  • 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
  • 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
  • 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
  • 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 type 字段和一个 status 字段。type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized、Unschedulable 和 ContainersReady。status 字段是一个字符串，可能的值有 True、False 和 Unknown

Pod 的 5 个阶段是 Pod 在其生命周期中所处位置的简单宏观概述，并不是对容器或 Pod 状态的综合汇总。Pod 有一些细分状态（ PodConditions ），例如 Ready/NotReady、Initialized、 PodScheduled/Unschedulable 等。这些细分状态描述造成 Pod 所处阶段的具体成因是什么。比如，Pod 当前阶段是 Pending，对应的细分状态是 Unschedulable，这就意味着 Pod 调度出现了问题

容器也有其生命周期状态（State）：Waiting、Running 和 Terminated。并且也有其对应的状态原因（Reason），例如 ContainerCreating、Error、OOMKilled、CrashLoopBackOff、Completed 等。而对于发生过重启或终止的容器，上一个状态（LastState）字段不仅包含状态原因，还包含上一次退出的状态码（Exit Code）。例如容器上一次退出状态码是 137，状态原因是 OOMKilled，说明容器是因为 OOM 被系统强行终止。在异常诊断过程中，容器的退出状态是至关重要的信息。

容器探针

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
  • HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

  • 成功：容器通过了诊断。
  • 失败：容器未通过诊断。
  • 未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

  • livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
  • readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

Hook

Pod hook（钩子）是由 Kubernetes 管理的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。

Hook 的类型包括两种：

  • exec：执行一段命令
  • HTTP：发送 HTTP 请求。

postStart 在容器创建之后（但并不能保证钩子会在容器 ENTRYPOINT 之前）执行，这时候 Pod 已经被调度到某台 node 上，被某个 kubelet 管理了，这时候 kubelet 会调用 postStart 操作，该操作跟容器的启动命令是在同步执行的，也就是说在 postStart 操作执行完成之前，kubelet 会锁住容器，不让应用程序的进程启动，只有在 postStart 操作完成之后容器的状态才会被设置成为 RUNNING。

PreStop 在容器终止之前被同步阻塞调用，常用于在容器结束前优雅的释放资源。

如果 postStart 或者 preStop hook 失败，将会终止容器

调试hook

Hook 调用的日志没有暴露给 Pod 的 event，所以只能通过 describe 命令来获取，如果有错误将可以看到 FailedPostStartHook 或 FailedPreStopHook 这样的 event

Preset

Preset 就是预设，有时候想要让一批容器在启动的时候就注入一些信息，比如 secret、volume、volume mount 和环境变量，而又不想一个一个的改这些 Pod 的 template，这时候就可以用到 PodPreset 这个资源对象了。

本页是关于 PodPreset 的概述，该对象用来在 Pod 创建的时候向 Pod 中注入某些特定信息。该信息可以包括 secret、volume、volume mount 和环境变量

Kubernetes 提供了一个准入控制器（PodPreset），当其启用时，Pod Preset 会将应用创建请求传入到该控制器上。当有 Pod 创建请求发生时，系统将执行以下操作：

  1. 检索所有可用的 PodPresets。
  2. 检查 PodPreset 标签选择器上的标签，看看其是否能够匹配正在创建的 Pod 上的标签。
  3. 尝试将由 PodPreset 定义的各种资源合并到正在创建的 Pod 中。
  4. 出现错误时，在该 Pod 上引发记录合并错误的事件，PodPreset 不会注入任何资源到创建的 Pod 中。
  5. 注释刚生成的修改过的 Pod spec，以表明它已被 PodPreset 修改过。注释的格式为 podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"。

每个 Pod 可以匹配零个或多个 Pod Prestet；并且每个 PodPreset 可以应用于零个或多个 Pod。 PodPreset 应用于一个或多个 Pod 时，Kubernetes 会修改 Pod Spec。对于 Env、EnvFrom 和 VolumeMounts 的更改，Kubernetes 修改 Pod 中所有容器的容器 spec；对于 Volume 的更改，Kubernetes 修改 Pod Spec

禁用特定Pod的Pod Preset

在某些情况下，您可能不希望 Pod 被任何 Pod Preset 所改变。在这些情况下，您可以在 Pod 的 Pod Spec 中添加注释：podpreset.admission.kubernetes.io/exclude："true"

启用Pod Preset

为了在群集中使用 Pod Preset，您必须确保以下内容：

  1. 您已启用 settings.k8s.io/v1alpha1/podpreset API 类型。例如，可以通过在 API server 的 --runtime-config 选项中包含 settings.k8s.io/v1alpha1=true 来完成此操作。
  2. 您已启用 PodPreset 准入控制器。 一种方法是将 PodPreset 包含在为 API server 指定的 --admission-control 选项值中。
  3. 您已经在要使用的命名空间中通过创建 PodPreset 对象来定义 PodPreset。

静态pod

在 Kubernetes 集群中除了我们经常使用到的普通的 Pod 外，还有一种特殊的 Pod，叫做 Static Pod，就是我们说的静态 Pod

静态 Pod 直接由特定节点上的 kubelet 进程来管理，不通过 master 节点上的 apiserver。无法与我们常用的控制器 Deployment 或者 DaemonSet 进行关联，它由 kubelet 进程自己来监控，当 pod 崩溃时重启该 pod，kubelete 也无法对他们进行健康检查。静态 pod 始终绑定在某一个 kubelet，并且始终运行在同一个节点上。 kubelet 会自动为每一个静态 pod 在 Kubernetes 的 apiserver 上创建一个镜像 Pod（Mirror Pod），因此我们可以在 apiserver 中查询到该 pod，但是不能通过 apiserver 进行控制（例如不能删除）。

创建静态 Pod 有两种方式：配置文件和 HTTP 两种方式

配置文件

配置文件就是放在特定目录下的标准的 JSON 或 YAML 格式的 pod 定义文件。用 kubelet --pod-manifest-path=<the directory> 来启动 kubelet 进程，kubelet 定期的去扫描这个目录，根据这个目录下出现或消失的 YAML/JSON 文件来创建或删除静态 pod。

比如我们在 node01 这个节点上用静态 pod 的方式来启动一个 nginx 的服务。我们登录到 node01 节点上面，可以通过下面命令找到 kubelet 对应的启动配置文件

https://zhuanlan.zhihu.com/p/612590575

pod异常场景

按照 Pod 容器是否运行为标志点，我们将异常场景大致分为两类：

  1. 在 Pod 进行调度并创建容器过程中发生异常，此时 Pod 将卡在 Pending 阶段。
  2. Pod 容器运行中发生异常，此时 Pod 按照具体场景处在不同阶段。
调度失败

常见错误状态：Unschedulable

Pod 被创建后进入调度阶段，K8s 调度器依据 Pod 声明的资源请求量和调度规则，为 Pod 挑选一个适合运行的节点。当集群节点均不满足 Pod 调度需求时，Pod 将会处于 Pending 状态。造成调度失败的典型原因如下

  • 节点资源不足

K8s 将节点资源（CPU、内存、磁盘等）进行数值量化，定义出节点资源容量（Capacity）和节点资源可分配额（Allocatable）。资源容量是指 Kubelet 获取的计算节点当前的资源信息，而资源可分配额是 Pod 可用的资源。Pod 容器有两种资源额度概念：请求值 Request 和限制值 Limit，容器至少能获取请求值大小、至多能获取限制值的资源量。Pod 的资源请求量是 Pod 中所有容器的资源请求之和，Pod 的资源限制量是 Pod 中所有容器的资源限制之和。K8s 默认调度器按照较小的请求值作为调度依据，保障可调度节点的资源可分配额一定不小于 Pod 资源请求值。当集群没有一个节点满足 Pod 的资源请求量，则 Pod 将卡在 Pending 状态。

Pod 因为无法满足资源需求而被 Pending，可能是因为集群资源不足，需要进行扩容，也有可能是集群碎片导致。以一个典型场景为例，用户集群有 10 几个 4c8g 的节点，整个集群资源使用率在 60% 左右，每个节点都有碎片，但因为碎片太小导致扩不出来一个 2c4g 的 Pod。一般来说，小节点集群会更容易产生资源碎片，而碎片资源无法供 Pod 调度使用。如果想最大限度地减少资源浪费，使用更大的节点可能会带来更好的结果。

  • 超过 Namespace 资源配额

K8s 用户可以通过资源配额（Resource Quota）对 Namespace 进行资源使用量限制，包括两个维度：

  1. 限定某个对象类型（如 Pod）可创建对象的总数。
  2. 限定某个对象类型可消耗的资源总数。

如果在创建或更新 Pod 时申请的资源超过了资源配额，则 Pod 将调度失败。此时需要检查 Namespace 资源配额状态，做出适当调整。

  • 不满足 NodeSelector 节点选择器

Pod 通过 NodeSelector 节点选择器指定调度到带有特定 Label 的节点，若不存在满足 NodeSelector 的可用节点，Pod 将无法被调度，需要对 NodeSelector 或节点 Label 进行合理调整。

  • 不满足亲和性

节点亲和性（Affinity）和反亲和性（Anti-Affinity）用于约束 Pod 调度到哪些节点，而亲和性又细分为软亲和（Preferred）和硬亲和（Required）。对于软亲和规则，K8s 调度器会尝试寻找满足对应规则的节点，如果找不到匹配的节点，调度器仍然会调度该 Pod。而当硬亲和规则不被满足时，Pod 将无法被调度，需要检查 Pod 调度规则和目标节点状态，对调度规则或节点进行合理调整。

  • 节点存在污点

K8s 提供污点（Taints）和容忍（Tolerations）机制，用于避免 Pod 被分配到不合适的节点上。假如节点上存在污点，而 Pod 没有设置相应的容忍，Pod 将不会调度到该 节点。此时需要确认节点是否有携带污点的必要，如果不必要的话可以移除污点；若 Pod 可以分配到带有污点的节点，则可以给 Pod 增加污点容忍。

  • 没有可用节点

节点可能会因为资源不足、网络不通、Kubelet 未就绪等原因导致不可用（NotReady）。当集群中没有可调度的节点，也会导致 Pod 卡在 Pending 状态。此时需要查看节点状态，排查不可用节点问题并修复，或进行集群扩容。

镜像拉取失败

常见错误状态：ImagePullBackOff

Pod 经过调度后分配到目标节点，节点需要拉取 Pod 所需的镜像为创建容器做准备。拉取镜像阶段可能存在以下几种原因导致失败：

  • 镜像名字拼写错误或配置了错误的镜像

出现镜像拉取失败后首先要确认镜像地址是否配置错误。

  • 私有仓库的免密配置错误

集群需要进行免密配置才能拉取私有镜像。自建镜像仓库时需要在集群创建免密凭证 Secret，在 Pod 指定 ImagePullSecrets，或者将 Secret 嵌入 ServicAccount，让 Pod 使用对应的 ServiceAccount。而对于 acr 等镜像服务云产品一般会提供免密插件，需要在集群中正确安装免密插件才能拉取仓库内的镜像。免密插件的异常包括：集群免密插件未安装、免密插件 Pod 异常、免密插件配置错误，需要查看相关信息进行进一步排查。

  • 网络不通

网络不通的常见场景有三个：

  1. 集群通过公网访问镜像仓库，而镜像仓库未配置公网的访问策略。对于自建仓库，可能是端口未开放，或是镜像服务未监听公网 IP；对于 acr 等镜像服务云产品，需要确认开启公网的访问入口，配置白名单等访问控制策略。
  2. 集群位于专有网络，需要为镜像服务配置专有网络的访问控制，才能建立集群节点与镜像服务之间的连接。
  3. 拉取海外镜像例如 gcr.io 仓库镜像，需配置镜像加速服务。
  4. 镜像拉取超时

常见于带宽不足或镜像体积太大，导致拉取超时。可以尝试在节点上手动拉取镜像，观察传输速率和传输时间，必要时可以对集群带宽进行升配，或者适当调整 Kubelet 的 --image-pull-progress-deadline 和 --runtime-request-timeout 选项。

  • 同时拉取多个镜像，触发并行度控制

常见于用户弹性扩容出一个节点，大量待调度 Pod 被同时调度上去，导致一个节点同时有大量 Pod 启动，同时从镜像仓库拉取多个镜像。而受限于集群带宽、镜像仓库服务稳定性、容器运行时镜像拉取并行度控制等因素，镜像拉取并不支持大量并行。这种情况可以手动打断一些镜像的拉取，按照优先级让镜像分批拉取。

依赖项错误

常见错误状态：Error

在 Pod 启动之前，Kubelet 将尝试检查与其他 K8s 元素的所有依赖关系。主要存在的依赖项有三种：PersistentVolume、ConfigMap 和 Secret。当这些依赖项不存在或者无法读取时，Pod 容器将无法正常创建，Pod 会处于 Pending 状态直到满足依赖性。当这些依赖项能被正确读取，但出现配置错误时，也会出现无法创建容器的情况。比如将一个只读的持久化存储卷 PersistentVolume 以可读写的形式挂载到容器，或者将存储卷挂载到 /proc 等非法路径，也会导致容器创建失败。

容器创建失败

常见错误状态：Error

Pod 容器创建过程中出现了错误。常见原因包括：

  • 违反集群的安全策略，比如违反了 PodSecurityPolicy 等。
  • 容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定。
  • 缺少启动命令，Pod 描述文件和镜像 Dockerfile 中均未指定启动命令。
  • 启动命令配置错误。Pod 配置文件可以通过 command 字段定义命令行，通过 args 字段给命令行定义参数。启动命令配置错误的情况非常多见，要格外注意命令及参数的格式。
初始化失败

常见错误状态：CrashLoopBackOff

K8s 提供 Init Container 特性，用于在启动应用容器之前启动一个或多个初始化容器，完成应用程序所需的预置条件。Init container 与应用容器本质上是一样的，但它们是仅运行一次就结束的任务，并且必须在执行完成后，系统才能继续执行下一个容器。如果 Pod 的 Init Container 执行失败，将会 block 业务容器的启动。通过查看 Pod 状态和事件定位到 Init Container 故障后，需要查看 Init Container 日志进一步排查故障点。

回调失败

常见错误状态：FailedPostStartHook 或 FailedPreStopHook 事件

K8s 提供 PostStart 和 PreStop 两种容器生命周期回调，分别在容器中的进程启动前或者容器中的进程终止之前运行。PostStart 在容器创建之后立即执行，但由于是异步执行，无法保证和容器启动命令的执行顺序相关联。如果 PostStart 或者 PreStop 回调程序执行失败，常用于在容器结束前优雅地释放资源。如果 PostStart 或者 PreStop 回调程序执行失败失败，容器将被终止，按照重启策略决定是否重启。当出现回调失败，会出现 FailedPostStartHook 或 FailedPreStopHook 事件，进一步结合容器打出的日志进行故障排查。

就绪探针失败

常见错误状态：容器已经全部启动，但是 Pod 处于 NotReady 状态，服务流量无法从 Service 达到 Pod

K8s 使用 Readiness Probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时，K8s 才认定该 Pod 处于就绪状态，才会将服务流量转发到该容器。一般就绪探针失败分为几种情况：

  • 容器内应用原因：健康检查所配置规则对应的端口或者脚本，无法成功探测，如容器内应用没正常启动等。
  • 探针配置不当：写错检查端口导致探测失败；检测间隔和失败阈值设置不合理，例如每次检查间隔 1s，一次不通过即失败；启动延迟设置太短，例如应用正常启动需要 15s，而设置容器启动 10s 后启用探针。
  • 系统层问题：节点负载高，导致容器进程 hang 住。
  • CPU 资源不足：CPU 资源限制值过低，导致容器进程响应慢。

需要特别说明的是，对于微服务应用，服务的注册和发现由注册中心管理，流量不会经过 Service，直接从上游 Pod 流到下游 Pod。然而注册中心并没有如 K8s 就绪探针的检查机制，对于启动较慢的 JAVA 应用来说，服务注册成功后所需资源仍然可能在初始化中，导致出现上线后流量有损的情况。对于这一类场景，EDAS 提供延迟注册和服务预热等解决方案，解决 K8s 微服务应用上线有损的问题。

存活探针失败

常见错误状态：CrashLoopBackOff

K8s 使用 Liveness Probe（存活探针）来确定容器是否正在运行。如果存活态探测失败，则容器会被杀死，随之按照重启策略决定是否重启。存活探针失败的原因与就绪探针类似，然而存活探针失败后容器会被 kill 消失，所以排障过程要棘手得多。一个典型的用户场景是，用户在压测期间通过 HPA 弹性扩容出多个新 Pod，然而新 Pod 一启动就被大流量阻塞，无法响应存活探针，导致 Pod 被 kill。kill 后又重启，重启完又挂掉，一直在 Running 和 CrashLoopBackOff 状态中振荡。微服务场景下可以使用延迟注册和服务预热等手段，避免瞬时流量打挂容器。如果是程序本身问题导致运行阻塞，建议先将 Liveness 探针移除，通过 Pod 启动后的监控和进程堆栈信息，找出流量涌入后进程阻塞的根因。

容器退出

常见错误状态：CrashLoopBackOff

容器退出分为两种场景：

  • 启动后立即退出，可能原因是：
  • 启动命令的路径未包含在环境变量 PATH 中。
  • 启动命令引用了不存在的文件或目录。
  • 启动命令执行失败，可能因为运行环境缺少依赖，也可能是程序本身原因。
  • 启动命令没有执行权限。
  • 容器中没有前台进程。容器应该至少包含一个 long-running 的前台进程，不能后台运行，比如通过 nohup 这种方式去启动进程，或是用 tomcat 的 startup.sh 脚本。

对于容器启动后立即退出的情况，通常因为容器直接消失，无法获取其输出流日志，很难直接通过现场定位问题。一个简易的排查方式是，通过设置特殊的启动命令卡住容器（比如使用 tail -f /dev/null），然后进到容器中手动执行命令看看结果，确认问题原因。

OOMKilled

K8s 中有两种资源概念：可压缩资源（CPU）和不可压缩资源（内存，磁盘 ）。当 CPU 这种可压缩资源不足时，Pod 只会 “饥饿”，但不会退出；而当内存和磁盘 IO 这种不可压缩资源不足时，Pod 会被 kill 或者驱逐。因为内存资源不足 / 超限所导致的 Pod 异常退出的现象被称为 Pod OOMKilled。K8s 存在两种导致 Pod OOMKilled 的场景：

  • Container Limit Reached，容器内存用量超限

Pod 内的每一个容器都可以配置其内存资源限额，当容器实际占用的内存超额，该容器将被 OOMKilled 并以状态码 137 退出。OOMKilled 往往发生在 Pod 已经正常运行一段时间后，可能是由于流量增加或是长期运行累积的内存逐渐增加。这种情况需要查看程序日志以了解为什么 Pod 使用的内存超出了预期，是否出现异常行为。如果发现程序只是按照预期运行就发生了 OOM，就需要适当提高 Pod 内存限制值。一个很常见的错误场景是，JAVA 容器设置了内存资源限制值 Limit，然而 JVM 堆大小限制值比内存 Limit 更大，导致进程在运行期间堆空间越开越大，最终因为 OOM 被终止。对于 JAVA 容器来说，一般建议容器内存限制值 Limit 需要比 JVM 最大堆内存稍大一些。

  • Limit Overcommit，节点内存耗尽

K8s 有两种资源额度概念：请求值 Request 和限制值 Limit，默认调度器按照较小的请求值作为调度依据，保障节点的所有 Pod 资源请求值总和不超过节点容量，而限制值总和允许超过节点容量，这就是 K8s 资源设计中的 Overcommit（超卖）现象。超卖设计在一定程度上能提高吞吐量和资源利用率，但会出现节点资源被耗尽的情况。当节点上的 Pod 实际使用的内存总和超过某个阈值，K8s 将会终止其中的一个或多个 Pod。为了尽量避免这种情况，建议在创建 Pod 时选择大小相等或相近的内存请求值和限制值，也可以利用调度规则将内存敏感型 Pod 打散到不同节点。

POD 驱逐

常见错误状态：Pod Evicted

当节点内存、磁盘这种不可压缩资源不足时，K8s 会按照 QoS 等级对节点上的某些 Pod 进行驱逐，释放资源保证节点可用性。当 Pod 发生驱逐后，上层控制器例如 Deployment 会新建 Pod 以维持副本数，新 Pod 会经过调度分配到其他节点创建运行。对于内存资源，前文已经分析过可以通过设置合理的请求值和限制值，避免节点内存耗尽。而对于磁盘资源，Pod 在运行期间会产生临时文件、日志，所以必须对 Pod 磁盘容量进行限制，否则某些 Pod 可能很快将磁盘写满。类似限制内存、CPU 用量的方式，在创建 Pod 时可以对本地临时存储用量（ephemeral-storage）进行限制。同时，Kubelet 驱逐条件默认磁盘可用空间在 10% 以下，可以调整云监控磁盘告警阈值以提前告警。

Pod失联

常见错误状态：Unkonwn

Pod 处于 Unkonwn 状态，无法获取其详细信息，一般是因为所在节点 Kubelet 异常，无法向 APIServer 上报 Pod 信息。首先检查节点状态，通过 Kubelet 和容器运行时的日志信息定位错误，进行修复。如果无法及时修复节点，可以先将该节点从集群中删除。

无法被删除

常见错误状态：卡在 Terminating

当一个 Pod 被执行删除操作后，却长时间处于 Terminating 状态，这种情况的原因有几种：

  • Pod 关联的 finalizer 未完成。首先查看 Pod 的 metadata 字段是否包含 finalizer，通过一些特定上下文信息确认 finalizer 任务具体是什么，通常 finalizer 的任务未完成可能是因为与 Volume 相关。如果 finalizer 已经无法被完成，可以通过 patch 操作移除对应的 Pod 上的 finalizer 完成删除操作。
  • Pod 对中断信号没有响应。Pod 没有被终止可能是进程对信号没有响应，可以尝试强制删除 Pod。
  • 节点故障。通过查看相同节点上的其他 Pod 状态确认是否节点故障，尝试重启 Kubelet 和容器运行时。如果无法修复，先将该节点从集群中删除。

控制器

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义（declarative）方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：

  • 定义 Deployment 来创建 Pod 和 ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续 Deployment

Deployment 为 Pod 和 Replica Set（下一代 Replication Controller）提供声明式更新。

您只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和 ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

注意：您不该手动管理由 Deployment 创建的 ReplicaSet，否则您就篡越了 Deployment controller 的职责！下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例，请直接在 Kubernetes 的代码库中提 issue。

典型的用例如下：

  • 使用 Deployment 来创建 ReplicaSet。ReplicaSet 在后台创建 pod。检查启动状态，看它是成功还是失败。
  • 然后，通过更新 Deployment 的 PodTemplateSpec 字段来声明 Pod 的新状态。这会创建一个新的 ReplicaSet，Deployment 会按照控制的速率将 pod 从旧的 ReplicaSet 移动到新的 ReplicaSet 中。
  • 如果当前状态不稳定，回滚到之前的 Deployment revision。每次回滚都会更新 Deployment 的 revision。
  • 扩容 Deployment 以满足更高的负载。
  • 暂停 Deployment 来应用 PodTemplateSpec 的多个修复，然后恢复上线。
  • 根据 Deployment 的状态判断上线是否 hang 住了。
  • 清除旧的不必要的 ReplicaSet。

StatefulSet

StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序

StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

  • 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
  • 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
  • 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
  • 有序收缩，有序删除（即从 N-1 到 0）

从上面的应用场景可以发现，StatefulSet 由以下几个部分组成：

  • 用于定义网络标志（DNS domain）的 Headless Service
  • 用于创建 PersistentVolumes 的 volumeClaimTemplates
  • 定义具体应用的 StatefulSet

StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local，其中

  • serviceName 为 Headless Service 的名字
  • 0..N-1 为 Pod 所在的序号，从 0 开始到 N-1
  • statefulSetName 为 StatefulSet 的名字
  • namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
  • .cluster.local 为 Cluster Domain

使用StatefulSet

StatefulSet 适用于有以下某个或多个需求的应用：

  • 稳定，唯一的网络标志。
  • 稳定，持久化存储。
  • 有序，优雅地部署和 scale。
  • 有序，优雅地删除和终止。
  • 有序，自动的滚动升级。

在上文中，稳定是 Pod （重新）调度中持久性的代名词。 如果应用程序不需要任何稳定的标识符、有序部署、删除和 scale，则应该使用提供一组无状态副本的 controller 来部署应用程序，例如 Deployment 或 ReplicaSet 可能更适合您的无状态需求

DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

使用 DaemonSet 的一些典型用法：

  • 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
  • 在每个 Node 上运行日志收集 daemon，例如 fluentd、logstash。
  • 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

一个简单的用法是，在所有的 Node 上都存在一个 DaemonSet，将被作为每种类型的 daemon 使用。 一个稍微复杂的用法可能是，对单独的每种类型的 daemon 使用多个 DaemonSet，但具有不同的标志，和 / 或对不同硬件类型具有不同的内存、CPU 要求

DaemonSet 需要 apiVersion、kind 和 metadata 字段

与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：

  • Push：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
  • NodeIP 和已知端口：DaemonSet 中的 Pod 可以使用 hostPort，从而可以通过 Node IP 访问到 Pod。客户端能通过某种方法知道 Node IP 列表，并且基于此也可以知道端口。
  • DNS：创建具有相同 Pod Selector 的 Headless Service，然后通过使用 endpoints 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
  • Service：创建具有相同 Pod Selector 的 Service，并使用该 Service 访问到某个随机 Node 上的 daemon。（没有办法访问到特定 Node）

更新DaemonSet

如果修改了 Node Label，DaemonSet 将立刻向新匹配上的 Node 添加 Pod，同时删除新近无法匹配上的 Node 上的 Pod。

可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次 Node（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。

可以删除一个 DaemonSet。如果使用 kubectl 并指定 --cascade=false 选项，则 Pod 将被保留在 Node 上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将鞥能够通过 Label 匹配识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者 删除 Node，可以强制创建新的 Pod。

在 Kubernetes 1.6 或以后版本，可以在 DaemonSet 上 执行滚动升级。

Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。

Job Spec格式

  • spec.template 格式同 Pod
  • RestartPolicy 仅支持 Never 或 OnFailure
  • 单个 Pod 时，默认 Pod 成功运行后 Job 即结束
  • .spec.completions 标志 Job 结束需要成功运行的 Pod 个数，默认为 1
  • .spec.parallelism 标志并行运行的 Pod 的个数，默认为 1
  • spec.activeDeadlineSeconds 标志失败 Pod 的重试最大时间，超过这个时间不会继续重试

所谓 Bare Pod 是指直接用 PodSpec 来创建的 Pod（即不在 ReplicaSet 或者 ReplicationController 的管理之下的 Pod）。这些 Pod 在 Node 重启后不会自动重启，但 Job 则会创建新的 Pod 继续任务。所以，推荐使用 Job 来替代 Bare Pod，即便是应用只需要一个 Pod。

CronJob

Cron Job 管理基于时间的 Job，即：

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行

当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 < 1.8，启动 API Server（参考 为集群开启或关闭 API 版本 获取更多信息）时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启 batch/v2alpha1 API。

典型的用法如下所示：

  • 在给定的时间点调度 Job 运行
  • 创建周期性运行的 Job，例如：数据库备份、发送邮件。

Cron Job的spec文件

  • .spec.schedule：调度，必需字段，指定任务运行周期，格式同 Cron
  • .spec.jobTemplate：Job 模板，必需字段，指定需要运行的任务，格式同 Job
  • .spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限

  • .spec.concurrencyPolicy：并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：

    • Allow（默认）：允许并发运行 Job
    • Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
    • Replace：取消当前正在运行的 Job，用一个新的来替换

    注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。

  • .spec.suspend ：挂起，该字段也是可选的。如果设置为 true，后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为 false。

  • .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。

    默认情况下，它们分别设置为 3 和 1。设置限制的值为 0，相关类型的 Job 完成后将不会被保留

当然，也可以用 kubectl run 来创建一个 CronJob

kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"

限制

Cron Job 在每次调度运行时间内 大概 会创建一个 Job 对象。我们之所以说 大概 ，是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。我们尝试少发生这种情况，但却不能完全避免。因此，创建 Job 操作应该是 幂等的。

Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决定这一组 Pod 的成功或失败。Cron Job 根本就不会去检查 Pod。

删除Cron Job

Events

https://moelove.info/2021/12/28/%E5%BD%BB%E5%BA%95%E6%90%9E%E6%87%82-Kubernetes-%E4%B8%AD%E7%9A%84-Events/#%E5%BD%BB%E5%BA%95%E6%90%9E%E6%87%82-events

https://github.com/opsgenie/kubernetes-event-exporter

扩缩容

Kubernetes 1.33 版本带来了我们梦寐以求的功能：原地垂直扩缩容

这一功能在不同的容器运行时中均可使用，但支持程度有差异，情况如下：

  • containerd（v1.6+）：完全支持，可以平滑调整 CPU 和内存的 cgroup
  • CRI-O（v1.24+）：完全支持原地扩缩容
  • Docker：支持有限，因为它正在逐步退出 Kubernetes

水平扩缩容

在 Kubernetes 中，HorizontalPodAutoscaler 自动更新工作负载资源 （例如 Deployment 或者 StatefulSet）， 目的是自动扩缩工作负载以满足需求。

水平扩缩意味着对增加的负载的响应是部署更多的 Pod。 这与“垂直（Vertical）”扩缩不同，对于 Kubernetes， 垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。

如果负载减少，并且 Pod 的数量高于配置的最小值， HorizontalPodAutoscaler 会指示工作负载资源（Deployment、StatefulSet 或其他类似资源）缩减。

水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：DaemonSet。）

HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和控制器。

资源决定了控制器的行为。 在 Kubernetes 控制平面内运行的水平 Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标， 例如，平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标。

Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数设置（默认间隔为 15 秒）。

在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 控制器管理器找到由 scaleTargetRef 定义的目标资源，然后根据目标资源的 .spec.selector 标签选择 Pod， 并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。

  • 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，控制器获取每个 Pod 中的容器资源使用情况， 并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。

    需要注意的是，如果 Pod 某些容器不支持资源采集，那么控制器将不会使用该 Pod 的 CPU 使用率。 下面的算法细节章节将会介绍详细的算法。

  • 如果 Pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。
  • 如果 Pod 使用对象指标和外部指标（每个指标描述一个对象信息）。 这个指标将直接根据目标设定值相比较，并生成一个上面提到的扩缩比例。 在 autoscaling/v2 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。

HorizontalPodAutoscaler 的常见用途是将其配置为从聚合 API （metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io）获取指标。 metrics.k8s.io API 通常由名为 Metrics Server 的插件提供

如果 HorizontalPodAutoscaler 指定的是 targetAverageValue 或 targetAverageUtilization， 那么将会把指定 Pod 度量值的平均值做为 currentMetricValue。

HorizontalPodAutoscaler（HPA）控制器有两个标志会影响 Pod 启动期间如何收集其 CPU 指标：

  1. --horizontal-pod-autoscaler-cpu-initialization-period（默认：5 分钟）

    此标志所定义的是 Pod 启动后的一个时间窗口，在此期间内其 CPU 使用率被忽略，除非：

    • Pod 处于 Ready 状态且
    • 指标样本完全是在它处于 Ready 状态期间采集的。

    此标志有助于排除初始化 Pod 中的误导性高 CPU 使用率 （例如，Java 应用程序预热）对 HPA 扩缩决策的影响。

  2. --horizontal-pod-autoscaler-initial-readiness-delay（默认：30 秒）

    这定义了一个短暂的延迟期，在 Pod 启动后，HPA 控制器将当前为 Unready 的 Pod 视为仍在初始化中，即使它们之前曾短暂转变为 Ready。

    其设计目的是：

    • 避免包含在启动期间快速在 Ready 和 Unready 之间波动的 Pod。
    • 确保在 HPA 认为它们的指标有效之前，初始就绪信号的稳定性。

关键行为：

  • 如果一个 Pod 是 Ready 状态并且保持 Ready，即使在延迟期间， 它也可以被视为贡献指标。
  • 如果一个 Pod 在 Ready 和 Unready 之间快速切换，那么它的指标将被忽略， 直到它被认为稳定在 Ready 状态。

最佳实践

如果你的 Pod 有一个 CPU 使用率较高的启动阶段：

  • 配置 startupProbe，使其在高 CPU 使用率结束之前不会传递，或
  • 使用 initialDelaySeconds，确保你的 readinessProbe 在 CPU 峰值过后才报告为 Ready

Ingress

Kubernetes 还为我们提供了一个非常重要的资源对象可以用来暴露服务给外部用户，那就是 Ingress。对于小规模的应用我们使用 NodePort 或许能够满足我们的需求，但是当你的应用越来越多的时候，你就会发现对于 NodePort 的管理就非常麻烦了，这个时候使用 Ingress 就非常方便了，可以避免管理大量的端口。

Ingress 其实就是从 Kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，可能你会觉得我们直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能让我们去手动更改或者滚动更新前端的 Nginx Pod 吧？那我们再加上一个服务发现的工具比如 consul 如何？貌似是可以，对吧？Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新依靠 Ingress Controller 来提供。

Ingress Controller 可以理解为一个监听器，通过不断地监听 kube-apiserver，实时的感知后端 Service、Pod 的变化，当得到这些信息变化后，Ingress Controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用。其实这点和服务发现工具 consul、 consul-template 非常类似。

ingress flow

现在可以供大家使用的 Ingress Controller 有很多，比如 traefik、nginx-controller、Kubernetes Ingress Controller for Kong、HAProxy Ingress controller，当然你也可以自己实现一个 Ingress Controller，现在普遍用得较多的是 traefik 和 nginx-controller，traefik 的性能较 nginx-controller 差，但是配置使用要简单许多，我们这里会重点给大家介绍 nginx-controller 的使用。

Nginx Ingress Controller

https://cloud.tencent.com/developer/article/1761376

https://rocdu.gitbook.io/ingress-nginx-docs-cn

NGINX Ingress Controller 是使用 Kubernetes Ingress 资源对象构建的，用 ConfigMap 来存储 Nginx 配置的一种 Ingress Controller 实现。

要使用 Ingress 对外暴露服务，就需要提前安装一个 Ingress Controller，我们这里就先来安装 NGINX Ingress Controller，由于 nginx-ingress 所在的节点需要能够访问外网，这样域名可以解析到这些节点上直接使用，所以需要让 nginx-ingress 绑定节点的 80 和 443 端口，所以可以使用 hostPort 来进行访问，当然对于线上环境来说为了保证高可用，一般是需要运行多个 nginx-ingress 实例的，然后可以用一个 nginx/haproxy 作为入口，通过 keepalived 来访问边缘节点的 vip 地址。

“所谓的边缘节点即集群内部用来向集群外暴露服务能力的节点，集群外部的服务通过该节点来调用集群内部的服务，边缘节点是集群内外交流的一个 Endpoint。“

URL rewrite

NGINX Ingress Controller 很多高级的用法可以通过 Ingress 对象的 annotation 进行配置，比如常用的 URL Rewrite 功能，比如我们有一个 todo 的前端应用，代码位于 https://github.com/cnych/todo-app，直接部署这个应用进行测试：

Basic Auth

同样我们还可以在 Ingress Controller 上面配置一些基本的 Auth 认证，比如 Basic Auth，可以用 htpasswd 生成一个密码文件来验证身份验证

灰度发布

在日常工作中我们经常需要对服务进行版本更新升级，所以我们经常会使用到滚动升级、蓝绿发布、灰度发布等不同的发布操作。而 ingress-nginx 支持通过 Annotations 配置来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。ingress-nginx 的 Annotations 支持以下 4 种 Canary 规则：

  • nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
  • nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header) 一起使用。
  • nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求，权重为 100 意味着所有请求都将被发送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-cookie：基于 cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口；当 cookie 值设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

总的来说可以把以上的四个 annotation 规则划分为以下两类：

  • 基于权重的 Canary 规则
  • 基于用户请求的 Canary 规则

Traefik Ingress Controller

Kubernetes-ingress-controller

https://github.com/kong/kubernetes-ingress-controller

kube-vip

kube-vip 是一个为 Kubernetes 集群内部和外部提供高可用和负载均衡的开源项目。

kube-vip 支持以静态 Pod 的形式运行在 Control Plane 节点上，这样就可以不需要部署 HAProxy + Keepalived 等传统的 LB 来保证高可用。

kube-vip 静态 Pod 通过 ARP 会话来识别每个节点上的其他主机，我们可以选择 BGP 或 ARP 来设置负载平衡器。在 ARP 模式下，会选出一个领导者，这个节点将继承虚拟 IP 并成为集群内负载均衡的 Leader，而在 BGP 模式下，所有节点都会通知 VIP 地址。

通过把 kube-vip 静态 Pod 的 yaml 文件配置到 cloud-init 的脚本中，当 cloud-init 命令执行的时候会把 kube-vip yaml 的相关内容写入到 control plane 节点机器上的 /etc/kubernetes/manifests/kube-vip.yaml 文件中。kubeadm 部署 control plane 节点的过程，在启动静态 Pod 的阶段，就会启动 kube-vip 服务

CAPI 通过 MHC 为集群定义节点故障替换信息，由 KCP 和 MD/MS 配合完成故障节点的替换工作

云原生可划分为容器与容器编排、应用开发与部署、服务治理、可观测性等领域，每个领域一般有多种实现方案，云原生平台可以理解为是多个领域的有机整合。与此相似，Kubernetes 也可划分多个领域，网络、存储、容器，每个领域都有标准（CNI、CSI、CRI 等）和不同的实现方案。CAPI 有多种 Provider，每种 Provider 可以有多种实现。

external-dns

Kube-DNS

如果你觉得我的文章对你有帮助的话，希望可以推荐和交流一下。欢迎關注和 Star 本博客或者关注我的 Github。