Deployment控制器:概念、原理解读

Deployment官方文档:
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

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

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

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资源清单文件编写技巧

  • 查看Deployment资源对象由哪几部分组成
[root@master1 ~]# kubectl explain deployment
KIND:     Deployment
VERSION:  apps/v1
DESCRIPTION:Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:apiVersion   <string>  #该资源使用的api版本kind    <string>            #创建的资源是什么?metadata <Object>       #元数据,包括资源的名字和名称空间spec   <Object>           #定义容器的status   <Object>       #状态,不可以修改
  • 查看Deployment下的spec字段
[root@master1 ~]# kubectl explain deployment.spec
KIND:     Deployment
VERSION:  apps/v1
RESOURCE: spec <Object>
DESCRIPTION:Specification of the desired behavior of the Deployment.DeploymentSpec is the specification of the desired behavior of theDeployment.
FIELDS:minReadySeconds  <integer>
#Kubernetes在等待设置的时间后才进行升级
#如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了
paused  <boolean>  #暂停,当我们更新的时候创建pod先暂停,不是立即更新progressDeadlineSeconds   <integer>`# k8s 在升级过程中有可能由于各种原因升级卡住(这个时候还没有明确的升级失败),比如在拉取被墙的镜像,权限不够等错误。那么这个时候就需要有个 deadline ,在 deadline 之内如果还卡着,那么就上报这个情况,这个时候这个 Deployment 状态就被标记为 False,并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的操作。完全由用户进行控制。replicas  <integer>  #副本数revisionHistoryLimit   <integer> #保留的历史版本,默认是10selector   <Object> -required- #标签选择器,选择它关联的podstrategy   <Object>     #更新策略template    <Object> -required  #定义的pod模板
  • 查看Deployment下的spec.strategy字段
[root@master1 ~]# kubectl explain deploy.spec.strategy
KIND:     Deployment
VERSION:  apps/v1
RESOURCE: strategy <Object>
DESCRIPTION:The deployment strategy to use to replace existing pods with new ones.DeploymentStrategy describes how to replace existing pods with new ones.
FIELDS:rollingUpdate    <Object>type  <string>Type of deployment. Can be "Recreate" or "RollingUpdate". Default isRollingUpdate.
#支持两种更新,Recreate和RollingUpdate
#Recreate是重建式更新,删除一个更新一个

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

  • 查看Deployment下的spec.strategy.rollingUpdate字段
