DevOps专题|玩转Kubernetes网络

Kubernetes无疑是当前最火热的容器编排工具，网络是kubernetes中很是重要的一环， 本文主要介绍一些相应的网络原理及术语，以及kubernetes中的网络方案和对比。
Kubernetes自己并不提供网络功能，只是把网络接口开放出来，经过插件的形式实现。为了知足不一样的网络功能及需求，使容器在建立或销毁时可以容易地配置容器网络， CNI（Container Network Interface）应运而生， CNI旨在定义运行时和插件之间的接口，在kubernetes中，CNI链接kubelet和网络插件来为容器配置对应的网络设置。

1 背景

容器网络是容器选择链接到其余容器、主机和外部网络的机制。在kubernetes网络模型设计中，每每须要每一个Pod都拥有一个独立的IP地址，并且假定全部的pod都在一个能够直接连通的、扁平的网络空间中。用户不须要额外考虑如何创建Pod之间的链接，也不须要考虑将容器端口映射到主机端口等问题。全部节点均可在不用NAT的方式下同全部容器通信，容器的地址和别人看到的地址是同一个地址。

2 技术术语

IPAM：IP地址管理；这个IP地址管理并非容器所特有的，传统的网络好比说DHCP其实也是一种IPAM，到了容器时代咱们谈IPAM，主流的两种方法：基于CIDR的IP地址段分配地或者精确为每个容器分配IP。但总之一旦造成一个容器主机集群以后，上面的容器都要给它分配一个全局惟一的IP地址，这就涉及到IPAM的话题。

Overlay：在现有二层或三层网络之上再构建起来一个独立的网络，这个网络一般会有本身独立的IP地址空间、交换或者路由的实现。

BGP：主干网自治网络的路由协议，用于管理边缘路由器之间数据包的路由方式。BGP经过考虑可用路径，路由规则和特定网络策略，帮助弄清楚如何将数据包从一个网络发送到另外一个网络。BGP有时被用做CNI插件中的路由机制，而不是封装的覆盖网络。

封装：封装是指在附加层中封装网络数据包以提供其余上下文和信息的过程。在overlay网络中，封装被用于从虚拟网络转换到底层地址空间，从而能路由到不一样的位置（数据包能够被解封装，并继续到其目的地）。

3 CNI

Container Network Interface (CNI) 最先是由CoreOS发起的容器网络规范，是Kubernetes网络插件的基础。其基本思想为：Container Runtime在建立容器时，先建立好network namespace，而后调用CNI插件为这个netns配置网络，其后再启动容器内的进程。

CNI Plugin负责给容器配置网络，必须实现为由容器管理系统（rkt或者kubernetes)调用的可执行文件，包括两个基本的接口来配置网络：

配置网络: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)

清理网络:DelNetwork(net NetworkConfig, rt RuntimeConf) error

在Kubernetes中，kubelet决定了容器应该加入哪一个网络以及它须要调用哪一个插件。而后插件会将接口添加到容器网络命名空间中，做为一个veth对的一侧。接着它会在主机上进行更改，好比将veth的其余部分链接到网桥。再以后，它会经过调用单独的IPAM（IP地址管理）插件来分配IP地址并设置路由。

4 IPAM

以上CNI插件解决了Pod内网络配置的问题，可是网络还有一个问题要解决的即是IP管理，为了解耦网络配置和ip管理， CNI定义了第二种类型的插件-ip地址管理插件（IPAM插件）。

与CNI插件同样，IPAM插件经过运行可执行文件来调用。IPAM插件负责为接口配置和管理IP地址。

CNI插件在执行时调用IPAM插件，IPAM插件来肯定接口IP /子网，网关和路由等信息，从而在容器启动时分配IP地址并配置网络，并将此信息返回给CNI插件，在删除容器时再次调用它以清理这些资源。

IPAM插件能够经过协议（例如dhcp），存储在本地文件系统上的数据，网络配置文件的“ipam”部分或上述各项的组合来获取信息。

5 介绍两种常见的k8s网络方案

flannel

