kubernetes控制器-Deployment

一 、ReplicaSet

1.1 传统的部署方式

传统部署应用，保证业务的高可用，都是通过2个或者2个以上多实例的方式进行部署，通过Nginx负载均衡的方式进行对外进行暴露，如果一个实例出现故障，仍然有一个实例提供服务，如果需要对实例进行扩缩容，就是需要通过Nginx的配置upstream的配置，进行配置实例，实现Nginx的负载均衡，对业务进行调度。

1.2 什么是ReplicaSet

在 Kubernetes 环境中，通过 ReplicaSet帮助我们实现集群的高可用， ReplicaSet (RS)的主要作用就是维持一组 Pod 副本的运行，保证一定数量的 Pod 在集群中正常运行，ReplicaSet 控制器会持续监听它控制的这些 Pod 的运行状态以及数量，保证应用集群的高可用;

1.3 ReplicaSet 的组成部分

ReplicaSet控制器包含了3个基本的组成部分

• seLector 标签选择器: 匹配并关联Pod对象，并加入控制器的管理中;
• repLicas期望的副本数: 期望在集群中所运行的Pod对象数量;
• template Pod模板: 实际上就是定义的Pod 规范，相当于把一个Pod 的描述以模板的形式嵌入到了 ReplicaSet

ReplicaSet:
如果想运行一个RS的控制器，来管理Pod；
1.必须有template字段，用来描述Pod规范（给Pod打标签）； 定义容器、定义镜像、定义resource、lifecycle、 做成一个模板；
2.必须在RS控制器申明我需要管理那些Pod；是通过标签选择器来选择要管理的Pod； Selector：
3.就可以通过RS控制器来管理并运行该Pod；（将Pod的描述信息通过模板的形式嵌入到了ReplicaSet中；）
4.如果期望运行的副本数是3或者是5；只需要通过修改replicas字段就可以完成；

1.4 ReplicaSet 的示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: king-replicaset
  namespace: king-dp
spec:                           # 定义RS的规范
  replicas: 5                   # 启动5个相同的Pod 
  selector:                     # RS通过Selector选择一组Pod，并进行管理
    matchLabels:
      app: nginx

  template:                     # 定义Pod的模板；当RS需要创建Pod时就通过模板来创建
    metadata:
      labels:                   # 所有通过该模板运行的Pod都有app=nginx这个标签
        app: nginx 
    spec:
      containers:
      - name: mall
        image: nginx:1.16
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

1.5 ReplicasSet 验证

kubectl  get rs -n king-dp  -o wide
kubectl  get pod -n king-dp -o wide 

• 1
• 2
• 3

• 即使删除pod都是会保持pod数量的期望值

二、Deployment

2.1 什么是Deployment

Deployment (简称为deploy) 是Kubernetes控制器的一种高级别实现，他构建于ReplicaSet控制器之上。
我们只需要描述Deployment中的目标Pod期望状态，而DepLoyment控制器以受控速率更改实际状态，使其变为期望状态，也就是说，后期我们部署应用不直接使用Pod和ReplicaSet，而是使用Deployment控制器来调用ReplicaSet来实现，Deployment控制器在ReplicaSet原有基础上，添加了部分特性。

• 1、事件和状态查看: 可以通过特定的命令查看Deployment对象的更新进度和状态;
• 2、版本记录: 将Deployment对象的更新操作都进行保存，以便后续执行回滚操作使用;
• 3、多种更新方案: Recreate重建，可以实现单批次更新所有PodRolLingUpdate可以实现多批次逐步替换Pod

2.2 Deployment的组成部分

DepLoyment 资源对象的格式和 ReplicaSet 几乎一致，Deployment 控制器也包含了3个基本的组成部分

• selector标签选择器: 匹配并关联Pod对象，并对授其管控的Pod对象计数;
• replicas期望的副本数: 期望在集群中所运行的Pod对象数量;
• template Pod模板: 实际上就是定义的 Pod 内容，相当于把一个Pod 的描述以模板的形式嵌入到了 ReplicaSet

2.3 Deployment示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3                   # 期望的副本数
  selector:                     # Deployment要管理的Pod有哪些 只要标签app=nginx就加入进行管理
    matchLabels:
      app: nginx

  template:                     # Pod模板；有标签；有Pod规范
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21

2.4 查看Deployment和ReplicaSet 的关系

kubectl  get replicasets
kubectl  get pod  -l app=nginx 
kubectl  get deployments

