当前位置:   article > 正文

Kubernetes控制器 —— Replicaset、Deployment_replicaset和deployment

replicaset和deployment

目录

一、Replicaset、Deployment控制器概念

1.Replicaset概述

2.Deployment控制器概念

二、Deployment资源清单文件编写技巧

三、Deployment使用案例:创建web站点

四、Deployment管理pod:扩容、缩容、滚动更新、回滚

自定义滚动更新策略


一、Replicaset、Deployment控制器概念

1.Replicaset概述

ReplicaSet是kubernetes中的一种副本控制器,简称rs,主要作用是控制由其管理的pod,使pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的Pod能够在集群中正常运行,它会持续监听这些Pod的运行状态,在Pod发生故障时重启pod,pod数量减少时重新运行新的 Pod副本。官方推荐不要直接使用ReplicaSet,用Deployments取而代之,Deployments是比ReplicaSet更高级的概念,它会管理ReplicaSet并提供很多其它有用的特性,最重要的是Deployments支持声明式更新,声明式更新的好处是不会丢失历史变更。所以Deployment控制器不直接管理Pod对象,而是由 Deployment 管理ReplicaSet,再由ReplicaSet负责管理Pod对象。

2.Deployment控制器概念

1.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运行。

rs v1控制三个pod,删除一个pod,在rs v2上重新建立一个,依次类推,直到全部都是由rs v2控制,如果rs v2有问题,还可以回滚,Deployment是建构在rs之上的,多个rs组成一个Deployment,但是只有一个rs处于活跃状态.

2.Deployment工作原理:如何管理rs和pod?

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

互动:什么叫做更新节奏和更新逻辑呢?

比如说Deployment控制5个pod副本,pod的期望值是5个,但是升级的时候需要额外多几个pod,那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本;比方说能多一个,但是不能少,那么升级的时候就是先增加一个,再删除一个,增加一个删除一个,始终保持pod副本数是5个;还有一种情况,最多允许多一个,最少允许少一个,也就是最多6个,最少4个,第一次加一个,删除两个,第二次加两个,删除两个,依次类推,可以自己控制更新方式,这种滚动更新需要加readinessProbe和livenessProbe探测,确保pod中容器里的应用都正常启动了才删除之前的pod。

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

通过Deployment对象,你可以轻松的做到以下事情:

1、创建ReplicaSet和Pod

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

3、平滑地扩容和缩容

4、暂停和继续Deployment

二、Deployment资源清单文件编写技巧

举例:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment

  labels:

    app: nginx

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx:1.14.2

        ports:

        - containerPort: 80

#查看Deployment资源对象由哪几部分组成

[root@hd1 ~]# kubectl explain deployment

FIELDS:

   apiVersion   

   kind    

   metadata  

   spec    

#查看Deployment下的spec字段

[root@hd1.com ~]# kubectl explain deployment.spec

FIELDS:

    replicas    <integer>  #副本数

    revisionHistoryLimit    <integer> #保留的历史版本,默认是10

    selector    <Object> -required- #标签选择器,选择它关联的pod

    strategy    <Object>     #更新策略

    template    <Object> -required  #定义的pod模板

#查看Deployment下的spec.strategy字段

[root@hd1.com ~]# kubectl explain deploy.spec.strategy

FIELDS:

   rollingUpdate    <Object>

   type <string>

#支持两种更新,Recreate和RollingUpdate

#Recreate是重建式更新,删除一个更新一个

#RollingUpdate滚动更新,定义滚动更新方式,也就是pod能多几个,少几个

#查看Deployment下的spec.strategy.rollingUpdate字段

[root@hd1.com ~]# kubectl explain deploy.spec.strategy.rollingUpdate

FIELDS:

   maxSurge <string>

#我们更新的过程当中最多允许超出的指定的目标副本数有几个;它有两种取值方式,第一种直接给定数量,第二种根据百分比,百分比表示原本是5个,最多可以超出20%,那就允许多一个,最多可以超过40%,那就允许多两个

   maxUnavailable   <string>

#最多允许几个不可用,假设有5个副本,最多一个不可用,就表示最少有4个可用

#template为定义Pod的模板,Deployment通过模板创建Pod

[root@hd1.com ~]# kubectl explain deploy.spec.template

FIELDS:

   metadata <Object>  #定义模板的名字

   spec <Object> 

deployment.spec.template为Pod定义的模板,和Pod定义不太一样,template中不包含apiVersion和Kind属性,要求必须有metadata。deployment.spec.template.spec为容器的属性信息,其他定义内容和Pod一致。

#查看Deployment下的spec.template.spec字段

[root@hd1.com ~]# kubectl explain deploy.spec.template.spec

FIELDS:

   activeDeadlineSeconds   <integer>

#activeDeadlineSeconds表示Pod 可以运行的最长时间,达到设置的该值后,Pod 会自动停止。

   affinity <Object>  #定义亲和性,跟直接创建pod时候定义亲和性类似

   automountServiceAccountToken<boolean> #身份认证相关的

   containers   <[]Object> -required- #定义容器属性

   dnsConfig    <Object>  #设置Pod的DNS

三、Deployment使用案例:创建web站点

deployment是一个三级结构,deployment管理replicaset,replicaset管理pod,

例子:用deployment创建一个pod

#把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上传到hd2.comhd3.com上,手动解压:

[root@hd2.com ~]# docker load -i myapp-blue-v1.tar.gz

[root@hd3.com ~]# docker load -i myapp-blue-v1.tar.gz

[root@hd2.com ~]# docker load -i myapp-blue-v2.tar.gz

[root@hd3.com ~]# docker load -i myapp-blue-v2.tar.gz

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

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-v1

spec:

  replicas: 2

  selector:

   matchLabels:

    app: myapp

    version: v1

  template:

   metadata:

    labels:

     app: myapp

     version: v1

   spec:

    containers:

    - name: myapp

     image: janakiramm/myapp:v1

     imagePullPolicy: IfNotPresent

     ports:

     - containerPort: 80

更新资源清单文件:

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

#kubectl apply:表示声明式的定义,既可以创建资源,也可以动态更新资源

查看deploy状态:

   [root@hd1 ~]# kubectl get deploy

#创建的控制器名字是myapp-v1

1.NAME :列出名称空间中deployment的名称。

2.READY:显示deployment有多少副本数。它遵循ready/desired的模式。

3.UP-TO-DATE: 显示已更新到所需状态的副本数。

4.AVAILABLE: 显示你的可以使用多少个应用程序副本。

5.AGE :显示应用程序已运行的时间。

kubectl get rs 显示如下:

#创建deploy的时候也会创建一个rs(replicaset),67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值

1.NAME: 列出名称空间中ReplicaSet资源

2DESIRED:显示应用程序的所需副本数,这些副本数是在创建时定义的。这是所需的状态。

3.CURRENT: 显示当前正在运行多少个副本。

4.READY: 显示你的用户可以使用多少个应用程序副本。

5.AGE :显示应用程序已运行的时间。

请注意,ReplicaSet的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是随机生成的

kubectl get pods

显示如下:

[root@hd1.com ~]# kubectl get pods -o wide | grep myapp

myapp-v1-67fd9fc9c8-fcprr   1/1   Running  0    10.244.187.78   hd3.com  

myapp-v1-67fd9fc9c8-hw4f9  1/1   Running   0   10.244.209.136  hd2.com  

#请求刚才创建的pod资源

[root@hd1.com ~]# curl 10.244.187.78

      background-color: blue;

[root@hd1.com ~]# curl 10.244.209.136

      background-color: blue;

#资源清单文件详细解读

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

kind: Deployment    #创建的资源是deployment

metadata:

  name: myapp-v1   #deployment的名字

spec:

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

  selector:       #标签选择器

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

    app: myapp

    version: v1

  template:

   metadata:

    labels:

     app: myapp

     version: v1

   spec:   #定义容器的属性

    containers: 

    - name: myapp

      image: janakiramm/myapp:v1 #容器使用的镜像

      imagePullPolicy: IfNotPresent  #镜像拉取策略

      ports:

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

四、Deployment管理pod:扩容、缩容、滚动更新、回滚

#通过deployment管理应用,实现扩容,把副本数变成3

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

直接修改replicas数量,如下,变成3

spec:

  replicas: 3

