K8s-Replicaset、Doployment 05

最新推荐文章于 2025-12-17 23:11:06 发布

原创最新推荐文章于 2025-12-17 23:11:06 发布 · 216 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #docker

本文介绍了Kubernetes中的ReplicaSet和Deployment，重点讲解了Deployment的功能，包括创建ReplicaSet和Pod、滚动更新、回滚应用、平滑扩容和缩容。详细阐述了如何通过修改yaml文件进行扩容、缩容和滚动更新操作，并探讨了自定义滚动更新策略，如maxSurge和maxUnavailable的设置，以实现服务的稳定和高效更新。

2.Deployment资源清单文件编写技巧

3.Deployment管理pod：扩容、缩容、滚动更新、回滚

Replicaset概述

ReplicaSet是kubernetes中的一种副本控制器，简称rs，主要作用是控制由其管理的pod，使pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的Pod能够在集群中正常运行，它会持续监听这些Pod的运行状态，在Pod发生故障时重启pod，pod数量减少时重新运行新的 Pod副本。

官方推荐不要直接使用ReplicaSet，用Deployments取而代之，

Deployments是比ReplicaSet更高级的概念，它会管理ReplicaSet并提供很多其它有用的特性，最重要的是Deployments支持声明式更新，声明式更新的好处是不会丢失历史变更。所以Deployment控制器不直接管理Pod对象，而是由 Deployment 管理ReplicaSet，再由ReplicaSet负责管理Pod对象。

Deployment概述

Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚。

扩展：声明式定义是指直接修改资源清单yaml文件，然后通过kubectl apply -f 资源清单yaml文件，就可以更改资源。

Deployment控制器是建立在rs之上的一个控制器，可以管理多个rs，每次更新镜像版本，都会生成一个新的rs，把旧的rs替换掉，多个rs同时存在，但是只有一个rs运行。

Deployment功能及使用

1.Deployment功能

1、创建ReplicaSet和Pod

2、滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）

3、平滑地扩容和缩容

4、暂停和继续Deployment

2.Deployment资源清单文件编写技巧

apiVersion: apps/v1       #deployment对应的api版本

kind: Deployment         #创建的资源是deployment

metadata:

  name: nginx-deployment        #deployment的名字

  labels:

    app: nginx

spec:

  replicas: 3       #deployment管理的pod副本数

  selector:         #标签选择器

    matchLabels:        # matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:       #定义容器的属性

      containers:

      - name: nginx

        image: nginx:1.14.2

        ports:

        - containerPort: 80     #容器里的应用的端口

3.Deployment管理pod：扩容、缩容、滚动更新、回滚

查看deployment

kubectl get deploy

查看raplicaset

kubectl get rs

扩容及缩容

修改对应的yaml文件中的replicas的数量

[root@hd1.com ~]# vim deploy-demo.yaml

直接修改replicas数量

spec:

replicas: 3

修改之后保存退出，执行即可

[root@hd1.com ~]# kubectl apply -f deploy-demo.yaml

滚动更新

修改对应的yaml文件中的image信息，后执行

containers:

- name: nginx

image: nginx:1.14.2

[root@hd1.com ~]# kubectl get rs

显示如下：

myapp-v1-67fd9fc9c8 0 0 0 27m

myapp-v1-75fb478d6c 2 2 2 79s

#上面可以看到rs有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚

回滚

#查看myapp-v1这个控制器的历史版本

[root@hd1.com ~]# kubectl rollout history deployment myapp-v1

deployment.apps/myapp-v1

REVISION CHANGE-CAUSE

1 <none>

2 <none>

#使用命令回滚

[root@hd1.com ~]# kubectl rollout undo deployment myapp-v1 --to-revision=1

deployment.apps/myapp-v1 rolled back

#在查看历史版本，

[root@hd1.com ~]# kubectl rollout history deployment myapp-v1

deployment.apps/myapp-v1

REVISION CHANGE-CAUSE

2 <none>

3 <none>

4.自定义滚动更新策略

maxSurge和maxUnavailable用来控制滚动更新的更新策略

按数值

1. maxUnavailable: [0, 副本数]

2. maxSurge: [0, 副本数]

注意：两者不能同时为0。

按比例

1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；

2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；

注意：两者不能同时为0。

建议配置

1. maxUnavailable == 0

2. maxSurge == 1

这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：

1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。

总结：

maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；

maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

更新策略知识详解

maxSurge：指定在升级时，最大可以创建多少个pod。这个值可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，也就是说，新旧pod的总量不能超过130%。简单来讲，就是在滚动升级时，会先启动30%的新的pod。然后开始杀掉旧的pod，每当一个旧的pod被杀掉，一个新的pod的会被启动，始终保持总量不超过130%，直至更新完成。需要说明的是，当maxUnavailable为0时，maxSurge的值不能为0。

maxUnavailable：指定在升级时，最大不可用的pods的值。可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，最少可用的Pod为70%,也就是说，在滚动升级的时候，会先杀掉30%旧的pod，然后开始启动新pod。当一个新的Pod被创建，一个旧的Pod就会被销毁。始终保持可用的pod在总量的70%，直至升级完成。需要说明的是，当maxSurge为0时，maxUnavailable的值不能为0