• 1
• 2
• 3

2.5 Deployment的场景应用

场景说明: 运行一个demoapp的应用，部署3个副本，然后通过service来实现负载均衡;

• 1、创建 Deployment资源，部署三个副本
• 2、创建 Service资源，通过标签选择器选择对应的Pod，以实现负载均衡;
• 3、使用 curl命令，或Chrome浏览器验证集群高可用;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
  namespace: default
spec:
  strategy:
    type: Recreate      # 更新镜像的策略为Recreate
  replicas: 4            # 副本数
  selector:             # 通过标签选择器选择要管理的Pod
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver
        image: nginx
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24

apiVersion: v1
kind: Service
metadata:
  name: demoapp-service
spec:
  selector:
    app: demoapp        # Service通过标签选择器将对应的Pod定义为一组backend，而后将所有请求调度到这组Pod上
  ports:
  - name: http
    port: 80            # 负载均衡的端口
    targetPort: 80      # 后端节点的端口

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

2.6 Deployment的负载均衡测试

• 跳转到pod的IP上
  

2.7 Deployment的水平伸缩

1、通过命令的方式进行replicaset的修改

kubectl  scale  deployment  demoapp-deploy  --replicas=2

• 1

2、通过修改yaml文件的方式修改replicaset副本数量

kubectl  edit  deployments demoapp-deploy  

• 1

2.8 Deployment的状态检查

• NAME 列出了集群中 Deployment 的名称。
• READY 显示应用程序的可用的“副本”数。显示的模式是"就绪个数期望个数”。
• UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
• AVAILABLE 显示应用可供用户使用的副本数。
• AGE 显示应用程序运行的时间。

2.9 故障转移

• 模拟背景
  将所有的pod删除

kubectl  delete pod --all

• 1

• 再次查询有控制器控制的pod会继续起来,replicaset 会保持跟原来的保持一致，但是随机ID发生变化。保持原有的期望值。

kubectl get pod 

• 1

• 全部删除pod 但是pod的IP和node的节点也会发生变化，只有service负载不发生变化，还会继续调度到后端的pod中

3.0 滚动更新

• 方法一：

kubectl  set image deployment/nginx-deploy nginx=nginx:1.24.0 --record
kubectl get pod -l app=nginx -w  ## 进行状态跟踪
kubectl rollout status deployment/nginx-deploy

• 1
• 2
• 3

• 方法二：通过修改配置文件的方式

kubectl edit deployment nginx-deploy 

• 1

3.1 版本回退

• 1、查看deployment的发布的历史版本

kubectl rollout history deployment/nginx-deploy

• 1

因为第一次使用了的是yaml进行配置，导致历史版本没有被记录

• 2、回退到上一次，或者其他的历史版本

kubectl  rollout  undo  deployment/nginx-deploy  --to-revision=1
kubectl get deployment nginx-deploy -o yaml | grep image  ##查看回退后的镜像版本

• 1
• 2

三、Deployment的自动扩缩容

Deployment自动扩缩容 -HPA

1、HPA的概述

Kubernetes实现Pod的扩缩容需要通过手动来实现，但线上的业务情况比较复杂，依赖于纯手动的方式，不太现实。所以希望系统能自动感知Pod的压力来完成扩缩容，比如: 当Pod的CPU达到了50%则扩容，当Pod的CPU低于50%自动缩容。

为此Kubernetes为我们提供了这样的一个资源对象HPA (horizontalpod-autoscaler) ，专用来实现Pod的水平自动扩缩容。HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整Pod 的副本数量;

2、HPA自动扩缩容的算法

算法: 副本数 =[当前副本数 (当前指标 期望指标]]当前指标: 当前Pod已经达到了百分之多少的压力;期望指标: 当Pod达到期望的指标百分比时就要进行扩容;
例如，当前副本为1，当前当前指标值250%，而期望的指标值是50%，则副本数会翻5倍，因为 1 * (250%/5%) = 5

3、安装MetricServer

参考上一章节的安装方法

4、HPA 压测示例

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: deployment-example
spec:
  replicas: 1
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
     containers:
     - name: php
       image: hpa-example
       ports:
       - name: http
         containerPort: 80 
       resources:
         requests:
           cpu: 200m
         limits:
           cpu: 500m 
        

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

apiVersion: v1
kind: Service
metadata:
  name: hpa-service
