k8s 控制器：Replicaset 和 Deployment

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

• k8s 在定义 pod 资源时，可以直接创建一个 kind：Pod 类型的自主式pod，但是这存在一个问题，假如 pod 被删除了，那这个 pod 就不能自我恢复，就会彻底被删除，线上这种情况非常危险，所以需要使用 pod 控制器
   
• 所谓控制器就是能够管理 pod，监测 pod运行状况，当 pod 发生故障，可以自动恢复 pod。也就是说能够代我们去管理 pod 中间层，并帮助我们确保每一个 pod 资源始终处于我们所定义或者我们所期望的目标状态，一旦 pod 资源出现故障，那么
  控制器会尝试重启 pod 或者里面的容器，如果一直重启有问题的话那么它可能会基于某种策略来进行重新布派或者重新编排；如果 pod 副本数量低于用户所定义的目标数量，它也会自动补全；如果多余，也会自动终止 pod 资源。

• Replicaset 控制器：概念、原理解读

• Replicaset 概述
• ReplicaSet 是 kubernetes 中的一种副本控制器，简称 rs，主要作用是控制由其管理的 pod，使pod 副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行，它会持续监听这些 Pod 的运行状态，在 Pod 发生故障时重启 pod，pod 数量减少时重新运行新的Pod 副本。官方推荐不要直接使用 ReplicaSet，用 Deployments 取而代之，Deployments 是比ReplicaSet 更高级的概念，它会管理 ReplicaSet 并提供很多其它有用的特性，最重要的是Deployments 支持声明式更新，声明式更新的好处是不会丢失历史变更。所以 Deployment 控制器不直接管理 Pod 对象，而是由 Deployment 管理 ReplicaSet，再由 ReplicaSet 负责管理 Pod 对象。
• Replicaset 工作原理：如何管理 Pod？
  Replicaset 核心作用在于代用户创建指定数量的 pod 副本，并确保 pod 副本一直处于满足用户期望的数量， 起到多退少补的作用，并且还具有自动扩容缩容等机制。
  Replicaset 控制器主要由三个部分组成：
  1、用户期望的 pod 副本数：用来定义由这个控制器管控的 pod 副本有几个
  2、标签选择器：选定哪些 pod 是自己管理的，如果通过标签选择器选到的 pod 副本数量少于我们指定的数量，需要用到下面的组件
  3、pod 资源模板：如果集群中现存的 pod 数量不够我们定义的副本中期望的数量怎么办，需要新建 pod，这就需要 pod 模板，新建的 pod 是基于模板来创建的。
• Replicaset 资源清单文件编写技巧
• 查看定义 Replicaset 资源需要的字段有哪些？
• # kubectl explain rs
   

  KIND:     ReplicaSet
  VERSION:  apps/v1

  DESCRIPTION:
       ReplicaSet ensures that a specified number of pod replicas are running at
       any given time.

  FIELDS:
       apiVersion <string> #当前资源使用的 api 版本，跟 VERSION: apps/v1 保持一致
       kind <string> #资源类型，跟 KIND: ReplicaSet 保持一致
       metadata <Object> #元数据，定义 Replicaset 名字的
       spec <Object> ##定义副本数、定义标签选择器、定义 Pod 模板
       status <Object> #状态信息，不能改

• 查看 replicaset 的 spec 字段如何定义？
   
•  kubectl explain rs.spec
  KIND: ReplicaSet
  VERSION: apps/v1
  RESOURCE: spec <Object>
  DESCRIPTION:
   Spec defines the specification of the desired behavior of the ReplicaSet.
   More info:
   https://git.k8s.io/community/contributors/devel/sig-architecture/apiconventions.md#spec-and-status
   ReplicaSetSpec is the specification of a ReplicaSet.
  FIELDS:
   minReadySeconds <integer>
   replicas <integer> #定义的 pod 副本数，根据我们指定的值创建对应数量的 pod
   selector <Object> -required- #用于匹配 pod 的标签选择器
   template <Object> #定义 Pod 的模板，基于这个模板定义的所有 pod 是一样的
