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