spec:
  selector: 
    run: php-apache
  ports:
  - name: http
    port: 80 
    targetPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

• 创建于结果检查

kubectl get deployment 
kubectl get pod -o wide 
kubectl get svc 

• 1
• 2
• 3
• 4

• 创建HPA的自动化扩缩容

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-example
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-example
  targetCPUUtilizationPercentage: 50

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

• 检查HPA

kubectl  get hpa 

• 1

• 压测和跟踪结果
  压测命令：

while sleep 0.01; do curl http://svcIP; done

• 1

pod资源跟踪方法，每一秒跟踪一次

watch -n 1  kubectl top pod 
watch -n 1  kubectl get hpa
watch -n 1  kubectl get pod 

• 1
• 2
• 3

可以观察到pod开始创建

四、Deployment的重建策略

1、Reacreate更新策略

重建 (Recreate)当更新策略设定为 Recreate，在更新镜像时它会先杀死正在运行的Pod，等彻底杀死后，重新创建新的RS，然后启动对应的Pod，那么在这个更新过程中，会造成服务一段时间无法提供服务;

• 第一步: 同时杀死所有旧版本的Pod，此时Pod无法正常对外提供服务;
• 第二步: 创建新的RS，启动新的Pod;
• 第三步: 等待Pod就绪，对外提供服务:

2、Deployment的Reacreate更新策略实验示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
  namespace: default
spec:
  strategy:
    type: Recreate      # 更新镜像的策略为Recreate
  replicas: 4            # 副本数
  selector:             # 通过标签选择器选择要管理的Pod
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24

apiVersion: v1
kind: Service
metadata:
  name: demoapp-service
spec:
  selector:
    app: demoapp        # Service通过标签选择器将对应的Pod定义为一组backend，而后将所有请求调度到这组Pod上
  ports:
  - name: http
    port: 80            # 负载均衡的端口
    targetPort: 80      # 后端节点的端口

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

3、通过修改镜像版本进行更新

image: demoapp:v1.0 更好为 image: demoapp:v1.1

修改镜像版本命令：
kubectl  edit    demoapp-deploy
跟踪pod的变化：
watch kubectl get pod  -n default
查看测试结果：
while sleep 0.5 ;do curl service:ip;done 

• 1
• 2
• 3
• 4
• 5
• 6

全部执行更新：导致访问不能进行

Reacreate策略是全部一起更新
deployment控制器控制的所有的pod创建完成，导致访问恢复正常

4、Deployment的Reacreate的重建策略的适用场景

通常只有当应用的新旧版本不兼容 (例如依赖的后端数据的格式不同且无法兼容) 时才会使用Recreate重建策略。一般正在的生产环境，小版本更新这种比较少见，因为会影响到全部用户的使用

5、RollingUpdate更新策略

滚动更新 (RollingUpdate) ，一次仅更新一批Pod，当更新的Pod就绪后，在更新另一批，直到全部更新完成为止;该策略实现了不间断服务的目标，在更新过程中可能会出现不同的应用版本并存且，同时提供服务的情况

• 第一步: 创建新的ReplicaSet，然后根据新的镜像运行新的Pod;
• 第二步: 删除旧的Pod，启动新的Pod，新Pod就绪后，继续删除旧Pod，启动新Pod;
• 第三步: 持续第二步过程，一直到所有Pod都被更新成功。

6、RollingUpdate滚动更新策略实验示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
  namespace: default
spec:
  strategy:
    type: RollingUpdate      # 更新镜像的策略为Recreate
  replicas: 4            # 副本数
  selector:             # 通过标签选择器选择要管理的Pod
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24

修改镜像版本：
kubectl set image deployment demoapp-deploy  *=demoapp:v1.1  --record
查看pod的更新进度
kubectl get pod -n default  -l app=demoapp -w

测试版本
while sleep 1 ;do curl service:ip ;done 

• 1
• 2
• 3
• 4
• 5
• 6
• 7

7、RollingUpdate回滚策略

• 先应该检查版本发布的历史记录

查看历史发布
kubectl  rollout  history  deployment demoapp-deploy 
查看历史发布的具体版本
kubectl  rollout  history  deployment demoapp-deploy --revision=6
查看所有的rs
kubectl get rs -l app=demoapp

• 1
• 2
• 3
• 4
• 5
• 6
• 7

• RollingUpdate的更新步骤：

回退到上一个版本中
kubectl  rollout undo  deployment  demoapp-deploy  --to-revision=6
查看回退详情
kubectl  rollout  status  deployment  demoapp-deploy