• 查看 replicaset 的 spec.template 字段如何定义？
• 对于 template 而言，其内部定义的就是 pod，pod 模板是一个独立的对象
• kubectl explain rs.spec.template
  KIND: ReplicaSet
  VERSION: apps/v1
  RESOURCE: template <Object>
  DESCRIPTION:
   Template is the object that describes the pod that will be created if insufficient replicas are detected。PodTemplateSpec describes the data a pod should have when created from a template
  FIELDS:
   metadata <Object>
   spec <Object>
•  kubectl explain rs.spec.template.spec
  通过上面可以看到，ReplicaSet 资源中有两个 spec 字段。
  第一个 spec 声明的是 ReplicaSet 定义多少个 Pod 副本（默认将仅部署 1 个 Pod）、匹配 Pod 标签的选择器、创建 pod 的模板。
  第二个 spec是 spec.template.spec：主要用于 Pod 里的容器属性等配置。
  
  .spec.template 里的内容是声明 Pod 对象时要定义的各种属性，所以这部分也叫做 PodTemplate（Pod 模板）。还有一个值得注意的地方是：在.spec.selector 中定义的标签选择器必须能够匹配到spec.template.metadata.labels 里定义的 Pod 标签，否则 Kubernetes 将不允许创建 ReplicaSet。

• Replicaset 使用案例-部署 Guestbook 留言板

• vim replicaset.yaml

  

  
•  镜像比较大，耗时有些久。

  

•  资源清单详细说明
  apiVersion: apps/v1 #ReplicaSet 这个控制器属于的核心群组
  kind: ReplicaSet #创建的资源类型
  metadata:
    name: frontend #控制器的名字
    labels:
      app: guestbook
      tier: frontend
  spec:
    replicas: 3 #管理的 pod 副本数量
    selector:
    matchLabels:
    tier: frontend #管理带有 tier=frontend 标签的 pod
    template: #定义 pod 的模板
    metadata:
    labels:
      tier: frontend #pod 标签，一定要有，这样上面控制器就能找到它要管理的 pod 是哪些了
     spec:
       containers: #定义 pod 里运行的容器
       - name: php-redis #定义容器的名字
         image: yecc/gcr.io-google_samples-gb-frontend:v3
         ports: #定义端口
         - name: http #定义容器的名字
           containerPort: 80 #定义容器暴露的端口

• Replicaset 管理 pod-扩容、缩容、更新

• Replicaset 实现 pod 的动态扩容
• ReplicaSet 最核心的功能是可以动态扩容和回缩，如果我们觉得两个副本太少了，想要增加，只需要修改配置文件 replicaset.yaml 里的 replicas 的值即可，原来 replicas: 3，现在变成 replicaset: 4，修改之后，执行如下命令更新：
  vim replicaset.yaml
  kubectl apply -f replicaset.yaml

  

  
• 也可以直接编辑控制器实现扩容
  kubectl edit rs frontend #这个是我们把请求提交给了 apiserver，实时修改
   kubectl edit rs frontend
  把 spec 下的 replicas 后面的值改成 5，保存退出。
  注意是第2个spec

  

• Replicaset 实现 pod 的动态缩容
  如果我们觉得 5 个 Pod 副本太多了，想要减少，只需要修改配置文件 replicaset.yaml 里的 replicas 的值即可，把 replicaset：5 变成 replicas: 2，修改之后，执行如下命令更新：
  # kubectl apply -f replicaset.yaml 
  

• Replicaset 实现 pod 的更新

• kubectl edit rs frontend
  #修改镜像 image: yecc/gcr.io-google_samples-gb-frontend:v3 变成 image: ikubernetes/myapp:v2，修改之后保存退出
  
•  上面可以看到镜像变成了 ikubernetes/myapp:v2，说明滚动升级成功了

  

  上面可以看到虽然镜像已经更新了，但是原来的 pod 使用的还是之前的镜像，新创建的 pod 才会使用最新的镜像

• #把 10.244.61.223这个 ip 对应的 pod 删除

  

  重新生成了一个新的 pod：frontend-mghpv  发现新生成的 pod 的镜像已经变成了 myapp 的，说明更新完成了
• 如果直接修改 replicaset.yaml 文件，把 image: yecc/gcr.io-google_samples-gb-frontend:v3 变成- image: ikubernetes/myapp:v2
  kubectl apply -f replicaset.yaml
  #发现原来的 pod 还是用的 frontend:v3 这个镜像，没有实现自动更新

