Kubernetes实践-Pod
Pod实现原理
Pod只是一个逻辑概念，Kubernetes真正处理的还是宿主机操作系统上Linux容器的Namespace和Cgroups，而并不存在一个所谓的Pod边界或隔离环境
Pod其实是一组共享了某些资源的容器，Pod里的所有容器，共享的是同一个Network Namespace，并且可以声明共享同一个Volume
在Kubernetes项目里，Pod的实现需要使用一个中间容器，这个容器叫做Infra容器（Infra容器占用极少的资源，它的镜像时用汇编语言编写的，永远处于“暂停”状态的容器）。在Pod中，Infra容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过join Network Namespace的方式，与Infra容器关联在一起，如下图所示，对于同一个Pod里面的所有用户容器，它们的进出流量都是通过Infra容器完成的。
在Infra容器Hold住Network Namespace后，用户容器就可以加入到Infra容器的Network Namespace中。对于Pod里容器A和容器B来说
- 它们可以直接使用localhost进行通信
- 它们看到的网络设备跟infra容器看到的完全一样
- 一个Pod只有一个IP地址（即这个Pod的Network Namespace对应的IP地址）。其他所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享
- Pod的生命周期只跟Infra容器一致，而与容器A和容器B无关
pod是一个小家庭，它把密不可分的家庭成员(container)聚在一起，Infra container则是家长，掌管家中共通资源，家庭成员通过sidecar方式互帮互助，其乐融融～
Pod的生命周期
- Pending：Pod的YAML文件已经提交给了Kubernetes，API对象已经被创建并保存在Etcd当中，但是这个Pod里有些容器因为某种原因而不能被顺利创建，比如调度不成功
- Running：Pod已经调度成功，跟一个具体的节点绑定，它包含的容器都已经创建成功，并且至少有一个正在运行中
- Succeeded： Pod里所有容器都正常运行完毕，并且已经退出了，一次性任务最常见
- Failed：Pod里至少有一个容器以不正常的状态（非0的返回码）退出
- Unknown：Pod状态不能持续地被kubelet汇报给kub-apiserver，很可能是Master和Kubelet之间通信出了问题