[root@master1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate
KIND:     Deployment
VERSION:  apps/v1
RESOURCE: rollingUpdate <Object>
DESCRIPTION:Rolling update config params. Present only if DeploymentStrategyType =RollingUpdate.Spec to control the desired behavior of rolling update.
FIELDS:maxSurge <string>
#我们更新的过程当中最多允许超出的指定的目标副本数有几个;
它有两种取值方式,第一种直接给定数量,第二种根据百分比,百分比表示原本是5个,最多可以超出20%,那就允许多一个,最多可以超过40%,那就允许多两个maxUnavailable   <string>
#最多允许几个不可用
假设有5个副本,最多一个不可用,就表示最少有4个可用
  • 查看Deployment下的spec.template字段
    template为定义Pod的模板,Deployment通过模板创建Pod
[root@xmaster1 ~]# kubectl explain deploy.spec.template
KIND:     Deployment
VERSION:  apps/v1
RESOURCE: template <Object>
DESCRIPTION:Template describes the pods that will be created.PodTemplateSpec describes the data a pod should have when created from a 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@master1 ~]# kubectl explain deploy.spec.template.spec
KIND:     Deployment
VERSION:  apps/v1
RESOURCE: spec <Object>
DESCRIPTION:Specification of the desired behavior of the pod. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusPodSpec is a description of a pod.
FIELDS:activeDeadlineSeconds    <integer>
#activeDeadlineSeconds表示Pod 可以运行的最长时间,达到设置的该值后,Pod 会自动停止。affinity <Object>  #定义亲和性,跟直接创建pod时候定义亲和性类似automountServiceAccountToken <boolean> #身份认证相关的containers  <[]Object> -required- #定义容器属性dnsConfig    <Object>  #设置Pod的DNS
dnsConfig:nameservers:- 192.xxx.xxx.6searches:- xianchao.svc.cluster.local- my.dns.search.xianchaodnsPolicy <string> # dnsPolicy决定Pod 内预设的DNS 配置策略None 无任何策略:使用自定义的策略
Default 默认:使用宿主机的dns配置,/etc/resolv.conf
ClusterFirst 集群DNS优先,与 Default 相反,会预先使用 kube-dns (或 CoreDNS ) 的信息当预设置参数写入到该 Pod 内的DNS配置。
ClusterFirstWithHostNet 集群 DNS 优先,并伴随着使用宿主机网络:同时使用 hostNetwork 与 kube-dns 作为 Pod 预设 DNS 配置。enableServiceLinks <boolean>ephemeralContainers  <[]Object> #定义临时容器
临时容器与其他容器的不同之处在于,它们缺少对资源或执行的保证,并且永远不会自动重启,因此不适用于构建应用程序。临时容器使用与常规容器相同的 ContainerSpec 段进行描述,但许多字段是不相容且不允许的。临时容器没有端口配置,因此像 ports,livenessProbe,readinessProbe 这样的字段是不允许的。Pod 资源分配是不可变的,因此 resources 配置是不允许的。临时容器用途:
当由于容器崩溃或容器镜像不包含调试应用程序而导致 kubectl exec 无用时,临时容器对于交互式故障排查很有用。hostAliases   <[]Object> #在pod中增加域名解析的hostAliases:– ip: "10.1.2.2"hostnames:– "mc.local"– "rabbitmq.local"– ip: "10.1.2.3"hostnames:– "redis.local"– "mq.local"hostIPC  <boolean> #使用主机IPChostNetwork <boolean>  #是否使用宿主机的网络hostPID <boolean> #可以设置容器里是否可以看到宿主机上的进程。True可以hostname    <string>imagePullSecrets  <[]Object>initContainers  <[]Object> #定义初始化容器nodeName   <string>  #定义pod调度到具体哪个节点上nodeSelector    <map[string]string> #定义节点选择器overhead  <map[string]string> #overhead是1.16引入的字段,在没有引入 Overhead 之前,只要一个节点的资源可用量大于等于 Pod 的 requests 时,这个 Pod 就可以被调度到这个节点上。引入 Overhead 之后,只有节点的资源可用量大于等于 Overhead 加上 requests 的和时才能被调度上来。preemptionPolicy    <string>priority  <integer>priorityClassName    <string>readinessGates    <[]Object> restartPolicy  <string>   #Pod重启策略runtimeClassName   <string>schedulerName <string>securityContext   <Object> #是否开启特权模式serviceAccount  <string>serviceAccountName    <string>setHostnameAsFQDN <boolean>shareProcessNamespace    <boolean>subdomain    <string>terminationGracePeriodSeconds <integer>
#在真正删除容器之前,K8S会先发终止信号(kill -15 {pid})给容器,默认30stolerations   <[]Object>  #定义容忍度topologySpreadConstraints   <[]Objectvolumes <[]Object>  #挂载存储卷

Deployment使用案例:创建一个web站点