• 生产环境如果升级，可以删除一个 pod，观察一段时间之后没问题再删除另一个 pod，但是这样需要人工干预多次；实际生产环境一般采用蓝绿发布，原来有一个 rs1，再创建一个 rs2（控制器），通过修改 service 标签， service 可以匹配到 rs2 的控制器，这样才是蓝绿发布，这个也需要我们精心的部署规划，有一个控制器就是建立在 rs 之上完成的，叫做 Deployment

• 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 资源对象由哪几部分组成
  
  # 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 字段
  
  # 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 字段
  
  # 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 字段
  
  # 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
  
  # 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 字段
  
  # 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/apiconventions.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:
   - xuegod.svc.cluster.local
   - my.dns.search.xuegod
   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 站点

• deployment 是一个三级结构，deployment 管理 replicaset，replicaset 管理 pod
• vim  deploy-demo.yaml

  

  #创建的控制器名字是 myapp-v1
  1.NAME ：列出名称空间中 deployment 的名称。
  2.READY：显示 deployment 有多少副本数。它遵循 ready/desired 的模式。
  3.UP-TO-DATE： 显示已更新到所需状态的副本数。
  4.AVAILABLE： 显示你的可以使用多少个应用程序副本。
  5.AGE ：显示应用程序已运行的时间。
  
  kubectl get rs blue-green 显示如下：
  创建的控制器名字是 myapp-v1
  #创建 deploy 的时候也会创建一个 rs（replicaset），67fd9fc9c8 这个随机数字是引用 pod的模板 template 的名字的 hash 值
  1.NAME： 列出名称空间中 ReplicaSet 资源
  2.DESIRED：显示应用程序的所需副本数，这些副本数是在创建时定义的。这是所需的状态。
  3.CURRENT： 显示当前正在运行多少个副本。
  4.READY： 显示你的用户可以使用多少个应用程序副本。
  5.AGE ：显示应用程序已运行的时间。
  
  请注意，ReplicaSet 的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING 是随机生成的

• kubectl get pods -A

  

  

  #资源清单文件详细解读
  apiVersion: apps/v1 #deployment 对应的 api 版本
  kind: Deployment #创建的资源是 deployment
  metadata:
    name: myapp-v1 #deployment 的名字
    namespace: blue-green #属于哪个名称空间
  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 管理应用，实现扩容，把副本数变成 4
• vim deploy-dome.yaml

  

  查看详细信息 
  kubectl describe deployments.apps --namespace blue-green myapp-v1
  可以使用简写 -n 指定命名空间

  

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

  

  #通过 deployment 管理应用，实现滚动更新
  在一个终端窗口执行如下：
  kubectl get pod -Al app=myapp -w

  

  打开一个新的终端窗口更改镜像版本，按如下操作：
  把 image: janakiramm/myapp:v1 变成 image: janakiramm/myapp:v2
  
  pending 表示正在进行调度，ContainerCreating 表示正在创建一个 pod，running 表示运行一个 pod，running 起来一个 pod 之后再 Terminating（停掉）一个 pod，以此类推，直到所有 pod 完成滚动升级

  

  

  

  #上面可以看到 rs 有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚
  #查看 myapp-v1 这个控制器的历史版本
  kubectl rollout history deployment --namespace blue-green

  

  执行回滚操作：
  
  kubectl rollout history deployment --namespace blue-green
  
  kubectl rollout undo deployment --namespace blue-green myapp-v1 --to-revision=1
  

• Deployment 资源清单详解
• apiVersion: apps/v1
  kind: Deployment 
  metadata:
   name: portal
   namespace: ms 
  spec:
   replicas: 1
   selector:
   matchLabels:
   project: ms
   app: portal
   template:
   metadata:
   labels:
   project: ms
   app: portal
   spec:
   containers:
   - name: portal
   image: xuegod/portal:v1
   imagePullPolicy: Always
   ports:
   - protocol: TCP
   containerPort: 8080 
   resources: #资源配额
   limits: #资源限制，最多可用的 cpu 和内存
   cpu: 1
   memory: 1Gi
   requests： #最少需要多少资源才可以运行 Pod
   cpu: 0.5
   memory: 1Gi
   readinessProbe:
   tcpSocket:
   port: 8080
   initialDelaySeconds: 60
   periodSeconds: 10
   livenessProbe:
   tcpSocket:
   port: 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 端口