Pod是kubernetes中你可以创建和部署的最小也是最简的单位。Pod代表着集群中运行的进程。
Pod中封装着应用的容器（数量大于等于1，docker最常用，也可使用其他的），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
自主式pod
控制器管理的pod
每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。
可以为一个Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。
你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。
Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为
有如下几种类型：RC（ReplicationController），RS（ReplicaSet），Deployment，HPA（HorizontalPodAutoScale）,StatefullSet，DaemonSet，Job，Cronjob
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
在新版本的 Kubernetes中建议使用 ReplicaSet来取代 ReplicationControlle
ReplicaSet跟 ReplicationController没有本质的不同，只是名字不一样，但是ReplicaSet支持集合式的selector
虽然 ReplicaSet可以独立使用，但一般还是建议使用 Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet不支持rolling-update（回滚更新）但 Deployment支持）
Deployment为Pod和 ReplicaSet提供了一个声明式定义（ declarative）方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括
定义 Deployment来创建Pod和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment
Horizontal Pod Autoscaling仅适用于 Deployment和 ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩所容，在 V1alpha版本中，支持根据内存和用户自定义的 metric扩缩容
StatefulSet是为了解决有状态服务的问题（对应 Deployments和 ReplicaSets是为无状态服务而设计），其应用场景包括
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其 PodName和 HostName不变，基于 Headless Service（即没有 Cluster IP的 Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N1，在下一个Pod运行之前所有之前的Pod必须都是 Running和 Ready状态），基于 init containers来实现
有序收缩，有序删除（即从N-1到0）
DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod
使用 DaemonSet的一些典型用法：
运行集群存储 daemon，例如在每个Node上运行 glusterd、ceph
在每个Node上运行日志收集 daemon，例如 fluentd、 logstash
在每个Node上运行监控 daemon，例如 Prometheus Node Exporter
Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
CronJob管理基于时间的Job，即：
在给定时间点只运行一次
周期性地在给定时间点运行
Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。
Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。（通过一些标签与pod建立联系，且service有自己的IP地址和端口）
client客户端通过访问service的IP地址和端口和RR（轮询算法）来访问到下面的pod。
Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（ Google Compute Engine）里面是现成的网络模型， Kubernetes假定这个网络已经存在。
而在私有云里搭建 Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker容器之间的互相访问先打通，然后运行 Kubernetes
同一个Pod内的多个容器之间：lo（通过localhost回环地址）
各Pod之间的通讯：overlay Network （覆盖网络）
Pod与 Service之间的通讯：各节点的 Iptables规则
Flannel是CoreOS团队针对 Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内
ETCD在这里的作用：为Flannel提供说明
存储管理 Flannel可分配的IP地址段资源
监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表
同一个Pod内部通讯
同一个Pod共享同一个网络命名空间，共享同一个 Linux协议栈
pod1和pod2通讯在同一台机器：
Pod1与Pod2不在同一台主机，Pod的地址是与 docker0在同一个网段的，但doke0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问
pod1和pod2通讯–不在同一台机器：
Pod1与Pod2在同一台机器，由 Docker0网桥直接转发请求至Pod2，不需要经过 Flanne1
Pod至 Service的网络
目前基于性能考虑，全部为 iptables（现在版本都是通过LVS）维护和转发
Pod到外网
Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后， iptables执行 Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求
外网访问Pod
外网访问Pod通过Service
