DockOne微信分享( 九十四):唯品会基于Kubernetes的网络方案演进

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
.cn 域名,1个 12个月
简介: 本文讲的是DockOne微信分享( 九十四):唯品会基于Kubernetes的网络方案演进【编者的话】本文主要介绍唯品会云平台PaaS在持续集成和持续部署方面,基于Docker和Kubernetes,对网络方案的选型及应用,以及随着业务需求的增加而经历的网络方案变更,包括:
本文讲的是DockOne微信分享( 九十四):唯品会基于Kubernetes的网络方案演进【编者的话】本文主要介绍唯品会云平台PaaS在持续集成和持续部署方面,基于Docker和Kubernetes,对网络方案的选型及应用,以及随着业务需求的增加而经历的网络方案变更,包括:
  1. Kubernetes + Flannel;
  2. 基于Docker libnetwork的网络定制;
  3. Kubernetes + Contiv + kube-haproxy;
  4. 基于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连接);

网络访问关系图如下:
flannel.png

在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源码的角度进行定制。

整个架构分为三层:
  1. Client Layer - Docker CLI和Kubernetes(Docker client);
  2. Docker Layer - Docker daemon 并在代码层面集成libnetwork(内置OVS driver);
  3. Controller Layer - ovsdb-server及network controller(自开发IPAM);

libnetwork_flow.png

整个方案包括以下三个流程:
  1. 启动Docker Daemon:
    初始化network controller -> 加载OVS Driver -> OVS Driver调用libovsdb创建docker0-ovs Bridge -> OVS Driver将主机上的一物理网卡attach到docker0-ovs上;
  2. 启动容器:
    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;
  3. 停止容器:
    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整体部署结构:
contiv.png

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操作流程图:
pod-registry.png

在原有Kubernetes代码基础上,我们修改了Pod结构(在PodSpec中加入PodIP)并重写了Pod Registry 同时引入了两个新的资源对象:
  1. Pod IP Allocator:Pod IP Allocator是一个基于etcd的IP地址分配器,主要实现Pod IP的分配与回收。Pod IP Allocator通过位图记录IP地址的分配情况,并且将该位图持久化到Etcd;
  2. 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-create.png

Pod的创建在PaaS里主要有两种情形:
  1. 应用的第一次部署及扩容,这种情况主要是从IP pool中随机分配;
  2. 应用的重新部署:在重新部署时,已经释放的IP已根据RC全名存放于IP Recycle列表中,这里优先从回收列表中获取IP,从而达到IP固定的效果。

删除Pod的UML时序图如下:
pod-delete.png

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的网络方案演进

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2月前
|
Kubernetes Cloud Native 网络协议
Kubernetes 高可用性与灾难恢复方案
【8月更文第29天】随着业务的不断增长,保持应用程序的高可用性和灾难恢复能力变得越来越重要。Kubernetes 作为现代云原生应用的主要平台,提供了丰富的工具和方法来保证应用的高可用性以及快速恢复的能力。本文将详细介绍如何利用 Kubernetes 的功能来构建高可用性的系统,并实施有效的灾难恢复策略。
104 1
|
14天前
|
Kubernetes API Docker
跟着iLogtail学习容器运行时与K8s下日志采集方案
iLogtail 作为开源可观测数据采集器,对 Kubernetes 环境下日志采集有着非常好的支持,本文跟随 iLogtail 的脚步,了解容器运行时与 K8s 下日志数据采集原理。
|
14天前
|
小程序 开发者
微信小程序之网络数据请求 wx:request的简单使用
这篇文章介绍了微信小程序中如何使用wx.request进行网络数据请求,包括请求的配置、请求的格式以及如何在开发阶段关闭请求的合法检验。
微信小程序之网络数据请求 wx:request的简单使用
|
1月前
|
Kubernetes 容器 Perl
Kubernetes网络插件体系及flannel基础
文章主要介绍了Kubernetes网络插件体系,特别是flannel网络模型的工作原理、配置和测试方法。
60 3
Kubernetes网络插件体系及flannel基础
|
3天前
|
Kubernetes 监控 测试技术
k8s学习--OpenKruise详细解释以及原地升级及全链路灰度发布方案
k8s学习--OpenKruise详细解释以及原地升级及全链路灰度发布方案
|
29天前
|
vr&ar 图形学 UED
电子沙盘VR模型大屏平板手机微信使用方案
数字孪生电子沙盘和VR模型被广泛应用在房地产等行业,为不同设备定制不同版本的模型是常见做法。然而,通过实时云渲染技术,可以将PC端的VR模型转化为网页版,使用户能够在平板或手机上流畅浏览详细信息,无需开发多个版本。这不仅提升了用户体验,还简化了模型提供商的工作流程,降低了成本。尤其在新楼盘发布时,可通过公众号或广告链接快速吸引潜在客户。成本主要取决于并发用户数及显卡性能要求,但该技术显著提高了跨设备访问的便利性。
32 1
|
2月前
|
小程序 数据安全/隐私保护
Taro@3.x+Vue@3.x+TS开发微信小程序,网络请求封装
在 `src/http` 目录下创建 `request.ts` 文件,并配置 Taro 的网络请求方法 `Taro.request`,支持多种 HTTP 方法并处理数据加密。
Taro@3.x+Vue@3.x+TS开发微信小程序,网络请求封装
|
2月前
|
Kubernetes Cloud Native 网络安全
云原生入门指南:Kubernetes和容器化技术云计算与网络安全:技术融合的新篇章
【8月更文挑战第30天】在云计算的浪潮中,云原生技术如Kubernetes已成为现代软件部署的核心。本文将引导读者理解云原生的基本概念,探索Kubernetes如何管理容器化应用,并展示如何通过实践加深理解。
|
4天前
|
Kubernetes Cloud Native 云计算
云原生之旅:Kubernetes 集群的搭建与实践
【8月更文挑战第67天】在云原生技术日益成为IT行业焦点的今天,掌握Kubernetes已成为每个软件工程师必备的技能。本文将通过浅显易懂的语言和实际代码示例,引导你从零开始搭建一个Kubernetes集群,并探索其核心概念。无论你是初学者还是希望巩固知识的开发者,这篇文章都将为你打开一扇通往云原生世界的大门。
54 17
|
1天前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
13 1