初探Kubernetes Pod
abcdocker DevOps视角
Pod 介绍
每个Pod都有一个特殊的被称为根容器的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器 。
为什么Kubernetes会设计出一个全新的Pod概念，并且有这样特殊的结构？
- Pause容器作为Pod根容器，以它的状态代表整个容器组的状态
- Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume
Kubernetes为每个Pod分配唯一的IP的地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP。Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP的直接通讯，采用虚拟二层网络技术来实现，一个Pod里的容器与另外主机上的Pod容器能够直接通信。静态Pod & 普通Pod
普通Pod
普通Pode一旦被创建，就会被放入到etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定(Binding),随后该Pod 被对应的Node上的kubelet进程实例化成一组相关的docker容器运行起来。 当Pod里的某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个Pod (重启Pod里的所有容器)，如果Pod所在的Node宕机，则会将这个Node上所有的Pod从新调度到其他节点上。
静态Pod (STatic Pod)
静态Pod不存放在Kubernetes的etcd存储里，而是存放在某个具体的Node上的文件中，并且只在此Node上启动运行。
静态Pod是由kubelet进行管理的仅存在于特定Node上的Pod。他们不能通过API Server进行管理，无法与ReplicationController(RC)、Deployment、或者DaemonSet进行关联，并且kubelet也无法对它们进行健康检查。静态Pod总是由kubelet进行创建的，并且总是在kubelet所在的Node上运行的Endpoint
Pod的IP加上这里的容器端口(container Port)，就组成了一个全新的概念---Endpoint它代表着此Pod里的一个服务进程的对外通讯地址。一个Pod也存在着多个Endpoint的情况，比如我们把Tomcat定义为一个Pod时，可以对外暴露端口与服务端口这两个Endpoint。
Event
Event是一个事件的记录，记录事件的最早生成时间、最后重现时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。Event通常会关联到某个具体的资源上，是排查故障的重要参考，Node描述信息包含了Event，而Pod同样有Event记录。
当我们发现某个Pod迟迟无法创建时，我们就可以用kubectl describe pod [Pod名称]来查看，定位问题。
示例：
# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-5c6b9976cc-2qbkr 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-bqtvp 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-ttdrz 0/1 ContainerCreating 0 14s
# kubectl describe pod nginx-deployment-5c6b9976cc-2qbkr
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 35s default-scheduler Successfully assigned default/nginx-deployment-5c6b9976cc-2qbkr to master
Warning FailedCreatePodSandBox 6s (x2 over 28s) kubelet, master Failed create pod sandbox: rpc error: code = Unknown desc = failed pulling image "gcr.io/google_containers/pause-amd64:3.0": Error response from daemon: Get https://gcr.io/v1/_ping: dial tcp 74.125.203.82:443: getsockopt: connection timed out