k8s--基础--14--deployment

案例1，案例2 说的就是滚动更新，需要加readinessProbe和livenessProbe探测，确保pod中容器里的应用都正常启动了才删除之前的pod；启动的第一步，刚更新第一批pod就暂停；假如目标是5个，允许一个也不能少，允许最多可以10个，那一次加5个即可；...

单身贵族男

1819人浏览 · 2022-08-10 19:35:24

单身贵族男 · 2022-08-10 19:35:24 发布

k8s–基础–14–deployment

1、概念

是一个控制器,用于维护同一个Pod 的数量。
为replicaSet和Pod提供了一个声明式更新的方法。
1. 声明式更新：
  1. 修改配置文件:deployment_nginx.yaml
  2. 再执行命令：kubectl apply -f deployment_nginx.yaml
  3. 上面的操作能立马能生效，就是声明式更新
在Deployment对象中描述一个期望的状态(副本数)，Deployment就会按照一定的控制速率把实际状态改成期望状态。

1.1、作用

Deployment可以使用声明式定义，直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，也就是通过打补丁的方式进行修改，一般我们通过直接修改配置文件来更新
Deployment能提供滚动式自定义自控制的更新,可以在实现更新时还可以实现控制更新节奏和更新逻辑

1.1.1、什么叫做更新节奏和更新逻辑呢

比如说ReplicaSet控制5个pod副本，pod的期望值是5个，但是升级的时候需要额外多几个pod，那么我们控制器可以控制在5个pod副本之外还能再增加几个pod副本；

1.1.1.1、案例1

比方说能多一个，但是不能少，那么升级的时候就是先增加一个，再删除一个，再增加一个删除一个，始终保持pod副本数是5个，但是有个别交叉之间是6个；

1.1.1.2、案例2

比方说最多允许多一个，最少允许少一个，也就是最多6个，最少4个，第一次加一个，删除两个，第二次加两个，删除1个，依次类推，可以自己控制更新方式

1.1.1.3、总结

案例1，案例2 说的就是滚动更新，需要加readinessProbe和livenessProbe探测，确保pod中容器里的应用都正常启动了才删除之前的pod；

启动的第一步，刚更新第一批pod就暂停；假如目标是5个，允许一个也不能少，允许最多可以10个，那一次加5个即可；这就是我们可以自己控制节奏来控制更新的方法

1.2、架构

1.2.1、结构

在这里插入图片描述

上面是Deployment,下面是replicaSet，绿色的表示处于活跃状态的replicaSet，一般只保留历史10个版本;
Deployment是建立在replicaSet之上的,底层是replicaSet

1.2.2、运行

在这里插入图片描述

Deployment是建构在replicaSet之上的，多个replicaSet组成一个Deployment，但是只有一个replicaSet处于活跃状态，当你更新到一个新版本的时候，只是创建了一个新的replicaSet，把旧的replicaSet替换掉了
replicaSet的v1控制三个pod，删除一个，在replicaSet的v2上重新建立一个，依次类推，直到全部都是由replicaSet2控制，如果replicaSet v2有问题，还可以回滚

1.2.3、怎么创建和删除Deployment

创建Deployment，会创建ReplicaSets，通过replicaset创建pod。
删除Deployment，会删除Deployment下对应的replicaSet,通过replicaset删除pod。

1.3、使用场景

创建无状态的应用
滚动更新和回滚

2、查看部署一个deployment时需要哪些字段

2.1、命令

# 查看 deployment 的定义
kubectl explain deployment 

# 查看 spec 的定义
kubectl explain deployment.spec
# 查看 template 的定义
kubectl explain deployment.spec.template

# 查看 template.spec 的定义
kubectl explain deployment.spec.template.spec

结果：这里只显示deployment 的定义


[root@master1 ~]# kubectl explain deployment 
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates forPodsand ReplicaSets.

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object metadata.

   spec	<Object>
     Specification of the desired behavior of the Deployment.

   status	<Object>
     Most recently observed status of the Deployment.

[root@master1 ~]#

说明

需要apiVersion，kind，metadata，spec字段
kind：Deployment
apiversion：apps/v1

2.2、重要字段说明

2.2.1、deployment.spec.template

# 定义
kubectl explain deployment.spec.template

定义一个Pod模板，且需要给pod模板设置标签。
1. 注意：不要与其他控制器的选择器重叠。
这个就是当pod挂掉的时候，新启动的pod的模板

2.2.2、deployment.spec.template.spec.restartPolicy

# 定义
kubectl explain deployment.spec.template.spec.restartPolicy

重启策略
OnFailure
Always：默认值

2.2.3、deployment.spec.selector

# 定义
kubectl explain deployment.spec.selector

标签选择器。
可以选择它所匹配的拥有相同标签的pod。
当pod挂掉的时候，deployment就通过标签选择器，选择指定标签的pod模板，再通过pod模板创建pod。
在deployment中，deployment.spec.template.metadata.labels必须匹配deployment.spec.selector，否则将被API拒绝。

注意：

不应直接通过创建另一个Deployment或创建另一个控制器(例如ReplicaSet或ReplicationController)来创建其标签与该选择器匹配的其他Pod。如果这样做，则第一个Deployment会认为它创建了其他Pod。如果你有多个具有重叠选择器的控制器，则这些控制器将相互竞争，并且无法正常运行

2.2.4、deployment.spec.replicas

# 定义
kubectl explain deployment.spec.replicas

指定要同时运行多少个 Pod。
在任何时间运行的 Pod 数量可能高于或低于 deployment.spec.replicas 指定的数量，例如在副本刚刚被增加或减少后、或者 Pod 正在被优雅地关闭、以及替换提前开始。
默认值：1

2.2.5、deployment.spec.strategy

# 定义
kubectl explain deployment.spec.strategy

指定用新Pods替换旧Pods的策略。

2.2.6、deployment.spec.strategy.type

# 定义
kubectl explain deployment.spec.strategy.type

指定策略类型
Recreate：
1. 重建：所有现有的Pods在创建新Pods之前被杀死。
RollingUpdate：
1. 默认值
2. 采取滚动更新的方式更新Pods。可以指定maxUnavailable和maxSurge来控制滚动更新操作。

2.2.7、deployment.spec.strategy.rollingUpdate.maxUnavailable

# 定义
kubectl explain deployment.spec.strategy.rollingUpdate.maxUnavailable

是一个可选字段
用于指定在更新过程中不可用的pod的最大数量
该值不能为0,可以是绝对数(例如5)或者所需pod的百分比(例如10％)
1. 绝对数：按照四舍五入的百分比计算
默认值：25％
举例：
1. 当此值设置为30％时，在滚动更新开始时，立即将旧的ReplicaSet缩小为所需Pod的70％。一旦准备好新的Pod，就可以进一步缩小旧的ReplicaSet的大小，然后按比例放大新的ReplicaSet，以确保更新期间始终可用的Pod总数至少为所需Pod的70％。

2.2.8、deployment.spec.strategy.rollingUpdate.maxSurge

# 定义
kubectl explain deployment.spec.strategy.rollingUpdate.maxSurge

是一个可选字段
用于指定可以在所需数量的Pod上创建的最大Pod数量。
该值不能为0,可以是绝对数(例如5)或所需Pod的百分比(例如10％)。
1. 绝对数是通过四舍五入从百分比中得出的
默认值：25％。
举例：
1. 当此值设置为30％时，可以在滚动更新开始时立即按比例放大新的ReplicaSet，以使旧Pod和新Pod的总数不超过所需Pod的130％。一旦旧Pod被杀死，新的ReplicaSet便可以进一步扩展，以确保更新期间随时运行的Pod总数最多为所需Pod的130％。

2.2.9、deployment.spec.progressDeadlineSecond

# 定义
kubectl explain deployment.spec.progressDeadlineSecond

是一个可选字段
用于指定在系统报告部署失败之前你要等待部署进行的秒数
默认值：600
此字段必须大于deployment.spec.minReadySeconds
举例：
1. 以Type=Progressing， Status=False以及Reason=ProgressDeadlineExceeded资源的状态为例。deployment控制器将继续重试部署。将来，一旦实现自动回滚，Deployment控制器将在观察到这种情况后立即回滚Deployment

2.2.10、deployment.spec.minReadySeconds

# 定义
kubectl explain  deployment.spec.minReadySeconds

是一个可选字段
用于指定新创建的Pod在不使其任何容器崩溃的情况下应准备就绪的最小秒数，以便将其视为可用。
默认值：0
1. 准备就绪后，Pod将被视为可用

2.2.11、deployment.spec.revisionHistoryLimit

# 定义
kubectl explain  deployment.spec.revisionHistoryLimit

是一个可选字段
用于指定要保留的可用于回滚的旧的replicaset的数量。
deployment的修订历史记录存储在它的ReplicaSets中。因此，一旦删除了旧的ReplicaSet，你将无法回滚到该版本的Deployment。
默认值：10
1. 将保留10个旧的ReplicaSet

2.2.12、deployment.spec.paused

# 定义
kubectl explain  deployment.spec.paused

是一个可选的布尔字段
用于暂停和恢复部署。
暂停的Deployment和未暂停的Deployment之间的唯一区别
1. 只要暂停，对暂停的Deployment的PodTemplateSpec所做的任何更改都不会触发新的rollouts(滚动更新)。
2. 当创建时，默认情况下不会暂停deployment。

3、案例：使用deployment部署一个无状态应用

3.1、配置文件

vim /root/test/deployment_nginx.yaml

内容

apiVersion: apps/v1
kind: Deployment
metadata:
  # Deployment 的名称
  name: deployment-nginx
  # Deployment 的标签
  labels:
    k1: k1_la
    k2: k2_la
spec:
  # 副本数目
  replicas: 3
  # 选择器
  selector:
    # 选择器匹配的标签
    matchLabels:
      nginx_pod: nginx_pod_la
  # Pod 模板
  template: 
    metadata:
      # Pod的标签
      labels:
        nginx_pod: nginx_pod_la
    spec:
      containers:
        # 容器名称
      - name: nginx
        # 镜像
        image: nginx
        # 镜像策略
        imagePullPolicy: IfNotPresent
        # 容器端口
        ports:
        - containerPort: 80

