【Kubernetes】Label、Replication Controller、Deployment

# Label
一个 Label 是一个 key=value 的键值对，key value 用户自己制定

Label 可以背附加到各种资源对象上，如 Node、Pod、Service、RC 等。

资源对象和 Label 是多对多的关系

通过给指定的资源对象捆绑一个或多个的 Label 实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

## 常见的 Label：
- 版本标签：`"release": "stable"`、`"release": "canary"`
- 环境标签：`"environment":"dev"`、`"environment":"qa"`、`"environment":"production"`
- 架构标签：`"tier":"frontend"`、`"tier":"backend"`、`"tier":"middleware"`
- 分区标签：`"partition":"customerA"`、`"partition":"customerB"`
- 质量管控标签：`"track":"daily"`、`"track":"weekly"`

给某个资源对象定义一个 Label，就相当于给他打了一个标签，随后可以通过 Label Selector （标签选择器）查询和筛选拥有某些 Label‘ 的资源对象。
Kubernetes 通过这种方式实现了类似 SQL 的简单又通用的对象查询机制

Label Selector 可以被类比为 SQL 语句中的 where 查询条件，eg.
`name=redis-slave` 这个Label Selector 作用于 Pod 时，可以被类比为 `select * from pod where pod's name ='redis-slave'` 这样的语句。

## 两种 Label Selector 表达式：
- 基于等式的（Equality-based）：采用等式类表达式匹配标签
	- `name = redis-salve`：匹配所有具有标签 name=redis-slave 的资源对象
	- `env != production`：匹配所有不具有标签 envproduvtion 的资源对象
- 基于集合的（Set-based）：使用集合操作类表达式匹配标签
	- `name in (redis-master, redis-slave)`：匹配所有具有标签 name=redis-master 或者 name=redis-slave 的资源对象
	- `name not in (php-frontend)`：匹配所有不具有标签 name=php-frontend 的资源对象。

可以通过多个 Label Selector 表达式的组合实现复杂的条件选择，多个表达式之间用 “, ” 进行分隔。几个条件之间是 “AND” 的关系，即同时满足多个条件
`name=redis-salve, env!=production`

## Label 的位置和用法
所有 Kubernetes 资源对象都可以在 metadata 部分定义标签
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: nginx
    environment: production
    tier: frontend
```

在控制器（如 Deployment、ReplicaSet、StatefulSet 等）中，标签会出现在以下两个位置：
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx    # Deployment 自身的标签
spec:
  selector:
    matchLabels:
      app: nginx  # 选择器，用于匹配 Pod
  template:
    metadata:
      labels:
        app: nginx  # Pod 模板中的标签
        tier: frontend
```

### Pod
Pod 的 Label 被定义在其 `metadata` 中：
```yaml
apiVersion: v1
kind: Pod
metadata:
  labels:    # Pod 的标签
    app: myapp
```

管理对象 RC 和 Service 通过 Selector 字段设置需要关联 Pod 的 Label：
### Replication Controller
```yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-rc
  labels:
    app: nginx    # 1. RC 自身的标签（可选）
spec:
  replicas: 3
  selector:        # 2. Pod 选择器（必需）
    app: nginx     # RC 只支持等值选择器
  template:
    metadata:
      labels:      # 3. Pod 模板中的标签（必需）
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
```
### Service
```yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx    # Service 自身的标签
spec:
  selector:
    app: nginx    # 用于选择 Pod 的标签选择器
```
其他管理对象如 Deployment、ReplicaSet、DaemonSet 和 Job 可以在 Selector 中使用基于集合的筛选条件定义
### ReplicaSet
```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:    # ReplicaSet 的标签
    app: myapp
spec:
  selector:
    matchLabels:    # Pod 选择器
      app: myapp
  template:
    metadata:
      labels:       # Pod 模板的标签
        app: myapp
```

### Deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:    # Deployment 的标签
    app: myapp
spec:
  selector:
    matchLabels:    # Pod 选择器
      app: myapp
  template:
    metadata:
      labels:       # Pod 模板的标签
        app: myapp
```

### StatefulSet
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:    # StatefulSet 的标签
    app: myapp
spec:
  selector:
    matchLabels:    # Pod 选择器
      app: myapp
  template:
    metadata:
      labels:       # Pod 模板的标签
        app: myapp
```

### DaemonSet
```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:    # DaemonSet 的标签
    app: myapp
spec:
  selector:
    matchLabels:    # Pod 选择器
      app: myapp
  template:
    metadata:
      labels:       # Pod 模板的标签
        app: myapp
```

