架构师系列-k8s（四）-Deployment控制器

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态，也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deploy

dengwei_dw

1126人浏览 · 2024-04-27 17:24:29

dengwei_dw · 2024-04-27 17:24:29 发布

3. Deployment控制器

3.1 Deployment概述

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新

只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态，也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

3.1.1 其他特性

Deployment控制器资源的主要职责是为了保证Pod资源的健康运行，其大部分功能均可通过调用ReplicaSet实现，同时还增添部分特性。

事件和状态查看：必要时可以查看Deployment对象升级的详细进度和状态。
回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上。
版本记录：对Deployment对象的每一个操作都予以保存，以供后续可能执行的回滚操作使用。
暂停和启动：对于每一次升级，都能够随时暂停和启动。
多种自动更新方案：一是Recreate，即重建更新机制，全面停止、删除旧有的Pod后用新版本替代；另一个是RollingUpdate，即滚动升级机制，逐步替换旧有的Pod至新的版本。

3.2 Deployment配置

3.2.1 编辑资源清单

vi nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  minReadySeconds: 2  # 这里需要估一个比较合理的值，从容器启动到应用正常提供服务
  strategy:  # k8s 默认的 strategy 就是 RollingUpdate， 这里写明出来可以调节细节参数
    #type: Recreate
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1  # 更新时允许最大激增的容器数，默认 replicas 的 1/4 向上取整
      maxUnavailable: 0  # 更新时允许最大 unavailable 容器数，默认 replicas 的 1/4 向下取整
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

3.2.2 配置项说明

3.2.2.1 配置解释

我们定义了一个Deployment，名字叫nginx-deployment；
通过spec.replicas字段定义了Pod的副本数是2；
通过minReadySeconds设置等待多长的时间后才进行升级
通过spec.selector字段定义了被打上app: nginx的标签的Pod才会被管理；
tmplate字段定义了这个Deployment管理的Pod应该是怎样的，具有怎样的属性；

3.2.2.2 控制器描述

总的来说一个Deploymet控制器可以由两部分组成：

3.2.3 创建控制器

kubectl apply -f nginx-deployment.yml
kubectl get pods -o wide

3.2.4 查看replicaset

ReplicaSet是一个副本控制器，ReplicaSet可以用selector来控制Pod的数量，而Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。

kubectl get replicaset -o wide

通过查看资源对象可以看出，Deployment会自动创建相关的ReplicaSet控制器资源，并以"[DEPLOYMENT-name]-[POD-TEMPLATE-HASH-VALUE]"格式为其命名，其中的hash值由Deployment自动生成。而Pod名则是以ReplicaSet控制器的名称为前缀，后跟5位随机字符。

3.3 更新策略

ReplicaSet控制器的应用更新需要手动分成多步并以特定的次序进行，过程繁杂且容易出错，而Deployment却只需要由用户指定在Pod模板中要改动的内容，（如镜像文件的版本），余下的步骤便会由其自动完成。Pod副本数量也是一样。

Deployment控制器支持两种更新策略：滚动更新（rolling updata）和重建更新（recreate），默认情况下为滚动更新

3.3.1 重建更新

重建更新为：先删除所有的Pod再根据新的模板创建新的Pod，中间会导致服务的不可用，用户要么使用的是新版本，要么就是旧版本

3.3.2 滚动更新

滚动更新是默认的更新策略，它在删除一些旧版本的Pod的同时补充创建一些新的Pod，更新期间服务不会中断。

滚动更新期间，应用升级期间还要确保可用的Pod对象数量不低于某些阈值，确保可以持续处理客户端请求，变动的方式和Pod对象的数量范围将通过maxSurge和maxunavailable两个属性协同进行定义

配置参数

两个参数用法如下：

maxSurge：指定升级期间存在的总Pod对象数量最多以超出期望值的个数，其值可以为0或者正整数，也可以是一个期望值的百分比：例如如果期望值是3，当前的属性值为1，则表示Pod对象的总数不能超过4个。
maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望的个数、其值可以是0或者正整数，也可以是一个期望值的百分比，默认值为1；该值意味着如果期望值是3，那么在升级期间至少要有两个Pod对象处于正常提供服务的状态

maxSurge和maxUnavailable的数量不能同时为0，否则Pod对象的复本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

3.4 更新控制器

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

3.4.1 命令更新

3.4.1.1 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.1.2 执行更新命令
kubectl set image deployment/nginx-deployment nginx=nginx:1.15

3.4.1.3 查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现更新后新建了一个RS，并且保留原来的RS但是节点数为0用来回滚

3.4.1.4 查看版本

通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.2 配置更新

3.4.2.1 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.2.2 编辑资源清单
vi nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.20 # 将nginx版本改为1.20
        ports:
        - containerPort: 80


3.4.2.3 应用更新
kubectl apply -f nginx-deployment.yml

3.4.2.4 查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w
我们发现更新后新建了一个RS，并且保留原来的RS但是节点数为0用来回滚

3.4.2.5 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.3 回滚更新

通过rollout命令进行回滚操作

3.4.3.1 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.3.2 执行回滚命令
kubectl rollout undo deployment/nginx-deployment

3.4.3.3 查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w
我们发现回滚没有创建新的rs而是将使用了原来的rs

3.4.3.4 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.4 再次回滚

3.4.4.1 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

3.4.4.2 执行回滚命令
kubectl rollout undo deployment/nginx-deployment

3.4.4.3 查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w
我们发现回滚没有创建新的rs而是将使用了原来的rs

3.4.4.4 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image
我们发现rollout回滚只在最近的两个版本之间来回回滚，不会回滚到在上一个版本。

3.4.5 回滚指定版本

# 查看历史版本
通过rollout history查看版本历史

kubectl rollout history deployment/nginx-deployment

# 历史版本内容
通过指定版本号来查看变更内容，找到需要回滚的版本，这里我会回滚到最早版本nginx:1.7.9

kubectl rollout history deployment/nginx-deployment --revision=1
我们找到了需要回滚的版本是1

# 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

#执行回滚命令
写入我们需要回滚到的指定版本1

kubectl rollout undo deployment/nginx-deployment --to-revision=1

# 查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image
到此我们已经回滚到了指定版本

3.5 Deployment扩缩容

3.5.1 scale命令扩容

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

3.5.1.1 查看当前容量

当前是两个节点

3.5.1.2 执行扩容

使用scale命令可以对集群进行扩缩容，扩充到4个节点

 kubectl scale deployment nginx-deployment --replicas=4

3.5.1.3 查看扩容过程

在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面增加了两个节点

3.5.2 配置文件缩容

配置文件扩缩容一般用于初始容量变更，长期进行扩缩容

3.5.2.1 查看当前容量

当前是4个节点

kubectl get pods -o wide

3.5.2.2 应用配置文件

因为我们没有更改配置文件，直接应用配置文件即可

kubectl apply -f nginx-deployment.yml

3.5.2.3 查看扩容过程

在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面减少了两个节点

3.6 删除Deployment

3.6.1 查看集群情况

#查看Deployment
kubectl get deployments -o wide

# 查看POD
kubectl get pods -o wide

#删除Deployment
执行删除命令删除Deployment

kubectl delete deployment nginx-deployment

#查看Deployment
kubectl get deployments -o wide

# 查看POD
kubectl get pods -o wide

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub