Kubernetes Replication Controller及其相关知识点学习

Kubernetes Replication Controller (RC)

一、概念

Replication Controller (RC) 是 Kubernetes 中早期用于管理 Pod 副本数量和生命周期的控制器对象。尽管在后续版本中已经被 ReplicaSet 所替代并逐渐淡出主流使用，理解 Replication Controller 的概念及其功能对于理解 Kubernetes 的基础架构和演进过程仍然具有重要意义。ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的

二、功能

Replication Controller 主要负责以下核心功能：

2.1、副本数量管理

• 用户通过定义 RC 对象时指定一个期望的副本数（replicas 字段），RC 会确保集群中始终存在指定数量的与之匹配的 Pod 副本。
• 如果实际运行的 Pod 数量少于期望值，RC 会创建新的 Pod；反之，如果实际数量多于期望值，RC 会删除额外的 Pod，以保持副本数的稳定。

2.2、 Pod 管理与自我修复

• RC 使用标签选择器（label selector）来识别和管理与其关联的 Pod。
• 当一个匹配标签选择器的 Pod 非正常终止（例如节点故障、Pod 异常等）时，RC 能够自动重新创建一个新的 Pod 来替换它，确保服务的高可用性。

2.3、 滚动更新

• RC 支持滚动更新，即逐步替换现有 Pod 副本为新版本的 Pod，而不会导致服务中断。
• 用户可以通过更新 RC 的 Pod 模板（定义容器镜像、环境变量等）并调整 replicas 字段来触发滚动更新。RC 会按照用户设定的策略（如更新批次大小、暂停间隔等）逐步替换旧 Pod，同时监控新 Pod 的健康状况，确保整个过程中服务的连续性和稳定性。

2.4、 结合HPA实现弹性伸缩

Horizontal Pod Autoscaler 通过监控指定Pod的CPU或内存使用率（或其他支持的自定义度量标准），根据用户设定的阈值和扩缩规则，自动调整与之关联的Replication Controller或Deployment（以及对应的ReplicaSet）的目标副本数。这意味着，虽然 Replication Controller 本身不直接支持弹性伸缩，但它可以与 HPA 配合使用，使得应用可以根据实际负载情况自动扩大或缩小规模。

2.5、手动伸缩

修改Pod的副本数目

$kubectl scale replicationController my-nginx --replicas=3

kubectl scale如果设置--current-replicas参数，就会先检查当前Pod的副本数是否匹配，不匹配的话就会报错：

$kubectl scale replicationController my-nginx --current-replicas=2 --replicas=3

另外，可以将Pod的副本数目设置为0，即删除Replication Controller关联的所有Pod：

$kubectl scale replicationController my-nginx --replicas=0

三、实现过程

Replication Controller 的实现基于 Kubernetes 控制循环（control loop）的设计原则：

3.1、 监听事件：

• RC 作为 Kubernetes 控制器的一部分，由 kube-controller-manager 组件托管并运行。
• 它持续监听集群中的资源变化，包括 RC 自身的配置更新、Pod 的创建、删除、状态变更等事件。

3.2、 计算差异：

• 当接收到事件通知或定期同步检查时，RC 根据其定义的期望副本数和实际匹配标签选择器的 Pod 数量进行比较。
• 如果存在差异，RC 会计算需要创建或删除的 Pod 数量。

3.3、 执行操作：

• 根据计算结果，RC 会调用 Kubernetes API 服务器接口来执行相应操作：
  • 创建新 Pod：RC 依据其定义的 Pod 模板（.spec.template 字段）创建新的 Pod，并为其自动添加与 RC 相同的标签，以便后续管理。
  • 删除多余 Pod：RC 发送请求删除超出期望数量的 Pod，通常遵循先删除未就绪或已标记为删除的 Pod 的策略。

3.4、 健康检查与回滚：

• 在滚动更新过程中，RC 依赖于 Pod 的 readiness probe 和 liveness probe 来判断新创建的 Pod 是否达到运行准备状态或保持健康。
• 如果新 Pod 验证失败或更新过程中出现问题，RC 可能会暂停更新进程，允许用户介入排查问题或自动回滚到先前的稳定版本。

四、拓展知识

4.1、 控制器对象有哪些？

Kubernetes 中的控制器对象是一系列管理特定类型资源的组件，它们遵循控制循环模式来确保集群中的实际状态与用户定义的期望状态保持一致。以下是 Kubernetes 中常见的控制器对象：

1. Deployment:
   管理应用程序的副本集，确保指定数量的 Pod 副本始终处于运行状态。它支持滚动更新、回滚等操作，使得应用升级更加平滑且具有容错性。

kubectl get Deployment -A

2. StatefulSet:
   用于管理有状态应用的部署，如数据库服务。它保证每个 Pod 拥有稳定的、唯一的网络标识（如固定名称和持久化存储卷），并且按照特定顺序进行创建、更新和删除。

kubectl get StatefulSet -A

kubectl get sts -A

3. DaemonSet:
   确保在每个（或特定）节点上运行一个 Pod 副本。常用于部署节点级别的守护进程，如日志收集器、监控代理,kube-proxy等。

