k8s-Controller | GJJ’s Blog

type

status

date

slug

summary

Deployment

应用场景

首先，Deployment 定义了一种 Pod 期望数量，比如说应用 A，我们期望 Pod 数量是四个，那么这样的话，controller 就会持续维持 Pod 数量为期望的数量。当我们与 Pod 出现了网络问题或者宿主机问题的话，controller 能帮我们恢复，也就是新扩出来对应的 Pod，来保证可用的 Pod 数量与期望数量一致；

配置 Pod 发布方式，也就是说 controller 会按照用户给定的策略来更新 Pod，而且更新过程中，也可以设定不可用 Pod 数量在多少范围内；

如果更新过程中发生问题的话，即所谓“一键”回滚，也就是说你通过一条命令或者一行修改能够将 Deployment 下面所有 Pod 更新为某一个旧版本

语法

replicas，就是 Deployment 中期望的或者终态数量；

template，也就是 Pod 相关的一个模板

Deployment状态

使用kubectl get deployment 查看状态

DESIRED：期望的 Pod 数量是 3 个；

CURRENT：当前实际 Pod 数量是 3 个；

UP-TO-DATE：其实是到达最新的期望版本的 Pod 数量；

AVAILABLE：这个其实是运行过程中可用的 Pod 数量。后面会提到，这里 AVAILABLE 并不简单是可用的，也就是 Ready 状态的，它其实包含了一些可用超过一定时间长度的 Pod；

AGE：deployment 创建的时长，如上图 Deployment 就是已经创建了 80 分钟。

查看pod

使用 kubectl get pod

更新镜像

快速回滚

DeploymeStatus

Processing 指的是 Deployment 正在处于扩容和发布中。

比如说 Processing 状态的 deployment，它所有的 replicas 及 Pod 副本全部达到最新版本，而且是 available，这样的话，就可以进入 complete 状态。

而 complete 状态如果发生了一些扩缩容的话，也会进入 processing 这个处理工作状态。

如果在处理过程中遇到一些问题：比如说拉镜像失败了，或者说 readiness probe 检查失败了，就会进入 failed 状态；

如果在运行过程中即 complete 状态，中间运行时发生了一些 pod readiness probe 检查失败，这个时候 deployment 也会进入 failed 状态。

进入 failed 状态之后，除非所有点 replicas 均变成 available，而且是 updated 最新版本，deployment 才会重新进入 complete 状态

Job

CronJob

ReplicationController 和 ReplicaSet

StatefulSet

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

组成

用于定义网络标志（DNS domain）的Headless Service

用于创建PersistentVolumes的volumeClaimTemplates

定义具体应用的StatefulSet

应用场景

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）

限制

组件

Pod 身份

StatefulSet Pod 具有唯一的身份，包括序数，稳定的网络身份和稳定的存储。身份绑定到 Pod 上，不管它（重新）调度到哪个节点上。

DNS格式

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的Pod

我们设想一下这样的场景：在kubernetes集群外部调试StatefulSet中有序的Pod，那么如何访问这些的pod呢？

方法是为pod设置label，然后用kubectl expose将其以NodePort的方式暴露到集群外部，以上面的zookeeper的例子来说明，下面使用命令的方式来暴露其中的两个zookeeper节点，也可以写一个serivce配置yaml文件。

这样在kubernetes集群外部就可以根据pod所在的主机所映射的端口来访问了。

查看zk-0这个service可以看到如下结果：

集群外部就可以使用所有的node中的任何一个IP:31693来访问这个zookeeper实例。

HPA

Horizontal Pod Autoscaling（HPA）是 Kubernetes 中的一种机制，用于根据特定指标动态调整 Pod 的副本数量，以满足应用程序的需求并提高资源利用率。HPA 可以根据指定的资源使用率（如 CPU 利用率、内存利用率）或自定义的指标来自动缩放 Pod 的数量。

HPA 的工作原理如下：

监控指标：HPA 监控与目标 Deployment 或 ReplicationController 关联的指标，这些指标可以是 CPU 使用率、内存使用率等，也可以是自定义的指标。

决策：根据监控的指标和用户定义的目标值（如目标 CPU 利用率百分比），HPA 决定是否需要增加或减少 Pod 的副本数量。如果监控指标超过或低于阈值，则触发缩放动作。

