本文讲的是DockOne微信分享( 九十四）：唯品会基于Kubernetes的网络方案演进【编者的话】本文主要介绍唯品会云平台PaaS在持续集成和持续部署方面，基于Docker和Kubernetes，对网络方案的选型及应用，以及随着业务需求的增加而经历的网络方案变更，包括：
基于这种网络访问功能，我们平台提供了以下功能：
网络访问关系图如下：
在Kubernetes Flannel的模型下，容器网络是封闭子网，可以提供平台内部应用之间基于4层和7层的调用，同时对外部提供应用基于域名（工作在七层）的直接访问，但无法满足用户在平台外部需要直接使用IP访问的需求。
整个架构分为三层：
整个方案包括以下三个流程：
[Contiv的网络模型在之前的分享 http://dockone.io/article/1691 里已经有详细解释]这里根据我们实际网络访问关系再描述下PaaS在Contiv整体部署结构：
Kube-haproxy替代了kube-proxy，主要是提供服务IP的公共调用，同时避免了容器数量增加后带来的iptables规则的大量增长，方便调试。这里要注意的是Haproxy所部署机器IP和Kubernetes Service IP要在同一网段。
Contiv带来的方便是用户可以根据实例IP直接进行访问；但是在使用过程中出现过一次问题： 机房停电导致了部分IP的分配状态不正确，而且Contiv当时还没有提供查看已分配IP的接口。
前面提到应用运行时，对应Kubernetes内一个Replication Controller以及一个Service。应用的重新部署目前采用的策略主要是重建策略。重建的流程包括删除RC及RC下所有Pod，更新并创建新的RC（Kubernetes会根据RC配置产生新的POD） 。
在默认的Kubernetes Contiv的网络环境下，容器（Pod）的IP网络连接是由Contiv Network Plugin来完成的，Contiv master只实现了简单的IP地址分配和回收，每次部署应用时，并不能保证Pod IP不变。所以我们引入了新的Pod层面的IPAM，以保证同一个应用多次发生部署时，Pod IP始终是不变的。
作为Pod层面的IPAM，我们把这一功能直接集成在了Kubernetes。Pod作为Kubernetes的最小调度单元，原有的Kubernetes Pod Registry（主要负责处理所有与Pod以及Pod subresource相关的请求：Pod的增删改查，Pod的绑定及状态更新，exec/attach/log等操作）并不支持在创建Pod时为Pod分配IP，Pod IP是通过获取Pod Infra Container的IP来获取的，而Pod Infra Container的IP即为Contiv动态分配得来的。
定制后的Pod Registry操作流程图：
在原有Kubernetes代码基础上，我们修改了Pod结构（在PodSpec中加入PodIP）并重写了Pod Registry 同时引入了两个新的资源对象：
Pod IP Recycler只会回收通过RC创建的Pod的IP，通过其他controller或者直接创建的Pod的IP并不会记录，所以通过这种方式创建的Pod的IP并不会保持不变；同时Pod IP Recycle检测每个已回收IP对象的TTL，目前设置的保留时间为一天。
这里对kubelet也进行了改造，主要包括根据Pod Spec中指定IP进行相关的容器创建（docker run加入IP指定）以及Pod删除时释放IP操作。 创建Pod的UML时序图如下：
Pod的创建在PaaS里主要有两种情形：
删除Pod的UML时序图如下：
Pod的删除流程触发情形：删除应用/应用缩容/重新部署重建策略。
整体删除过程为：由PaaSNg或kube-controller-manager调用apiserver Pod Delete并设置DeletionTimestamp，kubelet监听到删除时间并获取GracefulDeletiontime，删除应用容器, 通知APIServer释放IP（释放IP时获取Pod所属RC，根据是否有对应RC 名称决定是否存放在IP Recycle列表），删除Pause Pod，通知APIServer删除Pod对象。
另外为了防止出现问题，我们在kubernetes中加入了额外的REST API：包括对已分配IP的查询，手动分配/释放IP等。
- Kubernetes + Flannel；
- 基于Docker libnetwork的网络定制；
- Kubernetes + Contiv + kube-haproxy；
- 基于Kubernetes的应用容器IP固定方案。
背景简介
PaaS平台持续部署以镜像方式部署，公司业务域对应平台内的应用。平台应用管理包括应用配置管理以及应用的运行态管理。一个应用的运行态对应kubernetes的一个Replication Controller（后面使用RC简称）和一个Service，应用实例对应kubernetes中的Pod， 我们基于这样的管理方式，需要提供应用之间的相互调用，同时对部分应用要提供基于http/tcp的直接访问。Kubernetes + Flannel
首先说一下Kubernetes Flannel。 Flannel主要提供了跨主机间的容器通信；在kubernetes的Pod、Service模型里，kube-proxy又借助iptables实现了Pod和Service间通信（外部访问Service通过宿主机端口->Cluster IP:Port->Pod IP:Port）。基于这种网络访问功能，我们平台提供了以下功能：
- 基于gorouter提供的平台域名的访问 – watch k8s endpoints event管理router信息；
- 基于skydns并定制化kube2sky组件和kubelet，提供同一命名空间下应用（Pod）之间基于业务域名的访问 - kube2sky基于Kubernetes Service annotation解析并注册域名信息、kubelet设置容器启动时的domain search及外部DNS；
- 实现容器tty访问控制台 - 每台Kubernetes node部署平台组件 tty agent（根据Pod所属node信息，建立对应Kubernetes结点的tty连接）；
网络访问关系图如下：
在Kubernetes Flannel的模型下，容器网络是封闭子网，可以提供平台内部应用之间基于4层和7层的调用，同时对外部提供应用基于域名（工作在七层）的直接访问，但无法满足用户在平台外部需要直接使用IP访问的需求。
基于Docker libnetwork的网络定制
在Flannel网络稳定使用后，开始研究network plugin以使应用服务实例以public IP 方式供用户直接使用。当时Docker的版本为1.8，本身还不支持网络插件，同时Kubernetes本身提供一套基于CNI的网络插件， 但本身有bug [CNI delete invoked twice with non-infra container id #[20379]( https://github.com/kubernetes/ ... /2037 9) ]。于是尝试从docker network plugin的角度入手，尝试结合libnetwork从Docker源码的角度进行定制。整个架构分为三层：
- Client Layer - Docker CLI和Kubernetes（Docker client）；
- Docker Layer - Docker daemon 并在代码层面集成libnetwork（内置OVS driver）；
- Controller Layer - ovsdb-server及network controller（自开发IPAM）；
整个方案包括以下三个流程：
- 启动Docker Daemon：
初始化network controller -> 加载OVS Driver -> OVS Driver调用libovsdb创建docker0-ovs Bridge -> OVS Driver将主机上的一物理网卡attach到docker0-ovs上； - 启动容器：
OVS Driver创建veth pair用于连接network namespaces -> OVS Driver调用network controller获取容器IP和VLAN Tag -> OVS Driver将veth pair的一端添加到docker0-ovs上，并设置VLAN Tag -> OVS Driver设置容器内interface的IP，Mac Address以及路由 -> 设置各network interface为up; - 停止容器：
OVS Driver调用network controller释放容器IP -> 删除network link -> OVS Driver调用libovsdb删除port;
Kubernetes + Contiv + kube-haproxy
随着Docker版本的推进，Docker1.9开始支持Contiv Netplugin，我们开始研究Contiv应用，同时也完成了使用HAProxy替换kube-proxy的开发 [ https://github.com/AdoHe/kube2haproxy ]，并最后采用Docker 1.10 Contiv上线。[Contiv的网络模型在之前的分享 http://dockone.io/article/1691 里已经有详细解释]这里根据我们实际网络访问关系再描述下PaaS在Contiv整体部署结构：
Kube-haproxy替代了kube-proxy，主要是提供服务IP的公共调用，同时避免了容器数量增加后带来的iptables规则的大量增长，方便调试。这里要注意的是Haproxy所部署机器IP和Kubernetes Service IP要在同一网段。
Contiv带来的方便是用户可以根据实例IP直接进行访问；但是在使用过程中出现过一次问题： 机房停电导致了部分IP的分配状态不正确，而且Contiv当时还没有提供查看已分配IP的接口。
应用容器IP固定
Docker 1.10支持指定IP启动容器，由于部分应用对实例IP固定有需求，我们开始着手容器IP固定方案的设计与开发。前面提到应用运行时，对应Kubernetes内一个Replication Controller以及一个Service。应用的重新部署目前采用的策略主要是重建策略。重建的流程包括删除RC及RC下所有Pod，更新并创建新的RC（Kubernetes会根据RC配置产生新的POD） 。
在默认的Kubernetes Contiv的网络环境下，容器（Pod）的IP网络连接是由Contiv Network Plugin来完成的，Contiv master只实现了简单的IP地址分配和回收，每次部署应用时，并不能保证Pod IP不变。所以我们引入了新的Pod层面的IPAM，以保证同一个应用多次发生部署时，Pod IP始终是不变的。
作为Pod层面的IPAM，我们把这一功能直接集成在了Kubernetes。Pod作为Kubernetes的最小调度单元，原有的Kubernetes Pod Registry（主要负责处理所有与Pod以及Pod subresource相关的请求：Pod的增删改查，Pod的绑定及状态更新，exec/attach/log等操作）并不支持在创建Pod时为Pod分配IP，Pod IP是通过获取Pod Infra Container的IP来获取的，而Pod Infra Container的IP即为Contiv动态分配得来的。
定制后的Pod Registry操作流程图：
在原有Kubernetes代码基础上，我们修改了Pod结构（在PodSpec中加入PodIP）并重写了Pod Registry 同时引入了两个新的资源对象：
- Pod IP Allocator：Pod IP Allocator是一个基于etcd的IP地址分配器，主要实现Pod IP的分配与回收。Pod IP Allocator通过位图记录IP地址的分配情况，并且将该位图持久化到Etcd；
- Pod IP Recycler：Pod IP Recycler是一个基于etcd的IP地址回收站，也是实现Pod Consistent IP的核心。Pod IP Recycler基于RC全名（namespace RC name）记录每一个应用曾经使用过的IP地址，并且在下一次部署的时候预先使用处于回收状态的IP。
Pod IP Recycler只会回收通过RC创建的Pod的IP，通过其他controller或者直接创建的Pod的IP并不会记录，所以通过这种方式创建的Pod的IP并不会保持不变；同时Pod IP Recycle检测每个已回收IP对象的TTL，目前设置的保留时间为一天。
这里对kubelet也进行了改造，主要包括根据Pod Spec中指定IP进行相关的容器创建（docker run加入IP指定）以及Pod删除时释放IP操作。 创建Pod的UML时序图如下：
Pod的创建在PaaS里主要有两种情形：
- 应用的第一次部署及扩容，这种情况主要是从IP pool中随机分配；
- 应用的重新部署：在重新部署时，已经释放的IP已根据RC全名存放于IP Recycle列表中，这里优先从回收列表中获取IP，从而达到IP固定的效果。
删除Pod的UML时序图如下：
Pod的删除流程触发情形：删除应用/应用缩容/重新部署重建策略。
整体删除过程为：由PaaSNg或kube-controller-manager调用apiserver Pod Delete并设置DeletionTimestamp，kubelet监听到删除时间并获取GracefulDeletiontime，删除应用容器, 通知APIServer释放IP（释放IP时获取Pod所属RC，根据是否有对应RC 名称决定是否存放在IP Recycle列表），删除Pause Pod，通知APIServer删除Pod对象。
另外为了防止出现问题，我们在kubernetes中加入了额外的REST API：包括对已分配IP的查询，手动分配/释放IP等。
总结
容器IP固定方案已上线，运行基本没问题，但稳定性有待提升。主要表现为不能在预期时间内停止旧Pod，从而无法释放IP造成无法复用（初步原因是由于Docker偶尔的卡顿造成无法在规定时间内停止容器）。我们短期的work around是使用额外添加的REST API手动修复，后期会对于不可预料问题可能导致的IP变化问题，纳入监控并提供自动修复机制，同时IP固定方案本身会继续加强稳定性并根据需求进行优化。Q&A
Q：想问下这个IP外网可以直接访问吗？A：在Flannel网络下不可以直接访问Pod，在Contiv网络下，Pod所分配的网段是在交换机端打了tag的，默认办公网络是可以直接访问的。Q：贵司花了相当大的精力去做容器互通并显著提高了复杂度，如果直接用Kubernetes的host network方式是否可以直接绕过这些复杂点？
A：首先是公司业务的需求。公司有1k+的业务域，运行在不同的Docker容器里，每个业务域的配置基本是固定的，比如Tomcat或Nginx使用的端口，如果使用host network的话，端口冲突是面临的首要问题，整个服务化的管理方式也要改变了。Q：文中提到一个应用的运行态对应Kubernetes的一个RC和Service，RS是否好过RC？
A：我们的Kubernetes版本是1.2，Kubernetes 1.2里面RS这个东西还处于一个非常早期的版本，后面才有的，RS也是推荐的下一代RC。Q：什么样的应用必须要固定IP，是否有其他办法可以避开？
A：业务域之间相互调用，有些业务域要求提供调用方白名单。还有些业务域会需要线上的数据访问，要加入相应的防火墙权限等。Q：固定ip的情况下：容器的IP是通过桥接到宿主机的网桥连接到宿主机网络的吗？
A：固定IP的情况下，仍然是基于Contiv 的网络工作方式，只是在Docker运行时由IPAllocator负责分配好IP，Docker启动时使用--ip的方式绑定该IP。当前OVS的工作方式也是通过ovsbridge连接到宿主机的物理网卡的。Q：固定IP，分配的IP需要和宿主机同网段吗？
A： Kubernetes node主机网段和pod网段是不同的。原则上可以相同也可以不同。Q：Kubernetes支持Docker启动加参数吗，例如--ip？
A：默认不支持，我们对kubelet做了一些修改: 例如通过参数传入vlan id以及根据PodSpec中所分配IP指定docker run的 --ip。Q：据我了解Contiv现在更多的是对CNM的支持， 对Kubernetes的话 你们定制开发的多吗？
A：Kubernetes用的CNI，我们用的是CNM。更多是适应当前的Contiv对相关组件做修改，以及后面的固定IP（把IPAM集成到了Kubernetes APIServer）。
以上内容根据2016年11月8日晚微信群分享内容整理。分享人王成昌，唯品会PaaS平台高级开发工程师，主要工作内容包括：平台DevOps方案流程优化，持续部署，平台日志收集，Docker以及Kubernetes研究。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2016-11-09
本文作者：王成昌
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享( 九十四）：唯品会基于Kubernetes的网络方案演进
