kubernetes | Controller控制器 & Deployment

一、Replication Controller

1.1、简介

Replication Controller (RC) 是 Kubernetes 系统中核心概念之一，当我们定义了一个 RC 并提交到 Kubernetes 集群中以后，Master 节点上的 Controller Manager 组件就得到通知， 定期检查系统中存活的 Pod，并确保目标 Pod 实例的数量刚好等于 RC 的预期值，如果有过多或过少的 Pod 运行，系统就会停掉或创建一些 Pod。此外我们也可以通过修改 RC 的副本数量，来实现 Pod 的动态缩放功能。

kubectl scale rc nginx --replicas=5

由于 Replication Controller 与 Kubernetes 代码中的模块 Replication Controller 同名， 所以在 Kubernetes v1.2 时， 它就升级成了另外一个新的概念 Replica Sets，官方解释为 下一代的 RC，它与 RC 区别是：Replica Sets 支持基于集合的 Label selector。RC 只支持基于等式的 Label Selector。

我们很少单独使用 Replica Set，它主要被 Deployment 这个更高层面的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。最好不要越过 RC 直接创建 Pod， 因为 Replication Controller 会通过 RC 管理 Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样就能提高应用的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只有一个 Pod 副本，也强烈建议使用 RC 来定义 Pod。

1.2、RC 常用操作

1.2.1、配置文件

apiVersion: v1
kind: ReplicationController
metadata:
  name: tomcat-rc               # 建议名称与用途保持一致
spec:
  replicas: 3
  selector:                     # 重点修正：显式定义选择器
    app: tomcat
    component: web
  template:                     # Pod 模板
    metadata:
      labels:                   # 重点修正：这里的标签必须包含上面 selector 定义的所有标签
        app: tomcat
        component: web
    spec:
      containers:
      - name: tomcat
        image: tomcat:8.5-jdk8  # 指定具体版本比只写 8.0 更稳健
        ports:
        - containerPort: 8080

参数解释：

• Kind ReplicationController 中的值 ReplicationController 表示 kubectl 将使用 yaml 文件来创建 Replication Controller (RC)。
• name tomcat-rc 将用于识别创建 Replication Controller (RC) 的名称。
• name tomcat 表示容器的名称定义为 tomcat，pod 中出现的容器是 tomcat。
• replicas 3 表示需要在 pod 生命周期的任何时间点维护一个 pod 的三个副本。
• containerPort 8080 是确保集群中的所有节点都暴露在同一个端口 8080 上。

1.2.2、缩容 Pod

kubectl scale replicationcontroller tomcat-rc --replicas=1
replicationcontroller "tomcat-rc" scaled
kubectl get pod -l name
kubectl get rc tomcat-rc

1.2.3、扩容 Pod

kubectl scale replicationcontroller tomcat-rc --replicas=4
replicationcontroller "tomcat-rc" scaled
kubectl get pod -l name
kubectl get rc tomcat-rc

1.2.4、判断及修改副本数量

判断当前副本数是否为 3 个，如果是，则更改为 1 个副本：

kubectl scale rc tomcat-rc --current-replicas=3 --replicas=1

二、Replica Set

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。 Kubernetes 官方强烈建议避免直接使用 ReplicaSet，而应该通过 Deployment 来创建 RS 和 Pod。由于 ReplicaSet 是 ReplicationController 的代替物，因此用法基本相同，唯一的区别在于 ReplicaSet 支持集合式的 selector。

三、Deployment

Deployment 是 Kubenetes v1.2 引入的新概念，引入的目的是为了更好的解决 Pod 的编排问题，Deployment 内部使用了 ReplicaSet 来实现。Deployment 的定义与 ReplicaSet 的定义很类似，除了 API 声明与 Kind 类型有所区别：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - key: tier
        operator: In
        values: 
          - frontend
  template:                     # selector 要求：tier: frontend。如果不存在，则根据 template 部分创建。
    metadata:
      labels:
        app: app-demo           # 自定义的标签
        tier: frontend
    spec:
      containers:
      - name: tomcat-demo
        image: tomcat
        ports:
        - containerPort: 8080

可以看到，该定义方式与 ReplicaSet 区别除了 apiVersion 和 kind 两个参数不同之外，其他都是一样的。

四、Horizontal Pod Autoscaler

Horizontal Pod Autoscal（Pod 横向扩容 简称 HPA） 与 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标 Pod 的副本数，这是 HPA 的实现原理。

Kubernetes 对 Pod 扩容与缩容提供了手动和自动两种模式，手动模式 通过 kubectl scale 命令对一个 Deployment/RC 进行 Pod 副本数量的设置。自动模式 则需要用户根据某个性能指标或者自定义业务指标，并指定 Pod 副本数量的范围，系统将自动在这个范围内根据性 能指标的变化进行调整。

（1）手动扩容和缩容

kubectl scale deployment frontend --replicas 1  

（2）自动扩容和缩容
HPA 控制器基本 Master 的 kube-controller-manager 服务启动参数 --horizontal-podautoscaler-sync-period 定义的时长 (默认值为 30s)，周期性地监测 Pod 的 CPU 使用率，并在满足条件时对 RC 或 Deployment 中的 Pod 副本数量进行调整，以符合用户定义的平均 Pod CPU 使用率。

apiVersion: apps/v1                # 修正：从 extensions/v1beta1 升级
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:                        # 修正：apps/v1 必须显式声明 selector
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:                # HPA 正常工作必须设置资源限制
            cpu: 50m
          limits:                  # 建议也加上 limit
            cpu: 100m
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
---
apiVersion: autoscaling/v1         # 如果你的集群较新，也可以使用 autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1            # 修正：必须与 Deployment 的 apiVersion 完全一致
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50 # 当 CPU 使用率超过 requests 的 50% 时触发扩容

HPA 的计算遵循以下公式（向上取整）：

期望副本数 = 当前副本数 x (当前实际指标值/目标期望指标值)

（3）扩容的特殊规则 虽然公式是这样，但为了保证集群的稳定，K8s 还有几道“防火墙”：

• 最大/最小限制：副本数永远不会超过你在 YAML 中定义的 maxReplicas（你设的是 10），也不会低于 minReplicas（你设的是 1）。
• 扩容容忍度 (Tolerance)：如果 (当前值 / 目标值) 的结果非常接近 1（默认在 0.1 范围内，即 0.9 ~ 1.1 之间），HPA 会认为波动很小，不进行任何操作。这可以防止副本数因微小波动频繁抖动。
• 扩容速率限制：为了防止副本数瞬间暴涨导致集群雪崩，HPA 控制器在单次扩容中会有一定的增量比例限制（通常是当前副本数的数倍，具体取决于集群配置）。

扩容通常很迅速（为了救命），但缩容会有延迟（默认等待 5 分钟）。这是为了防止“扩了删，删了又扩”的“颠簸”现象。
可以运行这个命令实时观察 HPA 的决策过程：
kubectl get hpa nginx-hpa -w

关于 service: