在 Kubernetes 中，一个重要的概念就是 Pod(豆英)，Kubernetes 并不是直接管理容器他的最小管理单元叫做 Pod。的，
在 Docker 的应用中，我们把一个应用程序封装在一个镜像中，之后启动这个镜像并映射一个宿主机端口号，就能访问这个应用。既然单个容器就可以部署这个应用，为什么 Kubernetes不直接管理容器，而是要设计一个 Pod 呢?
一、什么是Pod
Pod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP 地址和端口的容器的集合。
1.从使用的角度来看
在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能组成一个系统，并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时,很难实现对容器内进行健康检査以及横向扩容等操作,而 Pod 可以轻松解决这些问题。
2.从Kubernetes 的角度来看
Docker 只是容器 Runtime(运行时)的一种们还有很多容器 Runtime，比如 Rkt、CRI-0等，而 Kubernetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层Runtime 的实现技术,于是就抽象出了 Pod 这个概念,用于管理多个紧密相连的符合 CRI 标准的容器。
Pod 可以简单的理解为一组、一个或多个容器，每个 Pod 还包含一个 Pause 容器，Pause 容器是 Pod 的父容器，主要负责僵尸进程的回收管理。同时，通过 Pause 容器可以使同一个 Pod里面的不同容器共享存储、网络、PID、IPC等，容器之间可以使用 Localhost:Port 的方式相互访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空卷、IP 地址和端口的容器。
3.Pod 有两个特点
网络:每一个Pod 都会被指派一个唯一的 ip 地址，在 Pod 中的每一个容器共享网络命名空间，包括 ip 地址和网络端口。在同一个 Pod 中的容器可以同 locahost 进行互相通信。当 Pod中的容器需要与 Pod 外的实体进行通信时，则需要通过端口等共享的网络资源。
存储:Pod 能够被指定共享存储卷的集合，在Pod 中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个Pod 持久化数据，以防止其中的容器需要被重启。
4.Pod的状态命令
kubectl命令创建pod
kubectl run nginx--image=nginx:1.7.9 --labels="app=nginx"查看pod
kubectl get pods -n default显示Pod的更多信息
kubectl get pod nginx -o wide查看pod日志
kubectl logs nginx以yaml格式显示Pod详细信息
kubectl get pod nginx -o yaml显示资源的详细描述信息
kubectl describe pod nginx在Pod的容器中执行命令
kubectl exec nginx -c nginx -- date
备注：-c:指定 Pod 中容器的名字登录到Pod中的容器中
kubectl exec -it nginx -c nginx --bash在线编辑运行中的资源对象
kubectl edit pod nginx将pod的端口映射到宿主机
kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80在宿主机和Pod的容器之间拷贝文件
kubectl cp nginx:etc/fstab /opt/aaa.txt
kubectl cp /opt/aaa.txt nginx:eetc/bbb.txtPod的状态
kubectl get pods -n default
删除Pod
kubectl delete pod nginx二、Pod探针
在生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检查尤其重要。在使用裸机或裸容器部署时，一般很难对应用做很完善的健康检査，而 Pod 提供的探针可以很方便的用来检测容器的应用是否正常。目前探针有3种检测方式，可以根据不同的场景选择合适的健康检查方式。
Pod探针检查容器后可能得到的状态
Pod探针有三类：
livenessProbe (存活探针):判断容器是否正常运行，如果失败则杀掉容器(不是 pod),再根据重启策略决定是否重启容器
readinessProbe(就绪探针):判断容器是否能够进入ready 状态，探针失败则进入noready 状态，并从 service 的endpoints 中剔除此容器
startupProbe(启动探针):判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态
三、Pod镜像拉取策略和重启策略
在发布应用或者更改控制器配置时，会种发 Pod 的滚动更新，此时针对容器的镜像有不同的拉取方式。
指定拉取策略
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --image-pull-policy=NeverPod 进行部署或者运行时，难免会出现故障，对于故障，Pod也有不同的处理方式。
指定重启策略
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --restart=OnFailure四、创建Pod
1.Pod文件语法
(1)Pod文件的一级属性
apiVersion<string>版本，由 kubernetes 内部定义，版本号必须可以用 kubect1api-versions 查询到。
kind<string>类型，由 kubernetes 内部定义，版本号必须可以用 kubect1api-resources 查询到。
metadata <0bject>元数据,主要是资源标识和说明,常用的有 name、namespace、labels
等。
spec<Object>描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述。
status<0bject>状态信息，里面的内容不需要定义，由kubernetes 自动生成。
(2)spec(规格)属性
在一级属性中，spec是研究的重点，它的常见子属性有:
containers<[ ]Object>容器列表，用于定义容器的详细信息
nodeName <String>根据 nodeName 的值将 pod 调度到指定的 Node 节点上
nodeselector <map[ ]>根据 NodeSelector 中定义的信息选择将该 Pod 调度到包含这些label的Node 上
hostNetwork<boolean>是否使用主机网络模式，默认为 false，如果设置为 true，表示使用宿主机网络
volumes<[ ]Object>存储卷，用于定义 Pod 上面挂在的存储信息
restartPolicy<string>重启策略，表示 Pod 在遇到故障的时候的处理策略
(3)通过kubectl explain命令来查看每种资源的可配置项
kubectl explain pod
kubectl explain deployment
kubectl explain service
kubectl explain pod.metadata
kubectl explain pod.spec.containers运行kubectl create命令创建Pod
kubectl create -f frontend-localredis-pod.yaml查看已经创建的Pod
kubectl get pods查看pod详细创建信息
kubectl describe pod redis-php删除pod
kubectl delete -f frontend-localredis-pod.yaml五、Pod的基本用法
部署nginx的pod文件
kubectl apply/create -f nginx-php.yaml查看pod的详细信息
kubectl describe pod nginx-php暴露端口
kubectl expose pod nginx-php --port=8080 --target-port=80 --type=NodePort --name=nginx-php查看端口映射
kubectl get pod,svc nginx-php -o wide