kubectl get DaemonSet -A

4. ReplicaSet:
   是 Deployment 的底层实现，直接管理 Pod 副本的数量。尽管一般不直接使用 ReplicaSet，但它作为 Deployment 的目标对象，确保指定数量的同质 Pod 实例可用。

kubectl get ReplicaSet -A

kubectl get rs -A

5. Job:
   用于执行一次性任务，确保指定的 Pods 完成其工作后成功终止。适用于批处理作业、定时任务等场景。

kubectl get Job -A

6. CronJob:
   定时调度 Job 执行，相当于 Kubernetes 中的定时任务控制器。它可以按预设的时间表重复运行 Jobs。

kubectl get CronJob -A

7. ReplicationController:
   （已逐渐被 ReplicaSet 取代，但仍可使用）与 ReplicaSet 类似，管理 Pod 副本数量，确保指定数量的相同 Pod 始终处于运行状态。

kubectl get ReplicationController -A

kubectl get rc -A

8. Horizontal Pod Autoscaler (HPA):
   根据指定的指标（如 CPU 使用率、自定义度量等）自动调整 Pod 副本的数量，实现水平扩展或收缩。

kubectl get hpa -A

9. Vertical Pod Autoscaler (VPA):
   自动调整单个 Pod 的资源请求（CPU 和内存），以优化资源利用率和避免资源不足或过度分配。

kubectl get vpa -A

10. Service Account Controller:
    管理 Service Accounts 及其关联的 Secret（用于身份验证），内置于 kube-controller-manager 组件中的控制循环（control loop）,确保每个 Namespace 中都有默认的 Service Account。

kubectl get serviceaccounts  -A

11. Endpoint Controller:
    更新 Service 的 Endpoint（即背后 Pod 的 IP 地址列表），确保 Service 与其实现 Pod 之间的映射始终准确。

kubectl get endpoints -A

12. Namespace Controller:
    管理 Namespace 的生命周期，包括创建、删除以及清理与 Namespace 关联的资源。

kubectl get namespace -A

13. Volume Controller:
    负责 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）的绑定、释放以及动态 Provisioning。

kubectl get pv

kubectl get pvc

此外，Kubernetes 还包含其他特定功能或插件相关的控制器，如 Ingress Controllers（如 Nginx Ingress Controller、Traefik 等）、CSI（Container Storage Interface）Controllers 用于对接第三方存储系统、以及各类 Operator（如 Prometheus Operator、Knative Serving Controller 等）实现特定领域的应用自动化管理。

这些控制器共同构成了 Kubernetes 集群的控制平面，通过不断地监测和调整，确保集群的整体状态符合用户的配置意图。

4.2、什么是控制循环模式

Kubernetes（简称K8s）的控制循环模式，也称为调谐循环或同步循环，是一种核心设计原则，用于确保集群中资源的实际状态始终与用户定义的期望状态保持一致。这种模式体现了Kubernetes作为自动化平台的核心能力，即持续监测、调整并维护系统的状态，确保其符合用户的意图。以下是关于Kubernetes控制循环模式的详细解释：

4.2.1、 控制循环模式基本原理

• 目标一致性：

  • 在Kubernetes中，用户通过声明式API（如YAML文件）来定义其期望的系统状态，包括部署的应用程序、服务、存储卷等各类资源。
  • 控制循环的目标是确保集群中的每个资源实例（如Pod、Deployment、Service等）的实际运行状态始终与这些声明式的期望状态相匹配。

• 监控与比较：

  • 控制器组件（如ReplicationController、Deployment Controller、StatefulSet Controller等）通过监听Kubernetes API Server的事件流或定期同步API Server的数据，获取资源的当前实际状态。
  • 控制器将实际状态与期望状态进行比较，检测两者之间是否存在差异。

• 调谐（Reconciliation）：

  • 当控制器发现实际状态与期望状态不一致时，触发调谐过程（Reconciliation）。这个过程通常涉及以下步骤：
    • 识别差异：确定具体是哪些方面（如副本数量、镜像版本、配置参数等）与期望不符。
    • 计算修正动作：根据差异情况，决定需要采取何种操作来缩小或消除差异。例如，如果是Pod数量不足，可能需要创建新的Pod；如果是Pod使用了过时的镜像，可能需要发起Pod的滚动更新。
    • 执行操作：通过调用Kubernetes API来执行上述修正动作，如创建、删除、更新资源对象。

• 闭环反馈：

  • 调谐操作完成后，控制器会继续监控资源的状态变化，直至实际状态与期望状态完全一致。
  • 如果由于某些原因（如节点故障、网络问题、配置错误等）导致调谐未能成功或新的不一致出现，控制器会再次进入调谐流程，持续尝试直到达到预期状态。

4.2.2、 控制循环的关键特性

• 事件驱动：除了定期同步，控制器也响应API Server上的实时事件（如资源创建、更新、删除事件），即时触发调谐流程，确保快速响应外部变化。