[root@master1 deployment]# cat deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v1
spec:replicas: 2selector:matchLabels:app: myappversion: v1template:metadata:labels:app: myappversion: v1spec:containers:- name: myappimage: janakiramm/myapp:v1imagePullPolicy: IfNotPresentports:- containerPort: 80   更新资源清单文件:
[root@master1 deployment]# kubectl apply -f deploy-demo.yaml
deployment.apps/myapp-v1 created查看deploy状态:
[root@master1 deployment]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/2     2            2           95s
#创建的控制器名字是myapp-v1
1.NAME :列出名称空间中deployment的名称。
2.READY:显示deployment有多少副本数。它遵循ready/desired的模式。
3.UP-TO-DATE: 显示已更新到所需状态的副本数。
4.AVAILABLE: 显示你的可以使用多少个应用程序副本。
5.AGE :显示应用程序已运行的时间。[root@master1 deployment]# kubectl get rs
NAME                  DESIRED   CURRENT   READY   AGE
myapp-v1-67fd9fc9c8   2         2         2       3m2s
[root@master1 deployment]# kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   0          3m6s
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   0          3m6s
#创建deploy的时候也会创建一个rs(replicaset),67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值
1.NAME: 列出名称空间中ReplicaSet资源
2DESIRED:显示应用程序的所需副本数,这些副本数是在创建时定义的。这是所需的状态。
3.CURRENT: 显示当前正在运行多少个副本。
4.READY: 显示你的用户可以使用多少个应用程序副本。
5.AGE :显示应用程序已运行的时间。

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

  • 请求刚才创建的pod资源
[root@master1 deployment]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   0          4m49s   10.1.104.40    node2   <none>           <none>
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   0          4m49s   10.1.166.177   node1   <none>           <none>
[root@master1 deployment]# curl 10.1.104.40background-color: blue;[root@master1 deployment]# curl 10.1.166.177background-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: myappversion: v1template:metadata:labels:app: myappversion: v1spec:   #定义容器的属性containers:  - name: myappimage: janakiramm/myapp:v1 #容器使用的镜像imagePullPolicy: IfNotPresent  #镜像拉取策略ports:- containerPort: 80     #容器里的应用的端口

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

  • 通过deployment管理应用,实现扩容,把副本数变成3
[root@master1 deployment]# vim deploy-demo.yaml
[root@master1 deployment]# cat deploy-demo.yaml | grep replicasreplicas: 3
[root@master1 deployment]# kubectl apply -f deploy-demo.yaml
deployment.apps/myapp-v1 configured注意:apply不同于create,apply可以执行多次;create执行一次,再执行就会报错复。[root@master1 deployment]# kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-mq49p   1/1     Running   0          50s
  • 查看myapp-v1这个控制器的详细信息
[root@master1 deployment]# kubectl describe  deploy myapp-v1
Name:                   myapp-v1
Namespace:              default
CreationTimestamp:      Tue, 02 Aug 2022 20:36:22 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=myapp,version=v1
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:Labels:  app=myappversion=v1Containers:myapp:Image:        janakiramm/myapp:v1Port:         80/TCPHost Port:    0/TCPEnvironment:  <none>Mounts:       <none>Volumes:        <none>
Conditions:Type           Status  Reason----           ------  ------Progressing    True    NewReplicaSetAvailableAvailable      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   myapp-v1-67fd9fc9c8 (3/3 replicas created)
Events:Type    Reason             Age   From                   Message----    ------             ----  ----                   -------Normal  ScalingReplicaSet  111s  deployment-controller  Scaled up replica set myapp-v1-67fd9fc9c8 to 3

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

[root@master1 deployment]# kubectl edit deploy myapp-v1
deployment.apps/myapp-v1 edited
[root@master1 deployment]# kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   1          19h
[root@master1 deployment]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/2     2            2           19h
  • 通过deployment管理应用,实现滚动更新
    在一个终端窗口执行如下:
[root@master1 ~]# kubectl get pods -l app=myapp -w
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   1          19h

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

[root@master1 deployment]# vim deploy-demo.yaml
把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2
保存退出,执行
[root@master1 deployment]# kubectl apply -f deploy-demo.yaml
deployment.apps/myapp-v1 configured

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

[root@master1 ~]# kubectl get pods -l app=myapp -w
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-67fd9fc9c8-d5br2   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-lw9cb   1/1     Running   1          19h
myapp-v1-67fd9fc9c8-twbjz   0/1     Pending   0          0s
myapp-v1-67fd9fc9c8-twbjz   0/1     Pending   0          0s
myapp-v1-75fb478d6c-ndvbz   0/1     Pending   0          0s
myapp-v1-75fb478d6c-ndvbz   0/1     Pending   0          0s
myapp-v1-67fd9fc9c8-twbjz   0/1     ContainerCreating   0          0s
myapp-v1-75fb478d6c-ndvbz   0/1     ContainerCreating   0          0s
myapp-v1-75fb478d6c-ndvbz   0/1     ContainerCreating   0          1s
myapp-v1-67fd9fc9c8-twbjz   0/1     ContainerCreating   0          2s
myapp-v1-67fd9fc9c8-twbjz   1/1     Running             0          3s
myapp-v1-75fb478d6c-ndvbz   1/1     Running             0          4s
myapp-v1-67fd9fc9c8-twbjz   1/1     Terminating         0          4s
myapp-v1-75fb478d6c-hzlvq   0/1     Pending             0          0s
myapp-v1-75fb478d6c-hzlvq   0/1     Pending             0          0s
myapp-v1-75fb478d6c-hzlvq   0/1     ContainerCreating   0          0s
myapp-v1-67fd9fc9c8-twbjz   1/1     Terminating         0          5s
myapp-v1-75fb478d6c-hzlvq   0/1     ContainerCreating   0          1s
myapp-v1-75fb478d6c-hzlvq   1/1     Running             0          1s
myapp-v1-67fd9fc9c8-d5br2   1/1     Terminating         1          19h
myapp-v1-75fb478d6c-lm4gh   0/1     Pending             0          0s
myapp-v1-75fb478d6c-lm4gh   0/1     Pending             0          0s
myapp-v1-75fb478d6c-lm4gh   0/1     ContainerCreating   0          0s
myapp-v1-67fd9fc9c8-twbjz   0/1     Terminating         0          6s
myapp-v1-67fd9fc9c8-d5br2   1/1     Terminating         1          19h
myapp-v1-75fb478d6c-lm4gh   0/1     ContainerCreating   0          1s
myapp-v1-67fd9fc9c8-d5br2   0/1     Terminating         1          19h
myapp-v1-75fb478d6c-lm4gh   1/1     Running             0          6s
myapp-v1-67fd9fc9c8-lw9cb   1/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-lw9cb   1/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-d5br2   0/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-d5br2   0/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-lw9cb   0/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-twbjz   0/1     Terminating         0          13s
myapp-v1-67fd9fc9c8-twbjz   0/1     Terminating         0          14s
myapp-v1-67fd9fc9c8-lw9cb   0/1     Terminating         1          19h
myapp-v1-67fd9fc9c8-lw9cb   0/1     Terminating         1          19h

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

在另外一个窗口执行

[root@master1 deployment]# kubectl get rs
NAME                  DESIRED   CURRENT   READY   AGE
myapp-v1-67fd9fc9c8   0         0         0       19h
myapp-v1-75fb478d6c   3         3         3       2m35s

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

  • 查看myapp-v1这个控制器的历史版本
[root@master1 deployment]# kubectl rollout history deployment myapp-v1
deployment.apps/myapp-v1
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
  • 回滚 到上一个版本