## 实例解析
```yaml
selector: 
	matchLabels: 
		app: myweb 
	matchExpressions: 
	- {key: tier, operator: In, values: [frontend]} 
	- {key: environment, operator: NotIn, values: [dev]}
```

- matchLabels 用于定义一组 Label，与直接写在 Selector 中的作用相同：
- matchExpressions 用于定义一组基于集合的筛选条件，可用运算符：`In`、`NotIn`、`Exists` 和 `DoesNotExist`
- 如果同时设置了 `matchLabels` 和 `matchExpressions`，则两组条件为 `AND` 关系，即需要同时满足所有条件才能完成 Selector 的筛选

## Label Selector 在 Kubernetes 中的重要使用场景
- `kube-controller` 进程通过在资源对象 RC 上定义的 Label Selector 来筛选要监控的 Pod 副本数量，使 Pod 副本数量始终符合预期设定的全自动控制流程
- `kube-proxy` 进程通过 Service 的 Label Selector 来选择对应的 Pod，自动建立每个 Service 到对应 Pod 的请求转发路由表，从而实现 Service 的智能负载均衡机制
- 通过对某些 Node 定义特定的 Label，并且在 Pod 定义文件中使用 NodeSelector 这种标签调度策略，`kube-secheduler` 进程可以实现 Pod 定向调度的特性

# Replication Controller
Replication Controller（RC）定义了一个期望的场景，即 声明某种 Pod 的副本数量在任意时刻都符合某个预期值，所以 RC 的定义包括一下几个部分：
- Pod 期待的副本数量
- 用于筛选目标 Pod 的 Label Selector
- 当 Pod 的副本数量小于预期数量时，用于创建新 Pod 的 Pod 模板（template）

定义了一个 RC 并将其提交到 Kubernetes 集群中后，Master 上的 Controller Manager 组件会得到通知，定期巡检系统中当前存活的目标 Pod，并确保目标 Pod 实例的数量刚好等于此 RC 的期望值，如果有过多的 Pod 副本在运行，系统就会停掉一些 Pod，否则系统会再自动创建一些 Pod

## 副本概念
不管是 RC 还是后面会提到的 Deployment 都有 “副本” 的概念，可以说 只要是通过 RC 和 Deployment 创建的 Pod 都属于 “副本”（Replica）

因为 RC 和 Deployment 的核心功能就是维护一定数量的相同 Pod 副本：
- 通过控制器管理：RC 和 Deployment 会根据 `spec.replicas` 字段指定的数量维护 Pod
- 基于相同模板：使用 `template` 部分定义的完全相同的配置创建 Pod
- 标签选择：通过标签选择器识别和管理所属的 Pod
- 自愈能力：当 Pod 失败或被删除时，自动创建新的 Pod 以维持副本数量
- 可互相替代：所有这些 Pod 都是功能等同的，可以互相替代

Pod 副本指的是：
- 具有相同标签
- 运行相同应用
- 配置基本一致
- 可以互相替代的 Pod

### RC 如何处理 Pod 数量不匹配
通过 RC 定义 Pod 时，是期望通过相同配置模板定义文件中的 `replicas: x` 在集群中 期望创建 x 个 Pod 副本。
假设 RC 定义 `redis-slave` 这个 Pod 需要保持 `replicas: 2` 系统将可能在集群中的两个 Node 上创建 Pod
假设其中一个 Node 上的 Pod 意外终止（假设是下图中的 Pod 2），则根据 RC 定义的 `replicas: 2` Kubernetes 会自动创建并启动一个新的 Pod，以保证在整个集群中始终有两个 `redis-slave Pod` 运行。
系统此时可能选择 Node1 也可能选择 Node3
![Node Pod Container 关系图-Pod 多副本.drawio](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/po7bp5.webp)

### 修改副本数量
#### 方法一
可以通过修改 RC 的副本数量，实现 Pod 的动态缩放（Scaling），执行以下命令：
```bash
kubectl scale rc <pod-name> --replicas=2
```
此时不需要再执行 `kubectl apply -f mysql-rc.yaml` 命令，当执行 `kubectl scale rc <pod-name> --replicas=2` 看到显示 `scaled` 就意味着副本数量已经成功更新到 Kubernetes 集群中。这个更改直接应用到集群中运行的 ReplicationController 对象上，而不是修改本地 yaml 文件。

执行内容与结果如图：
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/nuj6aq.webp)

需要注意的是，此时本地 YAML 文件中的 `replicas` 值仍然是 1，与集群中的实际状态不同步。如果你之后使用 `kubectl apply -f mysql-rc.yaml` 重新应用这个文件，它会将副本数量重置回 YAML 文件中定义的值（即 1）。

如果想要保持配置文件与集群状态一致，可以：
- 手动更新 YAML 文件中的 `replicas: 1` 为 `replicas: 2`
- 或者使用 `kubectl get rc mysql -0 yaml > mysql-rc-updated.yaml` 导出当前配置。

#### 方法二
或者可以编辑 `mysql-rc.yaml` 文件，保存配置文件后需要执行 `kubectl apply -f mysql-rc.yaml` 命令。

删除 RC 并不会影响通过该 RC 已创建好的 Pod，

### 删除所有 Pod
可以设置 `replicas: 0` 然后更新该 RC。

同时 kubectl 提供了 stop 和 delete 命令来一次性删除 RC 和 RC 控制的全部 Pod。

## 通过 RC 机制实现 滚动升级
应用升级时，通常会使用一个新的容器镜像版本替代旧版本，我们希望系统平滑升级。

比如在当前系统中有 10 个对应的旧版本的 Pod，则最佳的系统升级方式是旧版本的 Pod 每停止一个，就同时创建一个新版本的 Pod，在整个升级过程中此消彼长，而运行中的 Pod 数量始终是 10 个，几分钟以后，当所有的 Pod 都已经是新版本时，系统升级完成。

通过RC机制，Kubernetes 很容易就实现了这种高级实用的特性，被称为 “滚动升级”（Rolling Update）

## Replica Set 副本集
Replication Controller 由于与 Kubernetes 代码中的模块 Replication Controller 同名，同时 “Replication Controller" 无法准确表达他的本意，所以在 Kubernetes 1.2 中升级为另一个新概念 Replica Set，官方解释为  ”下一代的 RC“。

Replica Sets 支持基于集合的 Label selector（Set-based selector），而 RC 只支持基于等式的 Label Selector（equality-based selector）

```yaml
apiVersion: extensions/v1beta1 
kind: ReplicaSet 
metadata: 
	name: frontend 
spec: 
	selector: 
		matchLabels: 
			tier: frontend 
		matchExpressions: 
			- {key: tier, operator: In, values: [frontend]} 
template: ......
```

`kubectl` 命令行工具适用于 RC 的绝大部分命令，同样适用于 Replica Set
此外，当前很少单独使用 Replica Set，他主要是被 Deployment 这个更高层的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。

在使用 Deployment 时，无须关心他是如何创建和维护 Replica Set 的，这一切都是自动发生的。

Replica Set 与 Deployment 这两个重要的资源对象逐步替代了之前 RC 的作用，是Kubernetes 1.3 里 Pod 自动扩容（伸缩）这个告警功能实现的基础，也将继续在 Kubernetes未来的版本中发挥重要的作用。

## RC（Replica Set）的一些特性与作用
- 在大多数情况下，通过定义一个 RC 实现 Pod 的创建及副本数量的**自动控制**
- 在 RC 里包括完整的 Pod 定义模板
- RC 通过 Label Selector 机制实现对 Pod 副本的自动控制
- 通过改变 RC 里的 Pod 副本数量，可以实现 Pod 的扩容或缩容
- 通过改变 RC 里 Pod 模板中的镜像版本，可以实现 Pod 的滚动升级

# Deployment
Deployment 是 Kubernetes 在 1.2 版本中引入的新概念，用于更好地解决 Pod 的编排问题。

Deployment 在内部使用了 Replica Set 来实现目的，无论从 Deployment 的作用与 目的 YAML 定义，还是从它的具体命令行操作来看，都可以把他看做 RC  的一次升级，两者的相似度超过 90%

Deployment 相对于 RC 的一个最大升级是 我们可以随时知道当前 Pod “部署” 的进度。

由于一个 Pod 的创建、调度、绑定节点 及 在目标 Node 上启动对应的容器 这一完整过程需要一定的时间，所以期待系统启动 N 个 Pod 副本的目标状态，实际上是一个 连续变化的 “部署过程” 导致的最终状态。