• 1
• 2
• 3
• 4

8、RollingUpdate的滚动更新可选参数

DepLoyment 会在.=RolTingUpdate 时采取滚动更新的方式更新 Pods。可以指定 maxUnavailable 和maxSurge 来控制滚动更新过程。

maxSurge 最大可用Pod

• 用来指定可以创建超出期望Pod个数的 Pod数量。可以是数字0也可以是百分比 (例如10%) 此字段的默认值为25%
• 例如，当此值为 20% 时，启动滚动更新后，会立即对新的0RepLicaSet 扩容，同时保证新旧 Pod 的总数不超过所需Pod 总数的 120%。一旦旧 Pods 被杀死，新的RepLicaSet 可以进一步扩容， 同时确保更新期间的任何时候运行中的 Pods 总数最多为所需 Pods 总数的 12%。 计算公式: 10+(10x2%)=12

maxUnavailable 最大不可用Pod。

• 用来指定更新过程中不可用的 Pod 的个数上限。可以是数字也可以是百分比 (例如10%) 此字段的默认值为25%
• 例如，当此值设置为 20% 时，滚动更新开始时会立即将旧0RepLicaSet 缩容到期望 Pod 个数的70%。新 Pod 准备就绪后，继续缩容旧有的 ReplicaSet，然后对新的RepLicaSet 扩容， 确保在更新期间可用的 Pods 总数在任何时候都是所需的 Pod 个数的 70%。 计算公式: 1-(1x20%)=8

maxSurge 和 maxUnavailable 两个属性协同工作，可组合定义出3中不同的策略完成多批次的应用更新。

• 先增新，后减旧: 将maxSurge设置为30%，将maxUnavailable的值设为0;
• 先减旧，后增新: 将maxUnavailable设置为30%，将maxSurge的值设为;
• 同时增减，将maxSurge和maxUnavailable分别设定为20%:期望是12Pod，至少就绪8个Pod

8、RollingUpdate滚动更新可选参数-maxSurge

指定升级期间存在的总Pod对象数量最多可超出期望值的个数，可以是0，也可以是整数，也可以是一个百分比

例如: 期望的的值为10，maxSurge属性为2，则表示Pod对象总数不能超过12个。 计算公式: 10+(1x2%)=12

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
spec:
  strategy:
    rollingUpdate:
      maxSurge: 20%
      maxUnavailable: 0
    type: RollingUpdate  # 更新镜像的策略为RollingUpdate
  replicas: 10        
  selector:
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver 
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

编译文本方式更新镜像：
kubectl  edit    demoapp-deploy 

• 1
• 2

9、ROllingUpdate滚动更新的可选参数-maxUnavailable

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 20%
    type: RollingUpdate  # 更新镜像的策略为RollingUpdate
  replicas: 10        
  selector:
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver 
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

命令行方式更新镜像版本
kubectl set image deployment demoapp-deploy *=demoapp:v1.2 --record

• 1
• 2

10、RollingUpdate滚动更新的可选参数-maxSurge和maxUnavilable 结合使用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
spec:
  strategy:
    rollingUpdate:
      maxSurge: 20%
      maxUnavailable: 20%
    type: RollingUpdate  # 更新镜像的策略为RollingUpdate
  replicas: 10        
  selector:
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver 
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

• 更新保留80% 可用保留80%
  

11、Deployment的其他更新策略的字段

paused字段

• 是一个更新暂停的字段

[root@master ~]# kubectl  explain   | grep paused
   paused       <boolean>
     Indicates that the deployment is paused.
     estimated during the time a deployment is paused. Defaults to 600s.

• 1
• 2
• 3
• 4

minReadySeconds字段

[root@master ~]# kubectl  explain   | grep  -A 5 minReadySeconds
   minReadySeconds      <integer>
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)

   paused       <boolean>

• 1
• 2
• 3
• 4
• 5
• 6
• 7

Deployment支持使用 字段来控制滚动更新的速度，默认值为0，表示新建的Pod对象一旦 “就绪"将立即被视作可用，随后即可开始下一轮更新过程。如果设定了: 3 及表示新建的Pod对象至少要成功运行多久才会被视作可用，即就绪之后还要等待指定的 3s 才能开始下一批次的更新。在一个批次内新建的所有Pod就绪后在转为可用状态前，更新操作会被阻塞，并且任何一个Pod就绪探测失败，都会导致滚动更新被终止。

