RC、RS、Deployment

RC、RS、 Deployment概述

RC（Replication Controller）

• RC独立于所控制的Pod，并通过Label标签这个松耦合关联关系控制目标Pod实例的创建和销毁。

RS

• RS为RC的升级版，支持集合式的selector
• RC只能匹配单个标签，例如env=devel,RS可以同时匹配多个，也可以匹配没有某的标签或含有某个标签，不管值是什么

Deployment

• Deployment通过RS去创建和管理对应的pod典型的应用场景包括：
  • 定义Deployment来创建Pod和ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续Deployment

管理deployment

使用yaml文件创建deployment（推荐）

vim deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  strategy:
    type: RollingUpdate  # 更新类型为滚动更新
    rollingUpdate:       # 先减一个pod，再加一个pod
      maxSurge: 0
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

# 使用 --record 参数可以在部署历史记录的CHANGECAUSE列看到部署该版本时使用的命令
kubectl create -f deployment.yaml --record

命令行创建deployment

kubectl create deployment my-app --image=my-app:v1 --replicas=3 --port=8080

查看配置文件说明

• 忘记yaml文件格式不要怕，可以通过以下命令查看yaml文件层级

kubectl explain Deployment.spec.strategy

更新deployment中的镜像

# 将Pod中的容器busybox-container的镜像更新为busybox:latest。
kubectl set image deployment/busybox-deployment busybox-container=busybox:latest --record
或者
kubectl edit deployment/busybox-deployment

查看deployment更新过程

• 实时监控指定 Deployment 的滚动更新状态
• 阻塞式命令：会持续输出状态，直到 Deployment 的所有新 Pod 就绪或出现错误

kubectl rollout status deployment/busybox-deployment

# 常用选项
--timeout=5m	设置等待超时时间（默认 0，无限等待）
-w              持续监听状态（类似 watch 模式）

删除depolyment

• 默认情况下删除deployment会一并删除其创建的pod
• --cascade=false参数表示只删除deploymnet，不级联删除deployment管理的pod。Pod 会变成"孤儿"（无控制器管理），需手动清理

kubectl delete deploy my-deploy --cascade=false # 保留创建的pod

deployment的扩容、资源限制

# 扩容
# kubectl scale deployment deployment名称 --replicas 数量
kubectl scale deployment nginx-deployment --replicas 10

# 资源限制
kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

deployment的回滚、暂停

• 通过设置.spec.revisionHistoryLimit项来指定deployment最多可以保留多少revision历史记录
• 默认保留所有的revision
• 如果将.spec.revisionHistoryLimit设置为0，deployment就不能回退了

# 回滚
kubectl rollout history deployment/nginx-deployment  # 查看历史版本
kubectl rollout undo deployment/ngnix-deplyment      # 回滚到上一版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2    # 回滚到指定版本
kubectl rollout status deployments deployment名称     # 查看回滚状态

# 暂停
kubectl rollout pause deployment/nginx-deployment   # 暂停更新（进行任意次修改后恢复更新，触发完整更新操作）
kubectl rollout resume deployment/nginx-deployment  # 恢复更新

Deployment的两种更新策略

• Deployment的两种更新策略：Recreate（重建）和RollingUpdate（滚动更新），默认是RollingUpdate。
  • Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。
  • RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。

maxSurge参数

• maxSurge：用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数的最大数量。（从Kubernetes 1.6开始，maxSurge的默认值从1改为25%。）
  • 例如，当maxSurge的值被设置为30%时，新的ReplicaSet可以在滚动更新开始时立即进行副本数扩容，只需要保证新旧ReplicaSet的Pod副本数之和不超过期望副本数的130%即可。一旦旧的Pod被杀掉，新的ReplicaSet就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧ReplicaSet的Pod副本总数之和不超过所需副本数的130%。
• maxSurge的值可以是一个整整（例如5）或Pod期望副本数的百分比（例如10%）。如果是百分比，Kubernetes会先计算出一个数值，并向上取整。

maxUnavailable参数

• maxUnavailable：用于指定Deployment在更新过程中不可用状态的Pod数量的上限（从Kubernetes 1.6开始，maxUnavailable的默认值从1改为25%）。
• 例如，当maxUnavailable被设置为30%时，旧的ReplicaSet可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的Pod创建并准备好，旧的ReplicaSet会进一步缩容，新的ReplicaSet又继续扩容，整个过程中系统在任意时刻都可以确保可用状态的Pod总数至少占Pod期望副本总数的70%。
  • maxUnavailable的值可以是一个整整（例如5）或Pod期望副本数的百分比（例如10%）。如果是百分比，Kubernetes会先计算出一个数值，并向下取整。

更新Deployment的标签选择器（Label Selector）

• 通常来说，不鼓励更新Deployment的标签选择器，因为这样会导致Deployment选择的Pod列表发生变化，也可能与其他控制器产生冲突。如果一定要更新标签选择器，那么请务必谨慎，确保不会出现其他问题。
• 添加选择器标签时，必须同步修改Deployment配置的Pod的标签，为Pod添加新的标签，否则Deployment的更新会报验证错误而失败。
• 添加标签选择器是无法向后兼容的，这意味着新的标签选择器不会匹配和使用旧选择器创建的ReplicaSets和Pod，因此添加选择器将会导致所有旧版本的ReplicaSets和由旧ReplicaSets创建的Pod处于孤立状态（不会被系统自动删除，也不受新的ReplicaSet控制）。
• 更新标签选择器，即更改选择器中标签的键或者值，也会产生与添加选择器标签类似的效果。
• 删除标签选择器，即从Deployment的标签选择器中删除一个或者多个标签，该Deployment的ReplicaSet和Pod不会受到任何影响。但需要注意的是，被删除的标签仍会存在于现有的Pod和ReplicaSets上。

修改deployment或其他资源的不同方式

kubectl edit

• 直接打开默认编辑器（如 vim）修改 YAML
• 修改保存后立即生效
• 适用于快速调试和小改动

kubectl patch

• 只修改指定字段
• 支持JSON Patch和Strategic Merge Patch
• 适合自动化脚本

kubectl patch deployment/<name> --type='json' -p='[{"op": "replace", "path": "/spec/replicas", "value":5}]'

kubectl apply

• 声明式配置管理
• 保留之前的修改历史
• 适合版本控制和CI/CD流程

kubectl replace

• 完全替换现有资源配置
• 不会合并修改
• 需要提供完整资源配置

K8S Deployment 故障排除图解指南

https://www.imooc.com/article/297421
![c4d901e51431455193582438cd8ad819.png]