pod控制器类型以及网络通讯方式
pod概念：
自主式pod：一旦死亡 不会进行拉起
控制器管理的pod：死亡后 控制器进行拉起
pod：一个pod里面可能有多个容器
运行pause（跑死），容器共用pause的网络站，共用pause的存储卷，进程不会进行隔离；
在同一个pod里 不能端口冲突；
控制器：
1、replicationcontroller ：用来保证容器应用的副本数始终保持在用户定义的副本数，如果有容器异常退出，会创建新的pod来代替；如果异常多出来的容器也会被自动回收
在新版版的kubernetes中建议使用replicaset来代替replicationcontroller
**2、replicaset ：**和replicationcontroller 没有本质不同 只是名字不同并且relicaset支持集合式的selector；可以使用打标签的方式进行指定集合
**3、deployment：**虽然一般replicaset 可以独立使用，但是一般还是建议使用1deployment来自动管理replocaset 这样无需担心和其他机制不兼容的问题（比如replicaset不支持rolling-update，但是deployment支持）
deployment流程图
deployment ---->创建rs------>创建pod
deployment不直接管理pod
4、horizon pod autoscaling 仅适用于deployment和RS 在v1版中仅支持根据pod的CPU利用率扩容，在vlapha版本中 支持根据内存和用户自定义的metric扩容缩容
**5、statufulset：**是为了解决有状态服务的问题（对应deployment和replicaset是为无状态服务而设计），其应用场景包括：
1、稳定的持久化存储，pod重新调度后还能访问到相同的持久化数据，基于PVC实现
2、稳定的网络标志，pod重新调度后其podname和hostname不变，基于headless service实现（没有cluster ip和service）
3、有序部署，有序扩展，pod是有顺序的，在部署或者扩展时要依据定义的顺序依次进行，基于init container来实现
4、有序收缩，有序删除
6、daemonset：确保全部node节点上运行一个pod的副本。当有node加入集群时，也会为他们新增一个pod。当有node从集群移除时，这些pod也会被回收，删除daemonset将会1删除1他们创建的所有的pod
使用daemonset的一些典型用户：
1、运行集群存储daemon，例如在每个node上运行glusterd、ceph
2、在每个node上运行日志收集daemon，例如fluentd、logstash
3、在每个node上运行监控daemon，例如Prometheus node exporter
7、job 负责批处理任务，仅执行一次的任务，他保证批处理任务的一个或者多个pod成功结束
cron job 管理基于时间的job ：
1、在给定时间点只运行一次
2、周期性在给定时
服务发现 service：
service服务发现是通过标签进行选择的
网络通讯模式
kubernetes的网络模型假定了所有pod都在一个直接连通的扁平的网络中，这在GCE里面是现成的网络模型，kubernetes假设这个网络已经存在。
而在私有云里搭建kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的docker 容器之间的互相访问先打通，然后运行kubernetes。
同一个pod的多个容器之间：lo
各个pod之间的通讯：overlay network
pod和service之间的通讯：各个节点的iptables规则
flannel网络：
简单来说，他的功能是让集群中的不同节点主机创建的docker容器都具有全集群唯一的虚拟IP地址，而且他还能在这些IP地址之间建立一个覆盖网络（overlay network）通过这个覆盖网络，将数据包原封不动地传递到目标容器内
etcd的flannel提供说明：
1、存储管理flannel可分配的IP地址段资源
2、监控etcd中每个pod的实际地址，并在内存中建立维护pod节点路由表
不同情况下网络通讯方式
同一个pod内部通讯：
同一个pod共享同一个网络命名空间 共享同一个linux协议栈
pod1至pod2：
1、pod1和pod2不在同一台，pod的地址与docker0在同一个网段的，但是docker0网段与宿主机网卡是两个完全不同的ip网段，并且不同node之间的通讯只能通过宿主机物理网卡进行。将pod的ip所在node的IP地址关联起来，通过这个关联让pod可以相互访问
2、pod1与pod2在同一台机器，由docker0网桥直接转发请求到pod2 不需要经过flannel
pod至service的网络：
目前基于性能考虑，全部为iptables维护和转发
pod到外网：
pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行masquerade，把源ip更改为宿主机网卡的ip，然后向外网服务器发送请求
外网访问pod service
kubernetes中的网络类型：
service网络：虚拟网络
pod网络：虚拟网络
节点网络：只有节点网络是真实的网络