5-1. RS&Deployment

该文档内容来源于尚硅谷K8S教学视频课件尚硅谷

仅用于知识整理，便于后续巩固复习，如有侵权，请联系本人删除

RS

RS模板示例

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
# 这里的template字段下的内容，可以发现相当于是pod的相关配置内容
# 实际上是在rs模板中嵌套了pod，其他资源模板配置类似
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

一个rs如何知道哪些pod是属于自己所管理的呢？看上述rs模板中，有一个selector字段，其中有一个matchLabels字段，设置为tier: frontend（key:value）,下面的template（相当于pod的模板内容）中有metadata字段，其中也有labels，因此rs在管理自己的pod时，就会根据这两个labels进行匹配管理，只要labels是tier: frontend 就是这个rs所需要管理的pod。如果强行修改其中某个pod的labels，rs就会发现不满足期望副本数量，会立刻再重新创新一个新的原label name的pod。

RS对副本的管理是依赖标签的

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括；

• 定义 Deployment 来创建 Pod 和 ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续 Deployment

  Deployment并不会直接创建Pod，而是通过创建RS，再由RS创建Pod，间接地实现创建pod的任务。如图，假设Deployment现在创建一个RS-01，然后RS-01又创建了三个pod，这三个pod暂且将其定义为v1版本。

部署/使用

deployment模板(观察下述模板信息，实际上与rs模板基本类似)

#部署一个简单的 Nginx 应用
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

扩容

#kubectl scale deployment deploymentName --replicas numbers
kubectl scale deployment nginx-deployment --replicas 10

deployment在扩容时并不会创建新的rs；如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展。

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
# 当cpu利用率大于等于80时进行扩容，最大副本数量为15，当cpu利用率不足80时，进行缩容，最小副本数量为10

更新

比如说更新上述deployment中的nginx容器的版本。deployment中容器的镜像的更新会触发创建新的rs

#kubectl set image deployment/deploymentName containerName=container's image address
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

回滚

  那么Deployment是如何实现滚动更新呢？倘若现在要将这些pod全部更新到v2版本，Deployment会这样做，先创建一个RS-02，然后在RS-02下创建一个v2版的pod，同时再删掉RS-01下的一个v1版的pod，依次类推，直到所有的pod全部更新为v2版，此时RS-01被停用，注意并没有将其删除，这位后续进行回滚作了铺垫。同理，如果想将v2版回滚到v1版，则执行上述的逆过程，先删除RS-02下的一个v2，同时RS-01下创建一个v1，直到所有的pod都回滚到v1版本。

kubectl rollout undo deployment/nginx-deployment

• Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少 一个是up状态（最多一个不可用） 在k8s中实际上设置了一个25%的阈值，也就是说，在更新时先创建25%的new pod数量，然后再删除old RS中25%的pod。
• Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数 量多一个的 Pod 是 up 的（最多1个 surge ）

Rollover（多个rollout并行）

假设现在要创建一个包含有5个 niginx:1.7.9 replica的 Deployment，当创建到第3个副本的时候，突然就已经开始要更新niginx版本到 nginx:1.9.1 ，这个时候Deployment 会立即 杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的 Pod 都创建完成后才开始改变航道。

回退常用的命令操作

kubectl set image deployment/nginx-deployment nginx=nginx:1.91
# 查看rollout状态
kubectl rollout status deployments nginx-deployment
kubectl get pods
# 查看rollout历史信息
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用 --revision参数指定
某个历史版本
kubectl rollout pause deployment/nginx-deployment ## 暂停 deployment 的更新

清理 Policy

可通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会 保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了