修改之后保存退出,执行

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

注意:apply不同于create,apply可以执行多次;create执行一次,再执行就会报错复。

kubectl get pods

显示如下:

NAME                         READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr   1/1     Running   0          15m

myapp-v1-67fd9fc9c8-h9js5   1/1     Running   0          11s

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          17m

#上面可以看到pod副本数变成了3个

#查看myapp-v1这个控制器的详细信息

[root@hd1.com ~]# kubectl describe deploy myapp-v1

#通过deployment管理应用,实现缩容,把副本数变成2

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

直接修改replicas数量,如下,变成2

spec:

  replicas: 2

修改之后保存退出,执行

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

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

NAME                         READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr    1/1     Running   0          18m

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          20m

还可以通过kubectl edit deploy myapp-v1 实现自动扩容或缩容

[root@hd1 deploy]# kubectl edit deploy myapp-v1

#通过deployment管理应用,实现滚动更新

在一个终端窗口执行如下:

[root@hd1.com ~]# kubectl get pods -l app=myapp -w

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr   1/1     Running   0          19m

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          22m

打开一个新的终端窗口更改镜像版本,按如下操作:

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

把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2

保存退出,执行

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

再回到刚才执行监测kubectl get pods -l app=myapp -w的那个窗口,可以看到信息如下:

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr   1/1     Running   0          23m

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          26m

myapp-v1-75fb478d6c-fskpq   0/1     Pending   0          0s

myapp-v1-75fb478d6c-fskpq   0/1     Pending   0          0s

myapp-v1-75fb478d6c-fskpq   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-fskpq   0/1     ContainerCreating   0          1s

myapp-v1-75fb478d6c-fskpq   1/1     Running             0          4s

myapp-v1-67fd9fc9c8-fcprr   1/1     Terminating         0          24m

myapp-v1-75fb478d6c-x8stq   0/1     Pending             0          0s

myapp-v1-75fb478d6c-x8stq   0/1     Pending             0          0s

myapp-v1-75fb478d6c-x8stq   0/1     ContainerCreating   0          0s

myapp-v1-67fd9fc9c8-fcprr   1/1     Terminating         0          24m

myapp-v1-75fb478d6c-x8stq   0/1     ContainerCreating   0          1s

myapp-v1-67fd9fc9c8-fcprr   0/1     Terminating         0          24m

myapp-v1-75fb478d6c-x8stq   1/1     Running             0          1s

myapp-v1-67fd9fc9c8-hw4f9   1/1     Terminating         0          26m

myapp-v1-67fd9fc9c8-hw4f9   1/1     Terminating         0          26m

myapp-v1-67fd9fc9c8-hw4f9   0/1     Terminating         0          26m

myapp-v1-67fd9fc9c8-hw4f9   0/1     Terminating         0          26m

myapp-v1-67fd9fc9c8-hw4f9   0/1     Terminating         0          26m

myapp-v1-67fd9fc9c8-fcprr   0/1     Terminating         0          24m

myapp-v1-67fd9fc9c8-fcprr   0/1     Terminating         0          24m

pending表示正在进行调度,ContainerCreating表示正在创建一个pod,running表示运行一个pod,running起来一个pod之后再Terminating(停掉)一个pod,以此类推,直到所有pod完成滚动升级

[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>

自定义滚动更新策略

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:和期望的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快。

自定义策略:

修改更新策略:maxUnavailable=1,maxSurge=1

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

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-v1

spec:

  replicas: 3

  selector:

   matchLabels:

    app: myapp

    version: v1

  strategy:

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 1

  template:

   metadata:

    labels:

     app: myapp

     version: v1

   spec:

    containers:

    - name: myapp

      image: janakiramm/myapp:v1

      imagePullPolicy: IfNotPresent

      ports:

      - containerPort: 80

执行上面的yaml文件

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

查看myapp-v1这个控制器的详细信息

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

显示如下:

RollingUpdateStrategy:  1 max unavailable, 1 max surge

总结:deployment 副本控制器,功能是控制无状态协议的应用的pod的,http协议 就是无状态,ftp协议就是无状态的

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/凡人多烦事01/article/detail/189864
推荐阅读
相关标签
  

闽ICP备14008679号