2.1 Pod概念
Pod类型：
- 自主式pod：即不被控制器管理的Pod，死亡之后不会被重新拉起来，也不会被创建新的Pod。
每个Pod中运行着一个特殊的被称为Pause的容器，其他的容器为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间的通信和数据交互更为高效。
在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一Pod中，同一个Pod里的容器之间仅需通过locahost就能互相通信
- 控制器管理的Pod
Pod控制器类型：ReplicationController & ReplicaSet & Deployment
ReplicationController：简称RC，确保副本期望值数目，少了就创建新的Pod代替，多了就自动回收。
ReplicaSet：新版本建议通过RS来代替RC创建Pod，RS与RC没有本质区别，但是RS支持集合式selector(每个Pod有不同的标签，RS操作Pod可以按照标签进行条件筛选操作)。
Deployment：虽然RS可以独立，但是一般使用Deployment来自动管理RS，这样不用担心跟其他机制不兼容的问题，例如：RS不支持rolling-update（滚动更新），但是Deployment支持。Deployment本身不支持Pod创建，Deployment会创建RS，通过RS去创建Pod。
Deployment为Pod和ReplicaSet提供了一个声明式定义方法，用来替代以前的RC来管理应用。典型的应用场景包括：
* 定义Deployment来创建Pod和ReplicaSet
* 滚动升级和回滚应用
* 扩缩容
* 暂停和继续Deployment
HPA（HorizontalPodAutoScale：根据利用率平滑扩展，仅适用于Deployment和RS。
StatefulSet：解决有状态无福的问题，Deployment和RS是为了解决无状态服务而设计（Docker主要也是），主要场景包括：
* 稳定的持久化存储，即任务一个Pod死亡，重新调度成功之后还是能访问到相同的持久华数据，基于PVC实现。
* 稳定的网络标识，即Pod重新调度之后的Podname和Hostname不变，基于Headless Service来实现
* 有序部署，有序扩展，按照顺序行M>A>N（从0到N-1，在下一个Pod运行前，之前所有的Pod必须是running和Ready状态），基于init containers来实现。
* 有序收缩，即有序删除，即从N-1到0） Nagix > Apache >Mysql
DaemonSet：确保全部(或者一些)Node运行一个Pod副本，当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群中被移除时，相应的Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。除非打污点，正常情况所有的Node上都会运行一个且只有一个Pod。
典型用法：
* 运行集群存储daemon，例如在Node上运行glusterd、ceph
* 在每个Node上运行日志收集daemon，例如fluentd、logstash
* 在每个Node上运行监控daemon，例如Prometheus Node Exporter、zabbix agent都可以封装在DaemonSet中在每个Node上运行，帮助我们收集数据。
Job，Cronjob：
job负责批处理任务，即仅执行一次的任务，它确保批处理任务的一个或者多个Pod成功结束。（比如要备份数据库，备份代码可以放到统一Pod里，再放到Job里执行，与Linux直接运行不同点是是封装好的Job可以重复利用，并且脚本执行异常退出可以重复执行，并且可以设置正常退出次数才算Job执行成功）
cornjob管理基于时间的Job，即：
* 在给定时间点运行一次
* 周期性的在给定时间点运行
服务发现：
Client访问service的IP和端口，使用RR(Round Ribbon轮训)等算法间接访问到Pod
2.2 网络通讯方式
网络通讯模式：
Kubernetes的网络假定所有的Pod都在一个可以直接连通的扁平的网络空间中（都可以通过IP直接到达，其实底层有很多转换机制），这在GCE（Google Compute Engine）里面是现成的网络模型，K8S假定这个网络已经存在。而在私有云搭建K8S集群，就不能假定这个网络已经存在，我们需要自己去实现这个网络假设，将不同节点上的Docker容器之间互相访问先打通，然后再运行K8S。
同一个Pod内的多个容器见：lo pause
各Pod之间的通讯：Overlay Network
Pod与Service之间通讯：各节点的Iptables规则，新版本支持LVS转发上限，效率更高。
网络解决方案：K8S+Flannel
Flannel是CoreOS团队针对K8S设计的一个网络规划服务，简单来说他，他的功能是让集群中的不同节点主机创建的Docker容器具有全集群唯一的虚拟IP主机。而且它还能在这些IP之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
ETCD之Flannel提供说明：
>存储管理Flannel可分配的IP地址段资源
>监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表
不同情况下网络通信方式
同一个 Pod 内部通讯：同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈
Pod1 至 Pod2
> Pod1 与 Pod2 不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过 这个关联让Pod可以互相访问
> Pod1 与 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2，不需要经过 Flannel
Pod 至 Service 的网络：目前基于性能考虑，全部为 iptables 维护和转发
Pod 到外网：Pod 向外网发送请求，查找路由表, 转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执 行Masquerade，把源 IP 更改为宿主网卡的 IP，然后向外网服务器发送请求
外网访问 Pod：Service 组件通讯示意图：
标签：Node,容器,RS,IP,基础,概念,Deployment,Pod From： https://www.cnblogs.com/fangyu-blog/p/16770590.html