缩放操作：根据决策，HPA 可以自动调整 Pod 的副本数量。如果需要增加副本，则会自动启动新的 Pod；如果需要减少副本，则会自动删除多余的 Pod。

周期性检查：HPA 定期检查监控指标，并根据需要执行缩放操作。这个周期可以由用户自定义。

弹性伸缩应该包括：

Cluster Autoscaler：它负责自动调整集群的容量，即节点数量。当集群中的工作负载增加时，Cluster Autoscaler 可以动态地增加节点以容纳更多的 Pod。当工作负载减少时，它可以自动缩减节点数量以节省资源成本。这种弹性伸缩主要针对虚拟机或容器集群的物理资源。

Vertical Pod Autoscaler：它负责自动调整单个 Pod 的资源配置，即 Pod 的 CPU 和内存限制/请求。当 Pod 的工作负载增加时，Vertical Pod Autoscaler 可以自动增加 Pod 的资源配置，以确保 Pod 能够满足其资源需求。这种弹性伸缩主要依赖于历史负载指标，根据过去的资源使用情况来调整 Pod 的资源配置。

Horizontal Pod Autoscaler：它负责自动调整 Pod 的数量，即 Pod 的副本数量。当工作负载增加时，Horizontal Pod Autoscaler 可以自动增加 Pod 的副本数量，以应对流量增加。当工作负载减少时，它可以自动减少 Pod 的副本数量，以节省资源成本。这种弹性伸缩主要依赖于实时负载指标，根据当前的流量情况来调整 Pod 的数量。

VPA 和 HPA 分别解决了资源配置和副本数量的自动调整问题，从而提高了 Kubernetes 集群的资源利用率和应用程序的性能稳定性。它们的引入使得管理和调整应用程序的资源更加自动化和智能化。

使用 kubectl 管理

Horizontal Pod Autoscaling 作为 API resource 也可以像 Pod、Deployment 一样使用 kubeclt 命令管理，使用方法跟它们一样，资源名称为 hpa。

有一点不同的是，可以直接使用 kubectl autoscale 直接通过命令行的方式创建 Horizontal Pod Autoscaler。

用法如下：

举个例子：

为 Deployment foo 创建一个 autoscaler，当 Pod 的 CPU 利用率达到 80% 的时候，RC 的 replica 数在 2 到 5 之间。

DaemonSet

背景

首先如果希望每个节点都运行同样一个 pod 怎么办？

如果新节点加入集群的时候，想要立刻感知到它，然后去部署一个 pod，帮助我们初始化一些东西，这个需求如何做？

如果有节点退出的时候，希望对应的 pod 会被删除掉，应该怎么操作？

如果 pod 状态异常的时候，我们需要及时地监控这个节点异常，然后做一些监控或者汇报的一些动作，那么这些东西运用什么控制器来做？

DaemonSet：守护进程控制器

DaemonSet 也是 Kubernetes 提供的一个 default controller，它实际是做一个守护进程的控制器，它能帮我们做到以下几件事情：

首先能保证集群内的每一个节点都运行一组相同的 pod；

同时还能根据节点的状态保证新加入的节点自动创建对应的 pod；

在移除节点的时候，能删除对应的 pod；

而且它会跟踪每个 pod 的状态，当这个 pod 出现异常、Crash 掉了，会及时地去 recovery 这个状态。

更新 DaemonSet

有两种更新策略：一个是 RollingUpdate，另一个是 OnDelete。

RollingUpdate ：一个一个的更新。先更新第一个 pod，然后老的 pod 被移除，通过健康检查之后再去见第二个 pod，这样对于业务上来说会比较平滑地升级，不会中断；

OnDelete ：就是模板更新之后，pod 不会有任何变化，需要我们手动控制。我们去删除某一个节点对应的 pod，它就会重建，不删除的话它就不会重建，这样的话对于一些我们需要手动控制的特殊需求也会有特别好的作用。

DaemonSet 管理模式

DaemonSet 还是一个 controller，它最后真正的业务单元也是 Pod，DaemonSet 其实和 Job controller 特别相似，它也是通过 controller 去 watch API Server 的状态，然后及时地添加 pod。唯一不同的是，它会监控节点的状态，节点新加入或者消失的时候会在节点上创建对应的 pod，然后同时根据你配置的一些 affinity 或者 label 去选择对应的节点。