k8s-资源调度-deployment的学习

deployment一般用来部署无状态服务。

1.Label和selector

Label和selector一般是结合起来使用的就像mysql中的字段名和查询语句一样，一般使用selector查询器来查询Label为何值的资源。

一般来说在配置pod时就会配置label信息（具体配置如k8s-pod学习中所示），但是在后续如果要改动label信息就可以使用kubectl进行操作，同样selector也可以使用kubectl进行操作。

1）使用kubectl操作pod的Label。

# 临时创建label ,这里添加标签app=hell0
kubectl label po <资源名称> app=hello 

# 修改已存在的label ,这里将app标签覆盖为hello2
kubectl label po <资源名称> app=hello2 --overwrite

# 查看所有节点的 labels
kubectl get po --show-labels

2）使用kubectl操作selector选择器。

# 匹配单个值，查找 app=hello 的 pod
kubectl get po -A -l app=hello

# 匹配多个值
kubectl get po -A -l 'k8s-app in (metrics-server, kubernetes-dashboard)'
或 

# 查找 version!=1 and app=nginx 的 pod 信息
kubectl get po -l version!=1,app=nginx

# 不等值 + 语句
kubectl get po -A -l version!=1,'app in (busybox, nginx)'

2.deployment学习

在这之前首先要知道以下几个概念。

• ReplicationController(RC)：用来实现Pod副本数量的动态更新，只需要输入副本的数量即可。
• ReplicaSet(RS)：是对ReplicationController(RC)的一个升级，可以通过selector来选择对那些Pod进行副本的扩容或者缩容。
• Deployment：是对RS的再次封装升级，在RS的基础上添加了新的功能。

2.1.deployment的配置文件

​ deployments的配置文件和pod的配置文件都为yaml格式。在本文中还是以nginx为例，创建一个nginx的deployment文件，下面为该deployment的配置文件，该文件名为nginx-deploy.yaml

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
  selector: # 选择器，用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时，更新的个数最多可以超过期望副本数的个数/比例
      maxUnavailable: 25% # 进行滚动更新时，最大不可用比例更新比例，表示在所有副本数中，最多可以有多少个不更新成功
    type: RollingUpdate # 更新类型，采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
      - image: nginx:1.7.9 # 镜像
        imagePullPolicy: IfNotPresent # 拉取策略
        name: nginx # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

# 使用以下命令进行对deploy进行创建
kubectl crate -f nginx-deploy.yaml

#然后通过以下命令就可以查看到目前创建成功的deployment了
kubectl get deploy

2.2 .deployment添加副本数

# 使用以下命令就可以直接进行deploy的配置文件中进行编辑
kubectl edit deploy <资源名称>
# 将配置文件中的replicas进行修改就可以得到想要的副本数量

本文中将replicas改为了3，此时就有了3个nginx的deployment资源。其结果如下图所示：

通过上图观察，就可以发现deploy，rs，po三者之间的关系：一个deploy下有一个rs，而一个rs下又对于多个pod。

2.3.deployment滚动更新

• 在滚动更新之前一定要进行副本数的添加，或者在创建配置文件时，就将副本数设置为大于1。(虽然一个deployment资源也可以更新，但是体现不了滚动的这个操作)。
• 只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作。

本例中依然以nginx-deploy为例。具体步骤如下：

#Step1 修改nginx-deploy的template中的 - image: nginx:1.7.9 
- image: nginx:1.7.9  修改为 - image: nginx:1.9.1
#Step2 此时滚动更新操作已经在进行了,可以通过以下命令进行查看,其结果如下图所示
kubectl get deploy
kubectl get rs
kubectl get po

• 通过上图可以观察发现，deploy的UP-TO-DATE会逐渐从1变成了3，因为本例中一共就3个deployment副本，所以到3就说明更新结束了。
• 再看ReplicaSet(rs)，可以发现它的序号已经变了，上图中从577变为了fd7。
• 最后再查看pod，可以发现，pod的管理现在都已经到fd7下面了。

（可能这里会有疑惑，为什么和添加副本数的结果图，没有什么区别，因为本例中进行了2次回滚更新，从1.7.9->1.9.1然后又从1.9.1->1.7.9，所以deployment又回到了之前那个版本的rs）

#Step3 使用以下命令可以详细观察到deploy的滚动更新策略
kubectl describe deploy nginx-deploy(资源名称,本例中为nginx-deploy)

可以观察到再up一个后会down一个。直到up数量到达3，此时down的数量也就到达了0。其具体过程如下图所示，然后按照下图的操作不断进行滚动更新，直到所有deployment完成。

2.4.deployment回滚版本

​ 在2.3中，我们将nginx的- image: nginx:1.7.9修改为了1.9.1，此时如果我们要回到1.7.9就可以使用回滚操作。当然回滚操作大多数使用在更新错了参数的情况下。

#Step1 使用以下命令可以看到历史的版本号，如下图所示
kubectl rollout history deployment/nginx-deploy

#Step2 使用以下命令可以看到不同版本号的区别,如下图所示
kubectl rollout history deployment/nginx-deploy --revision=4(写自己要查看的版本号)
#Step3 使用以下命令可以回滚到指定版本
kubectl rollout undo deployment/nginx-deploy --to-revision=2(写自己要回滚的版本号)

#Step4 可以通过以下命令或者去yaml文件中查看，可以看到已经回滚成功了
 kubectl rollout status deployment/nginx-deploy

这时在进行rs的观察的话，会发现已经回到了1.7.9版本的那个rs区域。(这里就跟2.3中的图对上了)。

可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了。

2.5. deployment扩容缩容

在2.2中介绍的添加副本数量，其实也就是对deployment的扩容。但是对yaml文件进行修改并不方便。所以下面介绍以下常用的扩容—缩容方法。(其实就是按同一套模板，创建新的副本数量）。

# 对deployment进行扩容，这里是将nginx-deploy的数量扩容到6个
 kubectl scale --replicas=6 deploy nginx-deploy
 
# 对deployment进行缩容，这里是将nginx-deploy的数量扩容到3个
 kubectl scale --replicas=3 deploy nginx-deploy

2.6.deployment暂停与恢复

由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout。

# 通过以下命令就可以实现暂停
kubectl rollout pause deployment <name>

#可以通过对rs进行查看，就可以发现并没有进行滚动更新操作

# 通过以下命令就可以实现恢复
kubectl rollout resume deploy <name>

#再次通过对rs进行查看，就可以发现滚动更新操作开始进行了

# 通过以下命令就可以实现暂停
kubectl rollout pause deployment <name>

#可以通过对rs进行查看，就可以发现并没有进行滚动更新操作

# 通过以下命令就可以实现恢复
kubectl rollout resume deploy <name>

#再次通过对rs进行查看，就可以发现滚动更新操作开始进行了