flannel是CoreOS团队设计的一个网络方案，以etcd做为存储，给node上的每一个容器分配全局惟一的IP地址， 容器间经过overlay网络互相通讯。

Pod间通讯以下：

• Pod1和pod不在同一宿主机

数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡（veth pair），flanneld服务监听在网卡的另一端，Flannel经过Etcd服务维护了一张节点间的路由表，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每一个Pod的实际地址，源主机的flanneld服务将本来的数据内容UDP封装后根据本身的路由表投递给目的节点的flanneld服务，数据到达之后被解包，而后直接进入目的节点的flannel0虚拟网卡，而后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通讯一下的有docker0路由到达目标容器。

• Pod1和Pod2在同一台宿主机

Pod1和Pod2在同一台主机的话，由Docker0网桥直接转发请求到Pod2，不通过Flannel。

calico

Calico是一个纯3层的数据中心网络方案，并且无缝集成像OpenStack这种IaaS云架构，可以提供可控的VM、容器、裸机之间的IP通讯。

经过将整个互联网的可扩展IP网络原则压缩到数据中心级别，Calico在每个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每一个vRouter经过BGP协议负责把本身上运行的workload的路由信息像整个Calico网络内传播——小规模部署能够直接互联，大规模下可经过指定的BGP route reflector来完成。这样保证最终全部的workload之间的数据流量都是经过IP路由的方式完成互联的。

Calico节点组网能够直接利用数据中心的网络结构（不管是L2或者L3），不须要额外的NAT，隧道或者Overlay Network。

Calico还提供了丰富而灵活的网络Policy，保证经过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其余可达性限制等功能。

6 k8s网络在云翼的实践

容器技术的诞生，伴随本身诸多的优势被普遍应用。容器消除了部署环境差别，保证了应用生命周期的环境一致性标准，高资源利用率和隔离性，以及快速部署的特性，给企业的生产提高了效率，节约了成本。

随着京东云业务的快速增加，业务部署不能再局限于物理机、虚拟机等传统的方式， 云翼早在2017年就开始了容器方向的探索之路，咱们发现容器背后的理念很超前，但现实中生产环境有许多存量的业务，没法与之匹配，理念上是有一些差别， 如社区的容器倡导one process one container（在容器中只运行一个应用）。

云翼做为京东云DevOps平台，提供了集部署、运维、监控、日志等诸多功能，这些功能实现大多都是须要在实例内部署Agent与对应的服务通讯，而实例如何标识到自身每每是使用IP的方式，容器在内部落地的一个很强烈的需求就是可以固定IP，使运维或者开发能方便登陆容器排查问题；另外很大一部分存量的业务架构依赖固定IP；还有内部的一些基础系统都是经过IP来过滤，例如接入/LB 等后端须要填写IP地址。容器在内部的落地，不能彻底不考虑存量业务的兼容性，很难放弃原有的技术体系， 咱们但愿容器的引用能减轻上手成本，能更贴近传统运维的习惯，为了方便管理，咱们把容器的网络和机房的内网放在一个平坦的网络。

咱们开发了ipamD，大概的实现原理是pod每次建立时调用IPAMclient去请求ipamD申请地址， ipamD是一个常驻进程，维护了各个应用下对应分组的地址信息，经过pod前缀名能够查到对应实例的IP，经过这种方式实现了IP地址固定的需求。

另外为了降本增效，提高并知足一些业务方的特定需求，但愿容器可以跑在京东云的虚拟机上以方便管控相关的业务，咱们开发了相应的网络插件来知足在云主机中运行容器的需求，使云翼的用户能无差异的使用IaaS的资源。

云主机上的CNI插件借助弹性网卡、路由策略实现了：

1. 全部容器能够不须要NAT双向互通
2. 全部容器到Node能够不须要NAT双向互通，反之亦然

（图片来自https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md）

注：具体实现可参考amazon-vpc-cni-k8s(https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md)

云翼借助 docker/k8s 大幅提高了开发、测试、运维的生产力，简化了人工和自动系统管理工做。若是你想了解更多关于京东云翼，欢迎点击“阅读”~

欢迎点击“京东云”了解更多精彩内容