因此，为minReadySeconds 设定一个合理的值，不仅能够减缓更新的速度，还能够让Deployment 提前发现一部分程序因为Bug导致的升级故障。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
spec:
  #paused: true
  minReadySeconds: 3
  strategy:
    rollingUpdate:
      maxSurge: 20%
      maxUnavailable: 20%
    type: RollingUpdate  # 更新镜像的策略为RollingUpdate
  replicas: 20        
  selector:
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver 
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28

revisionHistoryLimit字段

[root@master ~]# kubectl  explain   | grep  -A 5 revisionHistoryLimit
   revisionHistoryLimit <integer>
     The number of old ReplicaSets to retain to allow rollback. This is a
     pointer to distinguish between explicit zero and not specified. Defaults to
     10.

   selector     <Object> -required-

• 1
• 2
• 3
• 4
• 5
• 6
• 7

Deployment保留一部分更新历史中旧版本的 ReplicaSet 对象，当我们执行回滚操作的时候，就直接使用旧版本的 ReplicaSet，在DepLoyment 资源保存历史版本数量有 属性进行定义

progressDeadlineSeconds字段

[root@master ~]# kubectl  explain   | grep  -A 5 progress
   progressDeadlineSeconds      <integer>
     The maximum time in seconds for a deployment to make progress before it is
     considered to be failed. The deployment controller will continue to process
     failed deployments and a condition with a ProgressDeadlineExceeded reason
     will be surfaced in the deployment status. Note that progress will not be
     estimated during the time a deployment is paused. Defaults to 600s.

• 1
• 2
• 3
• 4
• 5
• 6
• 7

滚动更新故障超时时长，默认为600秒，k8s 在升级过程中有可能由于各种原因升级卡住 (这个时候还没有明确的升级失败) ，比如在拉取被墙的镜像，权限不够等错误。如果配置 progressDeadlineSeconds，当达到了时间如果还卡着，则会上报这个异常情况，这个时候这个Deployment 状态就被标记为 False，并且注明原因。但是它并不会阻止 DepLoyment 继续进行卡住后面的升级操作。

五、Deployment实现灰度发布（金丝雀发布）

灰度发布 (又名金丝雀发布) 是指黑与白之前，能够平滑过度的一种发布
方式，在上面可以进行A/B Testing

• 1、首先: 让一部分用户继续使用产品特性A (旧版本)。2、其次: 让一部分用户开始使用产品特性B (新版本)
• 3、最后: 如果用户对产品特性B没有反对意见，那么逐步扩大反问将用户的流量迁移到B上面来。
  使用灰度发布的模式，可以及时发现问题，调整问题，以减少影响的速度，保证整体系统的稳定运行。

通过新版本和就版本数的增加和减少，来控制流量的准入，deployment通过标签的形式进行管理pod

1、Deployment实验案例

• 旧版本deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-prod-version-10
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demoapp
      version: v1.0

  template:
    metadata:
      labels:
        app: demoapp
        version: v1.0
    spec:
      containers:
      - name: demoapp-web
        image: demoapp:v1.0
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23

• 新版本deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-prod-version-11
spec:
  replicas: 1                   # 灰度版本，先来一个副本
  selector:
    matchLabels:
      app: demoapp
      version: v1.1

  template:
    metadata:
      labels:
        app: demoapp
        version: v1.1
    spec:
      containers:
      - name: demoapp-web
        image: demoapp:v1.1
        ports:
        - name: http
          containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23

• service只关注deployment的共同的标签

apiVersion: v1
kind: Service
metadata:
  name: demoapp-service
spec:
  selector:
    app: demoapp        # Service通过标签选择器将对应的Pod定义为一组backend，而后将所有请求调度到这组Pod上
  ports:
  - name: http
    port: 80            # 负载均衡的端口
    targetPort: 80      # 后端节点的端口

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

• 实验结果：
  通过访问svc的IP，流程可以正常打到新的版本上，如果测试新的版本没有问题，可以继续增加pod的数量，以提高新的deployment接入更多的流量。
  

六、Deployment实现滚动发布

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: rollingupdate
  labels:
    name: rollingupdate
  annotations: 
    : "v1:janakiramm/myapp:v1,v2:janakiramm/myapp:v2,v3:janakiramm/myapp:v3"
