1-RC、RS、Deployment

1.RC、RS、Deployment

k8s控制器

K8S Deployment 故障排除图解指南

https://www.imooc.com/article/297421

RC、RS、 Deployment概述

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

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

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

* 官方的建议：我们不应该直接使用底层的ReplicaSet来控制Pod副本，而应该使用管理ReplicaSet的Deployment对象来控制副本。

创建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的升级、更新

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

* 使用kubectl rollout status命令查看Deployment的更新过程
kubectl rollout status deployment/busybox-deployment

* 查看Deployment的更新的详细过程
kubectl describe deployment/busybox-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）来控制滚动更新的过程。

* 查看配置文件说明
kubectl explain Deployment.spec.strategy

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

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

* 注意：
    * 如果Deployment的上一次更新正在进行，此时用户再次发起Deployment的更新操作，那么Deployment会为每一次更新都创建一个ReplicaSet，而每次在新的ReplicaSet创建成功后，会逐个增加Pod副本数，同时将之前正在扩容的ReplicaSet停止扩容（更新），并将其加入旧版本ReplicaSet列表中，然后开始缩容至0的操作。
    * 例如，假设我们创建一个Deployment，这个Deployment开始创建5个busybox:1.7.9的Pod副本，在这个创建Pod动作尚未完成时，我们又将Deployment进行更新，在副本数不变的情况下将Pod模板中的镜像修改为busybox:1.9.1，又假设此时Deployment已经创建了3个busybox:1.7.9的Pod副本，则Deployment会立即杀掉已创建的3个busybox:1.7.9 Pod，并开始创建busybox:1.9.1 Pod。Deployment不会在等待busybox:1.7.9的Pod创建到5个之后再进行更新操作。

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

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

删除depolyment

删除deploy会一并删除其创建的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的回滚、暂停

回滚
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                 恢复更新

回滚策略
1. 添加参数才能够按照版本回滚
2. 创建、更新资源时，添加--record选项，会在历史版本中记录修改

Rollover（多个rollout并行）
假如要创建5个pod，当创建出3个时，启动了pod的更新，那么deployment会立即杀死3个旧版本，并开始创建新版本

历史版本清理策略
1.通过设置.spec.revisionHistoryLimit项来指定deployment最多可以保留多少revision历史记录
2.默认保留所有的revision
3.如果将该项设置为0，deployment就不能回退了