k8s之Deployment篇

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 the
     Deployment.
FIELDS:
    minReadySeconds	<integer>
#Kubernetes在等待设置的时间后才进行升级
#如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
paused	<boolean>  #暂停，当我们更新的时候创建pod先暂停，不是立即更新
    progressDeadlineSeconds	<integer>`
    # k8s 在升级过程中有可能由于各种原因升级卡住（这个时候还没有明确的升级失败），比如在拉取被墙的镜像，权限不够等错误。那么这个时候就需要有个 deadline ，在 deadline 之内如果还卡着，那么就上报这个情况，这个时候这个 Deployment 状态就被标记为 False，并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的操作。完全由用户进行控制。
    replicas	<integer>  #副本数
    revisionHistoryLimit	<integer> #保留的历史版本，默认是10
    selector	<Object> -required- #标签选择器，选择它关联的pod
    strategy	<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 is
     RollingUpdate.
#支持两种更新，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-status
     PodSpec 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.6
    searches:
      - xianchao.svc.cluster.local
      - my.dns.search.xianchao
   dnsPolicy	<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> #使用主机IPC
   hostNetwork	<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}）给容器，默认30s
   tolerations	<[]Object>  #定义容忍度
   topologySpreadConstraints	<[]Object
   volumes	<[]Object>  #挂载存储卷

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

[root@master1 deployment]# 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@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.40
 background-color: blue;
 
[root@master1 deployment]# curl 10.1.166.177
 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@master1 deployment]# vim deploy-demo.yaml 
[root@master1 deployment]# cat deploy-demo.yaml | grep replicas
  replicas: 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=myapp
           version=v1
  Containers:
   myapp:
    Image:        janakiramm/myapp:v1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      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:  选择器：控制器通过选择器控制哪些pod
    matchLabels:   标签选择器
      project: ms   标签值
      app: portal
  template:   创建pod资源的模版
    metadata:   元数据
      labels:   给pod打标签
        project: ms    标签值
        app: portal
    spec:   详细信息
      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: 1Gi
         requests： #最少需要多少资源才可以运行Pod
            cpu: 0.5
            memory: 1Gi
        readinessProbe: 就绪性探测 
          tcpSocket: 基于tcp端口探测
            port: 8080  探测8080端口
          initialDelaySeconds: 60 pod启动后60s后才开始探测
          periodSeconds: 10  探测的间隔为10s
        livenessProbe:  存活性探测
          tcpSocket: 基于tcp端口探测
            port: 8080 探测8080端口
          initialDelaySeconds: 60  
          periodSeconds: 10


livenessProbe: 
 #存活性探测
#用于判断容器是否存活，即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: 8080
        initialDelaySeconds: 60
        periodSeconds: 10
#在Pod运行过程中，K8S仍然会每隔10s检测8080端口