[root@master1 deployment]# kubectl rollout undo deployment myapp-v1 --to-revision=1
deployment.apps/myapp-v1 rolled back
[root@master1 deployment]# kubectl rollout history deployment myapp-v1
deployment.apps/myapp-v1
REVISION  CHANGE-CAUSE
2         <none>
3         <none>   # 这个之前刚开始创建pod时版本[root@master1 ~]# kubectl get pods -l app=myapp -w
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-75fb478d6c-hzlvq   1/1     Running   0          5m55s
myapp-v1-75fb478d6c-lm4gh   1/1     Running   0          5m54s
myapp-v1-75fb478d6c-ndvbz   1/1     Running   0          5m59s
myapp-v1-67fd9fc9c8-8kfxb   0/1     Pending   0          0s
myapp-v1-67fd9fc9c8-8kfxb   0/1     Pending   0          0s
myapp-v1-67fd9fc9c8-8kfxb   0/1     ContainerCreating   0          0s
myapp-v1-67fd9fc9c8-8kfxb   0/1     ContainerCreating   0          2s
myapp-v1-67fd9fc9c8-8kfxb   1/1     Running             0          2s
myapp-v1-75fb478d6c-lm4gh   1/1     Terminating         0          6m
myapp-v1-67fd9fc9c8-5nc87   0/1     Pending             0          0s
myapp-v1-67fd9fc9c8-5nc87   0/1     Pending             0          0s
myapp-v1-67fd9fc9c8-5nc87   0/1     ContainerCreating   0          0s
myapp-v1-75fb478d6c-lm4gh   1/1     Terminating         0          6m1s
myapp-v1-67fd9fc9c8-5nc87   0/1     ContainerCreating   0          1s
myapp-v1-75fb478d6c-lm4gh   0/1     Terminating         0          6m1s
myapp-v1-67fd9fc9c8-5nc87   1/1     Running             0          2s
myapp-v1-75fb478d6c-hzlvq   1/1     Terminating         0          6m3s
myapp-v1-67fd9fc9c8-952pj   0/1     Pending             0          0s
myapp-v1-67fd9fc9c8-952pj   0/1     Pending             0          0s
myapp-v1-67fd9fc9c8-952pj   0/1     ContainerCreating   0          0s
myapp-v1-75fb478d6c-hzlvq   1/1     Terminating         0          6m3s
myapp-v1-67fd9fc9c8-952pj   0/1     ContainerCreating   0          1s
myapp-v1-75fb478d6c-hzlvq   0/1     Terminating         0          6m4s
myapp-v1-67fd9fc9c8-952pj   1/1     Running             0          1s
myapp-v1-75fb478d6c-ndvbz   1/1     Terminating         0          6m9s
myapp-v1-75fb478d6c-ndvbz   1/1     Terminating         0          6m9s
myapp-v1-75fb478d6c-ndvbz   0/1     Terminating         0          6m9s
myapp-v1-75fb478d6c-hzlvq   0/1     Terminating         0          6m7s
myapp-v1-75fb478d6c-hzlvq   0/1     Terminating         0          6m7s
myapp-v1-75fb478d6c-lm4gh   0/1     Terminating         0          6m8s
myapp-v1-75fb478d6c-lm4gh   0/1     Terminating         0          6m8s
myapp-v1-75fb478d6c-ndvbz   0/1     Terminating         0          6m21s
myapp-v1-75fb478d6c-ndvbz   0/1     Terminating         0          6m21s
[root@master1 deployment]# kubectl get rs -o wide
NAME                  DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES                SELECTOR
myapp-v1-67fd9fc9c8   3         3         3       19h     myapp        janakiramm/myapp:v1   app=myapp,pod-template-hash=67fd9fc9c8,version=v1
myapp-v1-75fb478d6c   0         0         0       8m24s   myapp        janakiramm/myapp:v2   app=myapp,pod-template-hash=75fb478d6c,version=v1

自定义滚动更新策略

maxSurge和maxUnavailable用来控制滚动更新的更新策略
取值范围
数值

  1. maxUnavailable: [0, 副本数]
  2. maxSurge: [0, 副本数]
    注意:两者不能同时为0。
    比例
  3. maxUnavailable: [0%, 100%] 向下取整,比如10个副本,5%的话==0.5个,但计算按照0个;
  4. maxSurge: [0%, 100%] 向上取整,比如10个副本,5%的话==0.5个,但计算按照1个;
    注意:两者不能同时为0。
    建议配置
  5. maxUnavailable == 0
  6. maxSurge == 1
    这是我们生产环境提供给用户的默认配置。即“一上一下,先上后下”最平滑原则:
    1个新版本pod ready(结合readiness)后,才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳,但也有缺点,就是“太慢”了。

