今天很高兴可以和大家分享我们普元云平台SEM使用kubernetes时，关于pod、service网络通讯的实践与大家分享。
以下为今天讲的主要内容：
首先来看一下我们普元云的总体架构图
SEM –Software Enviroment Mgmt 向上承接业务需求，向下进行资源管理和调度。
SEM 后端对接的是容器，不是虚拟化技术。
SEM 后端选择容器技术，为了适应上层应用的快速多变的需求，这也是容器特点之一。
SEM 后端是以Flannel+Kubernetes为核心。(选择Flannel+Kubernetes 是两者结合的比较好，之前大神宋潇男也已经说明过。 )
容器的经典网络图，网络使用bridge方式来。
在docker 1.9之前主支持none/host/bridge/container四种网络模型。而在docker 1.9版本后实现了原本实验性的Networking组件的支持，可以在Swarm中使用它或者将其作为Compose 工具。创建虚拟网络并将其连接到容器实现多个主机上容器相互通讯。(kernel版本需要在3.19之上)
Kubernetes 不提供二层网络。二层网络是通过 Overlay Network来实现的。主要的flannel、openvswitch和weave等。这三种技术各有各的不同，且在部署过程中的难易度也有不同，性能上也差别。
普元云平台使用 flannel+kubernetes
Weave 主要是通过在宿主机上部署一个route的容器。 route拦截所有普通容器的ip请求，来实现容器间的网络通讯。
Flannel 是CoreOS团队开发的网络工具，flannel使用etcd进行配置，这样就可以保证多个flannel实例之间的配置一致性。
Flannel会为不同node的docker网桥配置不同IP段以保证docker容器的IP在集群内唯一。因此flannel会重新配置docker0网桥。
Flannel已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发模式。
Flannel是普元云平台网络实现技术，之前的微课程已经说明了。
Openvswitch 是通过SDN contrallor来实现。这是与weave和flannel的不同。
使用openvswitch需要提前进行ip段的规化，这是与flannel不同，openvswitch部署相较与weave和flannel有难度。
Kubernetes把Pod定义为最小管理单位，Pod是一个逻辑单位。Kubernetes通过PodIP实现容器网络变得灵活简单。Flannel负责二层网络管理，为容器分配地址还是docker0来完成。
Kubernetes提供PodIP为Pod与Pod，Pod与worker node的网络处于同一层面。
Kubernetes为每个Pod都附属了gcr.io/google_containers/pause:latest，这个容器只接管Pod的网络信息，业务容器通过加入网络容器的网络来实现网络共享。此容器随着pod创建而创建，随着Pod删除而删除，正如其名字“pause”
由于Pod IP使用了overlay network，如图在集群内Pod1､Pod3, Pod3, Pod4, work node1和work ndoe2之间的通讯。
在kubernetes集群中Node/Pod/Service的网络是扁平的网络。
Service在Pod之间起到服务代理的作用，对外表现为单一接口，将请求转发给Pod，Service的网络转发是kubernetes实现服务编排的关键一环。
在userspace机制，kubernetes proxy会为每一个service在主机上启用随机端口进行监听，创建iptables规则进行重定向。这个机制下kubernetes proxy是反向代理的作用。
在iptables机制下，kubernetes proxy则是完全通过创建iptable规则，直接重定向Service IP的请求到Endpoints，如果endpoints发生变化，kubernetes proxy负责刷新iptables规则。Kubernetes proxy只负责管理Service和endpoints，以及更新iptables规则。
Pod IP 带来的好处，通过overlay network网络实现Pod滚动更新，也可以算是恢度发布。
传统进行容器更新的时候，通常都是先停止v1版本的容器，然后在运行v2版本的容器。更新过程中Pod所在的应用来会出现。
正是通过Pod IP， 使得kubernetes在进行rolling Deployment更新应用在kubernetes中是先创建新版本v2然后在删除v1版本实现Pod应用更新。
