对于K8S而言，是最小的部署单元
是一组容器的集合，可以是一个容器，也可以是多个容器的集合
Pod内多个容器共享网络
其生命周期是短暂的，随时被创建，也随时被干掉
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，
因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中，
同一个Pod里的容器之间仅需通过localhost就能互相通信，这里当然就要注意端口冲突的问题，
Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。
一个Pod中的应用容器共享同一组资源：共享网络、共享储存
共享网络
通过Pause网络栈容器，把其他业务容器归纳到Pause容器里面，Pause可以让这些容器都处于同一个namespace名称空间中，从而实现网络的共享
共享储存
引入数据卷轴的概念Volumn，使用数据卷轴进行数据的持久化刷盘
Pod存在的意义
我们使用容器技术Docker来创建容器，一个docker对应一个容器，一个容器有进程，一个容器运行一个应用程序
Pod是多进程设计，可以运行多个应用程序
一个Pod可以有多个容器，一个容器运行一个应用程序
Pod的存在为了亲密性应用，缩短网络交互时间
Pod的特性
网络共享和储存共享
一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。 共享的如 namespace,group或者其他的隔离资源。
多个容器共享同一network namespace， 由此在一个Pod里的多个容器共享Pod的IP和端口namespace， 所以一个Pod内的多个容器之间可以通过localhost来进行通信,所需要注意的是不同容器要注意不要有端口冲突即可。
不同的 Pod 有不同的 IP,不同 Pod 内的多 个容器之前通信， 不可以使用 IPC（ 如果没有特殊指定的话） 通信， 通常情况下使用 Pod 的 IP 进行通信。
一个 Pod 里的多个容器可以共享存储卷， 这个存储卷会被定义为 Pod 的一部分， 并且可 以挂载到该 Pod 里的所有容器的文件系统上。
关于如何实现网络共享：所有容器都处于Pause所在的同一个nameSpace中，共享网络
关于如何实现共享储存，在资源编排yaml中，指定数据卷的挂载，就会实现数据的读取和独立储存
-
生命周期短暂
Pod 属于生命周期比较短暂的组件， 比如， 当 Pod 所在节点发生故障， 那么该节点上的 Pod 会被调度到其他节点， 但需要注意的是， 被重新调度的 Pod 是一个全新的 Pod,跟之前的 Pod 没有半毛钱关系。
-
平坦的网络
K8S 集群中的所有 Pod 都在同一个共享网络地址空间中， 也就是说每个 Pod 都可以通过其 他 Pod 的 IP 地址来实现访问
Pod的状态和 [拉取、重启] 策略
Pod的状态
| 状态值 | 说明 |
|---|---|
| Pending | API Server已经创建好该Pod,但是Pod中的一个或者多个容器的镜像还没有下载或者创建 |
| Running | Pod内所有的容器已经创建，至少一个容器处于运行状态、正在启动状态或者正在重启状态 |
| Completed | Pod内所有的容器都成功执行退出，且不会自动重启 |
| Failed | Pod内所有的容器都退出，但有一个或者多个容器退出失败 |
| Unknown | 未知异常无法获取Pod的状态，比如网络问题 |
Pod重启策略
restartPolicy ：[Always|Never|OnFailure]//重启策略， 默认值为 Always
| 重启策略 | 说明 |
|---|---|
| Always | 当容器失效时，总是由kubelet自动重启容器 |
| Never | 当容器终止运行且退出码不为0的时候，有kubelet自动重启该容器 |
| OnFailure | 无论容器运行关闭状态如何，kubelet都不会重启该容器 |
Pod镜像拉取策略
imagesPullPolicy: [Always|Never|IfNotPresent]//获取镜像的策略
| 镜像拉取策略 | 说明 |
|---|---|
| Always | 每次创建Pod都会从新拉去镜像 |
| Never | Pod永远不会主动拉取这个镜像 |
| IfNotPresent | 默认值，当宿主机不存在该镜像时，采取主动拉取 |
Pod的资源限制
每个 Pod都可以对其能使用的服务器上的计算资源设置限额， Kubernetes 中可以设置限额 的计算资源有 CPU与 Memory两种， 其中 CPU的资源单位为CPU数量,是一个绝对值而非相 对值。 Memory配额也是一个绝对值，它的单位是内存字节数
resources: #资源管理
requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
memory: 32Mi #内存使用量
limits: #资源限制最大范围
cpu: 0.5
memory: 64Mi上述代码表明容器申请最少 0.1 个 CPU 以及 32MiB 内存， 在运行过程中容器所能使 用的资源配额为 0.5 个 CPU 以及 64MiB 内存。
Pod的健康检查
-
livenessProbe 存活检查
-
如果检查失败，讲杀死容器，根据Pod的restartPolicy来操作
-
-
readinessProce：就绪检查
-
如果检查失败，kubernates会把Pod从Service endpoint中剔除
-
-
Probe支持一下三种检查方法（详细见下方图解）
-
httpGet
-
发送http请求，返回200-400范围的状态码为成功
-
-
exec
-
执行shell命令返回状态码是0为成功
-
-
tcpSocket
-
发起TCP Socket 建立成功
-
-
Pod的基本使用
在 kubernetes 中对运行容器的要求为： 容器的主程序需要一直在前台运行， 而不是后台运 行。 应用需要改造成前 台运行的方式。 如果我们创建的 Docker 镜像的启动命令是后台执 行程序， 则在 kubelet 创建包含这个容器的 pod 之 后运行完该命令， 即认为 Pod 已经结束， 将立刻销毁该 Pod。 如果为该 Pod 定义了 RC， 则创建、 销毁会陷入一个无 限循环的过程中。 Pod 可以由 1 个或多个容器组合而成。
Pod关联的常用命令
-
根据yaml创建一个容器
-
kubectl create -f xxx.yaml
-
-
查看
-
kubectl get pod / pd <pod_name>
-
kubectl get pod / po <pod_name> -o wide
-
kebectl describe pod / po <pod_name>
-
-
删除
-
kubectl delete -f pod pod_name.yaml
-
kubectl delete pod --all <pon_name>
-
Pod的分类
-
普通的Pod
普通 Pod一旦被创建， 就会被放入到 etcd 中存储， 随后会被 Kubernetes Master 调度到某 个具体的 Node 上并进行绑定， 随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相 关的 Docker容器并启动起来。 在默认情况下， 当 Pod 里某个容器停止时， Kubernetes 会 自动检测到这个问题并且重新启动这个 Pod 里某所有容器， 如果 Pod 所在的 Node 宕机， 则会将这个 Node 上的所有 Pod 重新调度到其它节点上。
-
静态Pod
静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod,它们不能通过 API Server 进行管理， 无法与 ReplicationController、 Deployment 或 DaemonSet 进行关联， 并且 kubelet 也无法对它们进行健康检查。
创建Pod的流程
-
如图所示：
影响Pod调度的因素