总结:
maxUnavailable:和期望的副本数比,不可用副本数最大比例(或最大值),这个值越小,越能保证服务稳定,更新越平滑;
maxSurge:和期望的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快。

自定义策略:

  • 修改更新策略:maxUnavailable=1,maxSurge=1
[root@master1 deployment]# kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}'
deployment.apps/myapp-v1 patched
[root@master1 deployment]# kubectl describe deployment myapp-v1 | grep RollingUpdateStrategy
RollingUpdateStrategy:  1 max unavailable, 1 max surge

上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge
这个rollingUpdate更新策略变成了刚才设定的,因为我们设定的pod副本数是3,1和1表示最少不能少于2个pod,最多不能超过4个pod
这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的

Deployment资源清单详解

apiVersion: apps/v1  版本
kind: Deployment   类型
metadata:   元数据name: portal  控制器名字namespace: ms   在哪个名称空间下
spec:    详细数据replicas: 1   副本数(创建pod的数量)selector:  选择器:控制器通过选择器控制哪些podmatchLabels:   标签选择器project: ms   标签值app: portaltemplate:   创建pod资源的模版metadata:   元数据labels:   给pod打标签project: ms    标签值app: portalspec:   详细信息containers:         pod里面创建的容器- name: portal      容器的名字image:  xianchao/portal:v1    容器的镜像imagePullPolicy: Always    镜像拉去方式ports:   容器的一些端口设置- protocol: TCP   端口协议containerPort: 8080    容器开放的端口resources:  #资源配额  limits:  #资源限制,最多可用的cpu和内存cpu: 1   #或者是1000m(1个cpu=1000m)memory: 1Girequests: #最少需要多少资源才可以运行Podcpu: 0.5memory: 1GireadinessProbe: 就绪性探测 tcpSocket: 基于tcp端口探测port: 8080  探测8080端口initialDelaySeconds: 60 pod启动后60s后才开始探测periodSeconds: 10  探测的间隔为10slivenessProbe:  存活性探测tcpSocket: 基于tcp端口探测port: 8080 探测8080端口initialDelaySeconds: 60  periodSeconds: 10livenessProbe: #存活性探测
#用于判断容器是否存活,即Pod是否为running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的重启策略是否重启。如果一个容器不包含LivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。tcpSocket: port: 8080   #检测8080端口是否存在initialDelaySeconds: 60  #Pod启动60s执行第一次检查
periodSeconds: 10    #第一次检查后每隔10s检查一次readinessProbe:  #就绪性探测
有时候应用程序可能暂时无法接受请求,比如Pod已经Running了,但是容器内应用程序尚未启动成功,在这种情况下,如果没有ReadinessProbe,则Kubernetes认为它可以处理请求了,然而此时,我们知道程序还没启动成功是不能接收用户请求的,所以不希望kubernetes把请求调度给它,则使用ReadinessProbe探针。ReadinessProbe和livenessProbe可以使用相同探测方式,只是对Pod的处置方式不同,ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除,而livenessProbe则Kill容器并根据Pod的重启策略来决定作出对应的措施。ReadinessProbe探针探测容器是否已准备就绪,如果未准备就绪则kubernetes不会将流量转发给此Pod。tcpSocket:port: 8080initialDelaySeconds: 60periodSeconds: 10
#在Pod运行过程中,K8S仍然会每隔10s检测8080端口