## Deployment 典型使用场景：
- 创建一个 Deployment 对象来生成对应的 Replica Set 并完成 Pod 副本的创建
- 检查 Deployment 的状态来看部署动作是否完成（Pod 副本数量是否达到预期值）
- 更新 Deployment 已创建新的 Pod（如 `镜像升级`）
- 如果当前 Deployment 不稳定，则`回滚`到一个早先的 Deployment 版本
- 暂停 Deployment 以便 `一次性修改` 多个 `PodTemplateSpec` 的配置项，之后再恢复 Deployment，进行新的发布
- 扩展 Deployment 以应对高负载
- 查看 Deployment 的状态，以此作为发布是否成功的指标
- 清理不再需要的旧版本 ReplicaSets

## Deployment 的定义
```yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
	name: nginx-deployment
```

与 Replica Set 的定义很类似
```yaml
# ReplicaSet 的定义
apiVersion: v1
kind: ReplicaSet
metadata:
	name: nginx-repset
```

## Deployment 实践
### 创建 Deployment 的 yaml 文件
```bash
touch tomcat-deployment.yaml
```
配置文件写入以下内容：
```yaml
apiVersion: apps/v1    # 更新到当前推荐的 API 版本
kind: Deployment
metadata:
  name: frontend
spec: # 定义了资源的期望状态
  replicas: 1 # Pod 副本数量
  selector: # 选择器，用于识别哪些 Pod 是属于这个 Deployment 的
    matchLabels:      # 简化选择器配置
      tier: frontend
  template: # Pod 模板，定义 Pod 的配置
    metadata:
      labels: # Pod 的标签
        app: app-demo
        tier: frontend
    spec: # Pod 的详细规格
      containers: # 容器配置
      - name: tomcat-demo # 容器名称
        image: tomcat # 使用的镜像
        imagePullPolicy: IfNotPresent # 镜像拉取策略
        ports: # 容器端口配置
        - containerPort: 8080 # 容器暴露的端口
```

### 创建 Deployment
```bash
kubectl create -f tomcat-deployment.yaml
```
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/r80wmm.webp)

### 查看 Deployment 的信息
```bash
kubectl get deployments
```
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/r8a2cg.webp)
信息解释：
- `NAME`：Deployment 名称
- `READY`：就绪的副本数 / 期望的副本数
	- `1/1` 表示期望 1 个副本，且已经有 1 个副本就绪
	- 如果显示 `0/3` 就表示期望 3 个副本，但当前没有就绪的副本
- `UP-TO-DATE`：显示已经更新到最新配置的副本数
	- 在滚动更新过程中特别有用
	- 上述信息中的 `1` 表示 1 个副本都是最新版本
- `AVAILABLE`：当前可用的副本数
	- “可用” 意味着 Pod 正在运行且处于就绪状态
	- 这里的 `1` 表示有 1 个副本可以正常服务
- `AGE`：Deployment 创建后经过的时间

获取更详细的信息可以执行以下命令：
```bash
# 查看详细信息
kubectl describe deployment frontend

# 查看 YAML 格式的完整配置
kubectl get deployment frontend -o yaml
```

## 查看对应的 Replica Set 
```bash
kubectl get rs
```

![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/rchvej.webp)

## 查看对应的 Pod
```bash
kubectl get pods
```
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/05/s60xja.webp)

# Deployment - ReplicaSet - Pod 的对应过程
当创建一个 Deployment 时，Kubernetes 会自动创建对应的 ReplicaSet（RS），工作机制是：Deployment → ReplicaSet → Pod
## Deployment 创建
- 创建一个 Deployment 时
- Deployment 控制器会自动创建一个 ReplicaSet

## 命名规则
- RS 命名规则：`{deployment-name}-{hash}`
- 如上述时间实践中的：`frontend-557b6578cd`
- 其中 `557b6578cd` 是根据 Pod 模板内容生成的哈希值

## 版本控制
- 每当你更新 Deployment 的 Pod 模板时
- 会创建新的 ReplicaSet
- 旧的 ReplicaSet 会被保留（默认保留 10 个）
- 这就是为什么 Deployment 能够进行回滚

## 示例
```yaml
Deployment: frontend
└── ReplicaSet: frontend-557b6578cd
    └── Pod: frontend-557b6578cd-xxxxx

Deployment: netchecker-server
└── ReplicaSet: netchecker-server-67c989ccbb
    └── Pod: netchecker-server-67c989ccbb-xxxxx
```

Pod 的管理对象，除了 RC 和 Deployment，还包括 ReplicaSet、DaemonSet、StatefulSet、Job 等，分别用于不同的应用场景中。

# References
- claude 3.5 sonnet
- claude 3.7 sonnet
- Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）