pod详解
pod介绍
pod的基础概念
Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象，一个pod代表着集群中运行的一个进程。kubernetes中其它大多数组件都是围绕着pod来进行支持和扩展pod功能的。
例如，用于管理pod运行的statefulset和deployment 等控制器对象，用于暴露应用的service和ingress对象，为pod提供存储的persistentVolumes存储资源对象。
kubernetes集群中Pod有两种使用方式
一个Pod中运行一个容器
“ 每个Pod中一个容器” 的模式是最常见的用法，在这种使用方式中，你可以把Pod想像成单个容器的封装，kubernetes管理的是Pod而不是直接管理容器。
在一个Pod中同时运行多个容器
一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，他们之间共享资源，这些在同一个Pod中的容器可以互相协作称为一个service单位，比如一个容器共享文件，另一个sidecar 容器来更新这些文件。pod将这些容器的存储资源作为一个实体来管理。
一个Pod下的容器必须运行在同一个节点上，现代容器技术建议一个容器只运行一个进程，该进程在容器中PID命名空间中的进程号为1，可直接接受并处理信号，进程终止时容器生命周期也就结束了。
若想在容器内运行多个进程，需要有一个类似linux操作系统init进程的管控类进程，以树状结构完成多进程的生命周期管理，运行于各自容器内的 进程无法直接完成网络通信，这是由于容器间的隔离机制导致，k8s中的Pod资源抽象正式解决此类问题，Pod对象是一组容器的集合，这些容器共享network、UTS及IPC命名空间，因此具有相同的域名，主句名和网络接口，并可通过IPC直接通信。
| namespace | 功能 |
| mnt（mount） | 提供磁盘挂载点和文件系统的隔离能力 |
| ipc（inter-Process Communication） | 提供进程间通信的隔离能力 |
| net（network） | 提供网络隔离能力 |
| uts（Unix Time Sharing） | 提供主机名隔离能力 |
| pid | 提供进程号隔离能力 |
| user | 提供用户隔离能力 |
Pod中的pause容器
Pod资源中针对各容器提供网络命名空间等共享机制的是底层基础容器pause，pause就是为了管理Pod容器间的共享操作，这个副容器需要能够准确的知道如何去创建共享运行环境的容器，还能管理这些容器的生命周期，为了实现这个副容器的构想，kubernetes中用pause容器来作为一个Pod中所有容器的副容器，
这个pause容器有两个核心的功能，一个是它提供整个Pod的Linux命名空间的基础，二是启动PID命名空间，它在每个Pod中都作为PID为1的进程（init进程），并回收僵尸进程。
pause容器使得Pod中的所有容器可以共享两种资源：网络和存储
网络
每个Pod都会被分配一个唯一的IP地址，Pod中的所有容器共享网络空间，包括IP地址和端口，Pod内部的容器可以使用localhost互相通信，Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）
存储
Pod可以指定多个共享的Volume，Pod中的所有容器都可以访问共享Volume。Volume也可以用来持久化Pod中的存储资源，以防止容器后文件丢失。
#总的来说
//每个Pod都有一个特殊的被称为“基础容器”的pause容器，pause容器对应的镜像属于kubernetes平台的一部分，除了pause容器，每个Pod号包含一个或多个紧密相关的用户应用容器。#kubernetes中pause容器主要为每个容器提供一下功能
//在pod中担任linux命名空间(如网络命名空间)共享的基础
//启用PID命名空间，开启init进程#kubernetes涉及这样的Pod概念和特殊组成结构有什么用意？
//原因一
在一组容器作为一个单元的情况下，难以对整体的容器简单的进行判断及有效进行行动。比如一个容器死亡了，此时是算整体挂了吗？那么引入与业务无关的pause容器作为Pod的基础容器，以它的状态代表牌整个容器组的状态，这样就可以解决该问题。//原因二
Pod里的多个应用容器共享pause容器的IP。共享pause容器挂载的Volume，这样简化了应用容器之间的通信问题，也解决了容器之间的文件共享问题。//就是产生pause容器的两个原因是，1、通过pause容器判断整个pod中容器是否正常，2、通过pause容器共享网络和挂载。
Pod的分类
自主式Pod
这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其它controller），都会被kubernetes调度到集群的Node上，直到Pod的进程终止，被删掉，因为缺少资源而被驱逐，或者Node故障之前这个Pod都会一直保持在那个Node上。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果所在Node缺少资源或者pod处理维护状态，Pod也会被驱逐。
控制器管理的Pod
kubernetes使用更高级的称为controller的抽象层，来管理Pod实例。controller可以创建和管理多个Pod，提供副本管理，滚动升级和集群级别的自愈能力。
例如，如果一个Node故障，controller就能自动将该节点上Pod调度到其它健康的Node上，虽然可以直接使用Pod，但是kubernetes中通常是使用controller来管理Pod的。
Pod的容器分类
基础容器（infrastructure container）
维护整个Pod网络和存储空间
node节点中操作
启动一个容器时，k8s会自动启动一个基础容器
初始化容器（init container）
Init 容器必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。Init 容器与普通的容器非常像，除了以下两点
1.Init 容器总是运行到成功完成为止
2.每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出
如果 Pod 的 Init 容器失败，k8s 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的重启策略（restartPolicy）为 Never，它不会重新启动。
#init容器的作用
因为 init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势1、Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
2、Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
3、应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
4、Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可具有访问 Secrets的权限，而应用容器不能够访问。
5、由于 Init 容器必须在应用容器启动之前运行完成，因此 Init容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。
应用容器（ main container）
在init容器完成并退出后并行启动
pod定义（资源清单）
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
在kubernetes中所有资源的一级属性都是一样的，主要包含5部分
apiVersion 版本： 由kubernetes内部定义，版本号必须可以用kubectl api-versions 查询到
kind 类型： 由kubernetes 内部定义，版本号必须可以用kubectl api-resources 查询到
metadata 元数据： 主要是资源标识和说明，常用的有name、namespace、labels等
spec 描述： 这是配置中最重要的一部分，里面是对各种资源配置的详细描述。
status 状态信息： 里面的内容不需要定义，由kubernetes自动生成。
在上面的属性中，spec 是接下来研究的重点，继续看它的常见子属性
containers <[]Object> 容器列表： 用于定于容器的详细信息
nodeName ： 根据nodeName的值将pod调度到指定的Node节点上
nodeSelector
hostNetwork 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes <[]Object> 存储卷： 用于定义Pod上面挂在的存储信息
restartPolicy 重启策略： 表示Pod在遇到故障的时候的处理策略
Pod中的容器配置
kubectl explain pod.spec.containers
#查看pod资源下的spec属性下的containers容器的配置信息
//下面列出常用的几项配置
KIND: Pod
VERSION: V1
RESOURCE: containers <[] object> #数组，代表可以有多个容器
FIELDS:
name #容器名称
image #容器需要的镜像地址
imagePullPolicy #镜像拉取策略
command <[]string> #容器的启动命令列表
args <[]string> #容器的启动命令需要的参数列表
env <[]object> #容器环境变量的配置
ports <[]object> #容器需要暴露的端口号列表
resources 基本配置
vim pod-text.yaml
apiVersion: v1 #版本号
kind: Pod #资源类型
metadata: #元信息
name: pod-base #pod名称
namespace: dev #pod的命名空间
labels: # 标签
user:ydq
spec: # 属性
containers:
- name: nginx
image: nginx:1.14 #定义了两个容器
- name: busybox
image: busybox:1.30
kubectl apply -f pod-base.yaml
#生成pod
kubectl get pods -n dev
#查看pod是否生成
kubectl describe pod pod-base -n dev
#查看该pod的详细信息
//READY 1/2 : 表示当前pod中有两个容器，其中一个准备就绪，1个未就绪
//RESTARTS : 重启次数，因为有一个1个容器故障了，Pod这一直在重启试图恢复它
镜像拉取（imagePullPolicy）
imagePullPolicy ： 用于设置镜像拉取策略，kubernets支持配置三种拉取策略
- Always： 总是从远程仓库拉取镜像（一直远程下载）
- ifNotPresent： 本地有则使用本地镜像，本地没有则从远程仓库拉取镜像
- Never： 只使用本地镜像，从不去远程仓库拉取，本地没有就报错。（一直使用本地）
默认值说明：
如果镜像tag为具体版本号， 默认策略是：IfNotPresent
如果镜像tag为：latest（最终版本） ，默认策略是always
apiVersion: v1
kind: Pod
metadata:
name: pod-imagepullpolicy
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.2
imagePullPolicy: Never #用于设置镜像拉取策略
启动命令（command）
在前面的案例中，一直有一个问题没有解决，就是busybox容器一直没有成功运行，那么到底是什么原因导致整个容器的故障呢？
- 因为busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭，解决办法就是让其一直在运行，这就用到了conmand配置。
apiVersion: v1
kind: Pod
metadata:
name: pod-command
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]
//command: 用于在pod中的容器初始化完毕之后运行一个命令。
"/bin/sh","-c", #使用sh执行命令
touch /tmp/hello.txt; #创建一个/tmp/hello.txt 文件
while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done; # 每隔3秒向文件中写入当前时间
环境变量（env）
env : 环境变量，用于在pod中的容器设置环境变量。
apiVersion: v1
kind: Pod
metadata:
name: pod-env
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do /bin/echo $(date +%T);sleep 60; done;"]
env: # 设置环境变量列表
- name: "username"
value: "admin"
- name: "password"
value: "123456"
kubectl apply -f pod-env.yaml
kubectl exec -it pod-env -n dev /bin/sh
#登录到容器中，（这里不需要使用-c指定容器名称，因为将诶这个pod里面就一个容器）
端口设置（ports）
apiVersion: v1
kind: Pod
metadata:
name: pod-ports
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports: # 设置容器暴露的端口列表
- name: nginx-port
containerPort: 80
protocol: TCP
资源配额（resources）
容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。 针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：
- limits： 用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
- requests ： 用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动
内存资源单位
内存的request 和limit 以字节为单位，可以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2 为底数的指数来表示（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
cpu的单位如果为0.5，表示该容器能获取的一个Cpu的一半，（类似于Cgroup对cpu的资源的时间分片），表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用cpu时间总量为100号秒。
案例1：创建pod-resources.yaml 文件
apiVersion: v1
kind: Pod
metadata:
name: pod-resources
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
resources: # 资源配额
limits: # 限制资源（上限）
cpu: "2" # CPU限制，单位是core数
memory: "10Gi" # 内存限制
requests: # 请求资源（下限）
cpu: "1" # CPU限制，单位是core数
memory: "10Mi" # 内存限制
#以上是可以正常创建pod的，然后再将requests的最小内存限制改为10Gi，再创建pod，查看是否创建成功
#发现是无法创建成功的，因为requests最小请求量不仅需要满足容器内部的应用启动大小， 也需要在当前node节点上能划分出该设定的资源的。不然资源无法请求成功到，容器也无法运行。
kubectl apply -f pod-resources.yaml
kubectl get pods -n dev
kubectl describe pod pod-resources -n dev
#查看详细信息
kubectl logs pod-resources -c nginx
#查看对象的容器日志信息
pod生命周期
pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程
pod创建过程
运行初始化容器（init container）过程
运行主容器（main container）
容器启动后钩子（post start），容器终止前钩子（pre stop）
容器的存活性探测（liveness probe），就绪性探测（readiness probe）
pod终止过程
在整个生命周期中，pod会出现5中状态（也称为相位）
挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启。
失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致
创建和终止
pod的创建过程
用户通过kubectl或其它api客户端提交需要创建的pod信息给apiserver。
apiserver开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端。
apiserver开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiserver上变动。
scheduler发现有新的pod对象要创建，开始为pod分配主机并将结果信息更新至apiserver。
node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结构返回apiserver
apiserver将接收到的pod状态信息存入etcd中。
pod的终止过程
用户向apiServer发送删除pod对象的命令
apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
将pod标记为terminating状态
kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
pod对象中的容器进程收到停止信号
宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
初始化容器（initContainers）
初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
- 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行
初始化容器有很多的应用场景，下面列出的是最常见的几个：
- 提供主容器镜像中不具备的工具程序或自定义代码
- 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
案例
假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器
为了简化测试，事先规定好mysql (20.0.0.100 ) 和 redis (20.0.0.110) 服务器的地址
apiVersion: v1
kind: Pod
metadata:
name: pod-initcontainer
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
initContainers:
- name: test-mysql
image: busybox:1.30
command: ['sh', '-c', 'until ping 20.0.0.100 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
- name: test-redis
image: busybox:1.30
command: ['sh', '-c', 'until ping 20.0.0.110 -c 1 ; do echo waiting for reids...; sleep 2; done;']
kubectl create -f pod-initcontainer.yaml
#创建pod
kubectl describe pod pod-initcontainer -n dev
#查看pod状态(发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行)
kubectl get pods pod-initcontainer -n dev -w
#动态查看pod状态
//接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化
ifconfig ens33:1 20.0.0.100 netmask 255.255.255.0 up
ifconfig ens33:2 20.0.0.110 netmask 255.255.255.0 up
//发现可以正常启动，因为初始化容器运行完成了
钩子函数（lifecycle）
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码
kubernetes在主容器的启动之后和停止之前提供了两个钩子函数
- post start ： 容器创建之后执行，如果失败会重启容器
- pre stop ： 容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作。
钩子处理器支持使用下面三种方式定义动作
- Exec命令：在容器内执行一次命令
....
lifecycle:
postStart:
exec:
command:
- cat
- /tmp/healthy
....
- TCPSocket：在当前容器尝试访问指定的socker
....
lifecycle:
postStart:
tcpSocker:
port: 8080
....
- HTTPGet：在当前容器中向某url发起http请求
....
lifecycle:
postStart:
httpGet:
path: / #URI地址
port: 80 #端口号
host: 192.168.5.3 #主机地址
scheme: HTTP #支持的协议，http或者https
....
以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-hook-exec
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
lifecycle:
postStart:
exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容
command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]
preStop:
exec: # 在容器停止之前停止nginx服务
command: ["/usr/sbin/nginx","-s","quit"]
kubectl create -f pod-hook-exec.yaml
kubectl get pods pod-hook-exec -n dev -o wide
curl 【pod的ip地址】
容器探测（probe）
容器探测用于检测容器中的应用实例是否正常共工作，是保障业务可用性的一种传统机制，如果经过探测，实例的状态不符合预期，那么kubernetes就会把问题实例 “ 摘除 ”，不承担业务流量，kubernetes提供了两种探针来实现容器探测。
liveness probe： 存活性探针，用于检测应用实例当前是否处于正常状态，如果不是，k8s会重启容器（根据重启策略选择是否重启），如果容器不提供存活探针，则默认状态为success。
readiness probe： 就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量。端点控制器将从与Pod匹配的所有service endpoints中剔除删除该pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
startupProbe： 启动性探针，判断容器内的应用程序是否已启动，主要针对不能确定具体启动时间的应用，如果配置了 startup Probe 探测，在startup Probe 状态为Success之前，其它探针都处于无效状态，直到它成功后，其它探针才起作用，如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置startupProbe，则默认状态为Success。
#以上规则可言同时定义，在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。
livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。
上面两种探针目前均支持三种探测方式
- Exec命令： 在容器内执行一次命令，如果命令执行的退出吗为0 ，则认为程序正常，否侧不正常
....
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
....
- TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否侧不正常
....
livenessProbe:
tcpSocket:
port: 8080
....
- HTTPGet：调用容器内Web应用的URL。如果返回的状态码在200和399之间，则认为程序正常，否则不正常
....
livenessProbe:
httpGet:
path: / #URL地址
port: 80 #端口号
host: 127.0.0.1 #主机地址
scheme: HTTP #支持的协议，http或https
....
每次探测都将获得以下三种结果之一：
- 成功：容器通过了诊断
- 失败：容器未通过诊断
- 未知：诊断失败，因此不会采取任何行动