Flannel+K8s容器网络通信实践

转载本文需注明出处：EAII企业架构创新研究院，违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号：“加群 姓名 公司 职位 微信号”。

亲爱的各位朋友，大家好！

今天很高兴可以和大家分享我们普元云平台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应用更新。

关于作者：

严伟

现任普元基础设施架构师，网络专家。传统企业突破内部局域网，公有云化之路上的幕后英雄 。  

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信账号。