k8s之Deployment篇相关推荐

  1. K8S实战基础篇:一文带你深入了解K8S实战部署SpringBoot项目

    K8S实战基础篇:一文带你深入了解K8S实战部署SpringBoot项目 1.前言 2.简介 2.1.为什么写这篇文章 2.2.需求描述 2.3.需求分析 3. 部署实战 3.1 环境准备 3.2 i ...

  2. 【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权(下)

    目录 一.常见角色(role)授权的案例 1.1 允许读取核心 API 组的 Pod 资源 1.2 允许读写 apps API 组中的 deployment 资源 1.3 允许读取 Pod 以及读写 ...

  3. 【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权(上)

    目录 一.k8s 安全管理:认证.授权.准入控制概述 1.1 认证 认证基本介绍 授权基本介绍 准入控制基本介绍 为什么需要准入控制器呢? k8s 客户端访问 apiserver 的几种认证方式 ku ...

  4. 4、k8s之deployment

    k8s之deployment Deployment部署应用 手动创建一个deployment deploy扩容 通过yaml文件创建 Deployment自愈&故障转移能力 升级部署方式介绍 ...

  5. k8s控制器Deployment使用详解

    前言 在上一篇我们聊了k8s中各种控制器的使用,本篇将以控制器中比较常用的一种控制器Deployment 进行详细的说明. 一.Deployment 简介 为了更好解决服务编排的问题,kubernet ...

  6. 【云原生|K8s系列特别篇】:一文速通实战Helm管理工具

    本期文章是K8s特别篇,主要是速通学习Helm之简介.仓库.实践应用等.通过本期文章:我们将学习Helm的基础知识.简介.仓库.实践应用等 在前期的文章中,已经介绍了一些云原生入门的知识及简单实战,感 ...

  7. k8s创建Deployment报错:missing required field “selector“ in io.k8s.api.apps.v1.DeploymentSpec

    报错类型: [root@master ~]# kubectl create -f lzb-test.yaml error: error validating "lzb-test.yaml&q ...

  8. k8s创建Deployment报错:no matches for kind “Deployment“ in version “extensions/v1beta1“

    报错类型: [root@master ~]# kubectl create -f lzb-test.yaml error: unable to recognize "lzb-test.yam ...

  9. k8s、Deployment多副本资源详解、SERVICE通信、案例一nginx端口暴漏、案例二tomcat端口暴漏、案例三jenkins端口暴漏

    文章目录 案例一 创建SERVICE 案例一nginx端口暴露 案例二tomcat端口暴露 案例三jenkins端口暴漏 使用yaml创建Deployment k8s deployment资源创建流程 ...

最新文章

  1. JQuery 基础 || 目前 jQuery 有三个大版本||JQuery快速入门
  2. Java中对象的实例化顺序
  3. Android 从AndroidManifest获取meta-data
  4. C#学习日志三(流程控制语句)
  5. vsftpd出现500 OOPS: cannot change directory的解决办法
  6. 软路由ros(MIKROTIK)安装教程:[3]ROS注册
  7. 创业12年 最野蛮的屌丝创业者
  8. libmodbus使用
  9. 关于idea的IdeaVim插件导致的光标问题(insert键)
  10. 了解DNS劫持及dns劫持修复方法
  11. 【探花交友】阿里云OSS、百度人脸识别
  12. 记一次服务器被木马注入攻击
  13. Android手游外挂入侵----寓攻于守,方能破敌
  14. 标准化和归一化 超全详解
  15. 洛谷 P4726 【模板】多项式指数函数
  16. ubuntu16安装python3.6
  17. WebGL简易教程(一):第一个简单示例
  18. 人工智能必备知识——同济大学线性代数第四章向量组的线性相关性
  19. 【C语言】指针:输入某一年的第几天,计算并输出它是这一年的第几月第几天
  20. 人类产生负面情绪 根源在贪嗔痴三毒

热门文章

  1. 5728系统刷机步骤
  2. Painter(微信小程序分享卡片)
  3. java中*和**的作用 以及 /和/*和/**的区别
  4. 人工智能所需高等数学知识大全(收藏版)
  5. am4针脚定义_AMD新一代处理器改用AM4插槽:针脚数提升40%,140W供电
  6. 戴尔电脑装系统用u盘启动及bios设置
  7. 第25讲:Python字符串的字符转换、字符串劈分、字符串合并
  8. 保险代理机构管理规定
  9. 计算机中总评等级怎么算,总评成绩是按什么算的~
  10. 音视频前沿:新一代 AV1 视频标准究竟是怎样一种存在?