Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的
ip。一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker），多个容器间共享IPC、Network和UTC namespace。
Pod的生命周期
创建一个pod
kubectl describe pod myapp查看具体的pod的信息
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下两点：
它们总是运行到完成。
Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成。
每个 Init 容器必须运行成功，下一个才能够运行。
如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
•Init 容器能做什么？
•Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
•Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
•应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像
•Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
•由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
我们创建一个init
查看
只有初始化成功才会执行pod
创建一个service让外部的可以访问我们的
创建完成后就可以完成解析
read为1就表明可以对外访问了，用户可以访问到他，然后就开始执行别的
探针 是由 kubelet 对容器执行的定期诊断:
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功
•TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
•HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
•每次探测都将获得以下三种结果之一：
•成功：容器通过了诊断。
•失败：容器未通过诊断。
•未知：诊断失败，因此不会采取任何行动。
探针的状态
挂起（Pending）：Pod 已被Kubernetes系统接受，但有一个或者多个容器读像尚未创建。等待时间包括调度Pod的时间和通过网络下载统像的时间，这可能需要花点时间。
运行中（Runming）：该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创难。至少有一个容器正在运行，或者正处于启动或重启状态。
成功（Succeeded）：Pod中的所有容器都被成功终止，并且不会再重启。
失败aied）：Pod中的所有容猫都已终止了，并且至少有一个容猫是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）：因为某些原因无法粤得Pod的状态，通常是因为与Pod所在主机通信失败。
常用的探针
livenessProbe：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启集路的影响。如果容器不损供存活探针，则默认状态为Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的媒点中删除该Pod的P地址。初始廷迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
探针存活检测
检测延时、检测频率、检测超时
然后创建探针
如果我们把端口改成8080就会一直重启，因为myapp占用的是80端口
查看restart的状态分别是0、1、2一直再重启
就绪检测
一直未read但是就是没有就绪查看日志
因为找不到test.html文件
这个时候如果我们把文件创建上就会就绪
他会持续检测，如果我们删除页面，发现就绪又变成0为未完成
重启策略
•PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。
•Pod 的生命
•一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。
•建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以
•三种可用的控制器：
•使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
•对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
•提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。
控制器
创建一个rs.yml
用来控制pod副本
修改app的label
我们创建一个deploment控制
我们如果将上述replicas改为4就相当于做了一个拉伸
如果我们上述镜像改成v2相当于做了滚动更新
这样他会重新建立四个新的并且删除原来的
查看更新结果
在做滚动更新的时候首先创建一个rs然后重建原来的pod删除原来的pod并且断开原来的rs并且保留
如果rs比较多我们可以删除
但是pod还是存在的
daemonset
创建一个yml文件
当我们删除pod的时候他会自动帮我们拉取
vim job.yaml(计算圆周率)