spec:
  replicas: 3
  selector:
    matchLabels:
      name: nginx
  strategy:
    rollingUpdate: # 滚动更新
      maxSurge: 1  
      maxUnavailable: 0
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        imagePullPolicy: IfNotPresent
        ports:
        - name: web
          containerPort: 80
          protocol: TCP
        startupProbe:
          failureThreshold: 5
          httpGet: 
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          timeoutSeconds: 20
          periodSeconds: 5
        livenessProbe:
          failureThreshold: 5
          periodSeconds: 5
          initialDelaySeconds:  20
          timeoutSeconds: 20
          httpGet:
            port: 80
            scheme: HTTP
            path: /
        readinessProbe:
          failureThreshold: 5
          periodSeconds: 5
          initialDelaySeconds:  20
          timeoutSeconds: 20
          httpGet:
            port: 80
            scheme: HTTP
            path: /

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51
• 52
• 53
• 54
• 55
• 56
• 57

七、Deployment实现蓝绿发布

vim

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lan
  namespace: lanlv
spec:
  replicas: 3
  selector:
    matchLabels:
      name: myapp
      version: v1
  template:
    metadata:
      labels:
        name: myapp
        version: v1
    spec:
      containers:
      - name: lan
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23

vim

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lv
  namespace: lanlv
spec:
  replicas: 3
  selector:
    matchLabels:
      name: myapp
      version: v2
  template:
    metadata:
      labels:
        name: myapp
        version: v2
    spec:
      containers:
      - name: lv
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23

vim

apiVersion: v1
kind: Service
metadata:
  name: myapp-lan-lv
  namespace: lanlv
  labels:
    app: myapp
    version: lanlv
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    name: myapp
    version: v2
 #修改配置文件,让其匹配到蓝程序
 # selector:
 #   name: myapp
 #   version: v1
 #  将V1修改为V2
    

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23

八、对某个命名空间进行资源限制

资源配额（Resource Quotas）是 Kubernetes 中用于限制命名空间内资源使用的一种机制。它可以帮助集群管理员控制资源的使用，避免某个命名空间或用户占用了过多的资源，从而影响其他用户或应用的性能。

使用场景
多租户隔离：在多租户环境中，可以为每个租户设置资源配额，保证资源的公平使用。
资源保障：确保关键应用有足够的资源来运行，防止非关键应用占用过多资源。
成本控制：通过限制资源的使用来控制成本。

使用技巧
组合限制：可以设置多种资源的配额，如 CPU、内存、Pod数量等。
配额范围：可以为不同的资源设置不同的配额范围，以适应不同的应用需求。
动态调整：根据实际使用情况动态调整配额，以优化资源利用率。

使用案例
假设我们有一个命名空间，我们希望限制该命名空间内的资源使用：
最多使用2个CPU和4GiB内存。
最多创建10个 Pods 和 Services。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: example-quota
spec:
  hard:
    cpu: "2"
    memory: 4Gi
    pods: "10"
    services: "10"
---
这个配置创建了一个名为example-quota的资源配额，应用于指定的命名空间。它限制了CPU、内存、Pods和Services的使用数量。
----

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

查看ResourceQuota的示例：

kubectl  explain  

• 1

创建和使用：

将上面的YAML保存为文件，例如。
在Kubernetes集群中应用这个配置：

kubectl apply -f  -n <your-namespace>

• 1

现在在这个命名空间中创建的任何资源都不能超过这里设置的配额。
注意：实际应用中，需要根据实际工作负载和集群资源情况调整这些值。 资源配额是Kubernetes中资源管理的重要工具，正确配置可以帮助集群管理员控制资源的使用，避免资源争抢和性能问题。

[root@master ~]# kubectl  create ns king 
namespace/king created
[root@master ~]# kubectl  apply  -f   -n king 
resourcequota/example-quota created

[root@master ~]# kubectl  get resourcequotas -n king 
NAME            AGE   REQUEST                                               LIMIT
example-quota   35s   cpu: 0/2, memory: 0/4Gi, pods: 0/10, services: 0/10   

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

删除resourcequota

## 删除配置文件，如果配置文件已经被删除，可以
[root@master ~]# kubectl  delete  resourcequotas  example-quota -n king 
resourcequota "example-quota" deleted
## 使用配置文件进行删除
[root@master ~]# kubectl  delete  -f   -n king 
resourcequota "example-quota" deleted
## 再删除命名空间
[root@master ~]# kubectl  delete  ns king 
namespace "king" deleted

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9