• 幂等性：控制器设计为幂等操作，这意味着无论调谐循环执行多少次，只要给定相同的期望状态，最终结果应是一致的。这有助于处理并发操作、网络重试等情况，避免重复或冲突的操作影响系统稳定性。

• 水平扩展：为了应对大规模集群和高负载场景，Kubernetes控制器可以水平扩展，即运行多个相同控制器实例，它们共享工作负载并通过锁机制或其他协调机制避免冲突。

• 自恢复能力：控制循环机制赋予Kubernetes强大的自恢复能力。即使在面临节点故障、应用程序崩溃、配置更改等异常情况时，控制器也能自动检测到问题并启动相应的恢复操作，力求使集群回到期望状态。

综上所述，Kubernetes的控制循环模式是一种持续监测、比较、调整资源状态的过程，旨在确保任何时刻集群的实际状态都与用户定义的期望状态相符。这种模式是Kubernetes实现自动化运维、故障恢复、应用程序弹性的重要基石。

4.3、有状态的应用？

有状态应用（Stateful Application）是指那些在运行过程中依赖于其内部维护的状态，并且该状态必须在应用重启、迁移或扩展时得到保留和正确处理的软件系统。这类应用通常需要对数据的持久化存储、稳定的网络标识以及有序的管理和操作，以确保数据一致性、服务的连续性和高可用性。

以下是对有状态应用特点的详细解释：

• 持久化存储需求：
  有状态应用通常会生成、修改或依赖于持久化的数据，这些数据不能随着应用实例的销毁而丢失，必须持久化存储在可靠的介质上。例如，数据库服务（如 MySQL、PostgreSQL、MongoDB 等）会保存用户的数据记录，这些数据必须在服务器重启、故障转移或集群扩展时保持不变，并能被应用程序正确访问。

• 稳定的网络标识：
  有状态应用需要一个稳定的、可预测的网络身份来保证客户端或其他服务能够持续地、唯一地与其交互。这包括固定的网络域名或IP地址，以及可能的固定端口。例如，在一个多节点数据库集群中，主节点和从节点可能需要通过固定的主机名（如 mysql-0, mysql-1）进行通信，以便于主从同步或客户端连接。此外，某些应用可能需要基于实例名称来定位和协调彼此的状态，比如分布式文件系统中的节点。

• 有序的生命周期管理：
  有状态应用的创建、更新和删除通常需要遵循特定的顺序，以避免数据丢失、不一致或服务中断。例如，在升级数据库集群时，可能需要先更新从节点，再更新主节点，以最小化服务中断时间并确保数据一致性。在缩容时，可能需要先删除从节点，再删除主节点，以防止数据丢失或服务不可用。

• 实例间的关联性：
  有状态应用的多个实例之间可能存在紧密的关联和依赖关系。例如，主从复制架构的数据库中，主节点负责写入操作并将变更同步到从节点；从节点则负责读取操作和备份。如果这些实例随意创建或销毁，可能会破坏复制链路，影响数据的一致性和系统的可用性。

举例：

• 数据库服务：如前所述，MySQL、PostgreSQL、MongoDB 等数据库服务都是典型的有状态应用。它们不仅需要持久化存储用户数据，还需要维持固定的网络连接点供客户端连接，且在集群环境下，节点间存在明确的角色分工（如主从关系）和数据同步机制，这些都需要有序的生命周期管理和稳定的网络标识。

• 消息队列系统：如 Apache Kafka、RabbitMQ 等，它们维护着消息的生产、消费状态以及主题分区的元数据。消费者需要能够持续订阅特定的主题，且在重启后能够从上次消费的位置继续处理消息。此外，集群中的各个节点（broker）也需要有序地加入和离开，以确保数据分布和负载均衡的正确性。

• 分布式存储系统：如 Ceph、GlusterFS 等，它们由多个节点组成，共同提供统一的存储服务。节点间需要维护数据块的分布信息、副本状态等复杂状态，并通过稳定的网络标识与其他节点及客户端通信。节点的增减或故障转移必须有序进行，以避免数据丢失或服务中断。

在 Kubernetes 中，StatefulSet 资源正是为了满足上述有状态应用的需求而设计的。它提供了诸如稳定的网络标识（通过stable network identity和Headless Service）、持久化存储卷的自动挂载、有序的Pod创建/删除/更新等特性，确保有状态应用能够在容器化环境中得到妥善管理和运维。

4.4、kube-controller-manager

Garbage Collector:
Garbage Collector（垃圾收集器）并不是以独立资源对象的形式存在，而是作为 Kubernetes 控制面组件 kube-controller-manager 内的一个核心功能模块运行。它负责自动清理不再需要的资源对象，如当某个对象被删除且没有其他对象依赖它时，Garbage Collector 会确保所有相关的孤儿资源也被正确清理掉。确保资源的有效回收和集群的整洁。

Service Account Controller

Node Controller:
监控节点状态，处理节点加入、离开集群的事件，以及节点健康检查失败、节点未及时上报心跳等情况。

参考文档

1、https://www.cnblogs.com/web424/p/8023948.html

2、https://blog.csdn.net/m0_54232496/article/details/130914646