3.2、启动

kubectl apply -f /root/test/deployment_nginx.yaml

3.3、验证

3.3.1、查看deployment

kubectl get deployment

在这里插入图片描述

NAM: deployment的名称。
READY：deployment有多少副本数。它遵循ready/desired的模式。
UP-TO-DATE：显示已更新到所需状态的副本数。
AVAILABLE：显示你的可以使用多少个应用程序副本。
AGE：显示应用程序已运行的时间。

3.3.2、查看replicaset

因为创建deployment的时候会创建一个replicaset，replicaset会在后台创建pod,所以我们查看下

kubectl get rs

在这里插入图片描述

NAME：ReplicaSet的名称。
DESIRED：显示应用程序的所需副本数，这些副本数是在创建时定义的。这是所需的状态。
CURRENT：显示当前正在运行多少个副本。
READY：显示你的用户可以使用多少个应用程序副本。
AGE：显示应用程序已运行的时间。


ReplicaSet的名称规则: DEPLOYMENT-NAME-随机生成字符串

3.3.3、查看deployment对应的pod

kubectl get pods | grep deployment-nginx

在这里插入图片描述

名称为：ReplicaSet的名称+随机数

3.3.4、展示刚才创建的deployment详细信息

kubectl describe deployment deployment-nginx

在这里插入图片描述

3.3.5、列出deployment创建的拥有标签是nginx_pod=nginx_pod_la的pods

kubectl get pods -l nginx_pod=nginx_pod_la

在这里插入图片描述

3.3.6、更新deployment：更新nginx的镜像版本

编辑配置文件，将nginx版本改为1.8

vim /root/test/deployment_nginx.yaml

在这里插入图片描述

执行

kubectl apply -f /root/test/deployment_nginx.yaml

查看该deployment创建的pods，可发现创建新的pod的同时删除了旧的pods

kubectl get pods -l nginx_pod=nginx_pod_la

在这里插入图片描述

3.3.7、通过增加副本数来扩容pod应用

编辑配置文件，修改副本数为4

vim /root/test/deployment_nginx.yaml

在这里插入图片描述

执行

kubectl apply -f /root/test/deployment_nginx.yaml

在这里插入图片描述

3.3.8、查看历史版本

kubectl rollout history deployment deployment-nginx

在这里插入图片描述

3.3.9、按照指定版本回滚

kubectl rollout undo deployment/deployment-nginx --to-revision=1 
kubectl get pods -l nginx_pod=nginx_pod_la

在这里插入图片描述

3.3.10、删除deployment

kubectl delete deployment deployment-nginx
kubectl get rs
kubectl get pods -l nginx_pod=nginx_pod_la

在这里插入图片描述

K8S/Kubernetes

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

更多推荐

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

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

K8S/Kubernetes

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

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

K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

K8S/Kubernetes

所有评论(0)

查看更多评论

单身贵族男

@zhou920786312

已为社区贡献55条内容

k8s--基础--14--deployment

单身贵族男

k8s–基础–14–deployment

1、概念

1.1、作用

1.1.1、什么叫做更新节奏和更新逻辑呢

1.1.1.1、案例1

1.1.1.2、案例2

1.1.1.3、总结

1.2、架构

1.2.1、结构

1.2.2、运行

1.2.3、怎么创建和删除Deployment

1.3、使用场景

2、查看 部署一个deployment时需要哪些字段

2.1、命令

结果：这里只显示deployment 的定义

说明

2.2、重要字段说明

2.2.1、deployment.spec.template

2.2.2、deployment.spec.template.spec.restartPolicy

2.2.3、deployment.spec.selector

注意：

2.2.4、deployment.spec.replicas

2.2.5、deployment.spec.strategy

2.2.6、deployment.spec.strategy.type

2.2.7、deployment.spec.strategy.rollingUpdate.maxUnavailable

2.2.8、deployment.spec.strategy.rollingUpdate.maxSurge

2.2.9、deployment.spec.progressDeadlineSecond

2.2.10、deployment.spec.minReadySeconds

2.2.11、deployment.spec.revisionHistoryLimit

2.2.12、deployment.spec.paused

3、案例：使用deployment部署一个无状态应用

3.1、配置文件

3.2、启动

3.3、验证

3.3.1、查看deployment

3.3.2、查看replicaset

3.3.3、查看deployment对应的pod

3.3.4、展示刚才创建的deployment详细信息

3.3.5、列出deployment创建的拥有标签是nginx_pod=nginx_pod_la的pods

3.3.6、更新deployment：更新nginx的镜像版本

3.3.7、通过增加副本数来扩容pod应用

3.3.8、查看历史版本

3.3.9、按照指定版本回滚

3.3.10、删除deployment

所有评论(0)

单身贵族男

2、查看部署一个deployment时需要哪些字段