网易云基于 K8S 的容器服务实现

 | 为  |  容  |  器  |  技  |  术  |  而  |  生  |

讲师：陈定斌  / 网易云资深云计算解决方案架构师

编辑：小君君

校对：夏天

网易云很早就开始使用容器，因为 Kubernetes 在容器编排上的规模应用，使得很多服务都将 Kubernetes 作为基础核心的一部分。在长时间的使用过程中，积累了很多 Troubleshooting 的经验，特别是在升级和网络架构演进方面。本次介绍主要针对网易云在 Kubernetes 应用过程中遇到一些典型挑战和思路。

欢迎戳 “阅读原文” 观看讲师【现场视频】，对话框回复【资料下载】获取本文 PPT。

---

网易云容器服务的历史

2015 年网易云容器已经开始启动基于 Kubernetes 0.6 版本的调研，当时 Kubernetes 1.0 还没有正式发布。2015 年 10 月，基于 Kubernetes 1.0 版本，我们发布了容器服务 1.0 版本。2016 年我们启动了基于微服务版本的容器平台开发（基于 Kubernetes 1.3 版本）。在 2016 年 10 月，我们正式发布了容器服务 2.0 版本。2017 年 10 月一直到现在，我们主要用的是 1.8 和 1.9 版本。在发布 2.0 版本后，1.8 和 1.9 版本的使用就正式回归到原生。现在我们已经在私有云上线了基于 Kubernetes 1.9 的正式版本。

网易云主要使用 Kubernetes 1.0、1.3、1.6 和 1.9 版本。因为 1.0 版本比较老旧我们不再使用，现在主要用的是 1.3 版本。1.6 版本主要是为了基于 Kubernetes 1.3 适配基于 VPC 网络的裸机容器而开发上线的。在使用 1.8 和 1.9 版本后，就舍弃了 1.6 版本。现在已在私有云上线了基于 Kubernetes 1.8 和 1.9 的容器服务。目前网易云的容器服务主要还是基于 Kubernetes  1.3 去提供，这就包括经典网络和 VPC 两种类型网络的容器服务。

这是网易云容器服务的整体架构。这张图可以看到左边是容器服务的管理平台，右边是容器实例部分。左边的容器服务管理平台，又分成两部分，包括偏上一部分的基于微服务的公共服务模块，包括服务治理和需要支持的公共服务（包括认证，用户中心等）。另一个模块，是基于 Kubernetes 基础容器服务的管理模块，这个模块主要是用来管理容器配置，容器管理等。

右边模块，可以看到网易云使用两种类型的容器。一种是基于 KVM ，部署在 KVM 云主机内的容器实例。另一种是直接部署在裸机 Kubernetes 的容器实例。同时我们基于 LVS+HAProxy ，再结合  Kubernetes 的 Ingress 来提供面向容器实例的对外负载均衡服务。 容器实例配置管理，可以通过 API 网关调用和 Web 控制台两条路径下发到配置容器。

刚才讲的那些，主要是基于 Kubernetes 1.3。为了使容器网络同时支持经典网络和 VPC 网络，所以我们对于 Kubernetes 的定制改造做的比较深。在同时支持两种网络模式的情况下，我们对容器服务进行了面向公有云的全面改造，既要支持多租户隔离，又要对容器服务实施安全加固还要自己做一些动态资源管理。

同时我们也深度整合了网易云的基础资源，租户的 VPC 内部兼容云主机和容器实例。容器包括基于虚拟 KVM 主机的容器实例和基于高性能物理机的裸机容器。同时，容器服务兼容经典网络和 VPC 网络，支持本地盘和基于 Ceph 的普通云盘，结合了网易云自研的 NLB 提供负载均衡服务。在使用 Kubernetes 容器服务的同时，做了比较多的性能优化和功能增强。

首先在 VPC 网络内部，网易云能支持的集群规模可达 3.5 万。在整个 Kubernetes 做配置和管理时会对整个调用链路进行优化。同时也实现了一些高级有状态的服务，并且支持数据自动迁移和容器垂直扩容。

容器网络

现在介绍支持 VPC 网络的容器实例部署。首先介绍一下 VPC 网络，它属于公有云平台的一个基础部分。用户在使用 VPC 网络时，可完全构建一个隔离的网络空间。租户在这个空间内，可以自定义它的子网地址、地址段、还有路由表。同时通过配置安全组的规则，实现网络访问控制，所以它具有一个完整隔离网络的优势，并能支持灵活配置和安全控制。

这张 PPT 中左边图主要是裸机容器实例，裸机设备使用两个接口，一个接口是直接打通到 Kubernetes Master 网络，Kubernetes Masber 通过这个管理口，去下发配置来创建裸机容器实例。裸机容器实例通过 veth pair 和 OVS datapath 网络打通容器流量就可以通过 OVS 进入到虚拟网络中。容器流量可进入到 VPC 网络内。

右图是基于 KVM 云主机内部的容器实例，在部署容器时，首先会去创建一个云主机。这个云主机，会分配一个私网地址，将这个地址通过 VPC 网关和 Kubernetes Masber 打通，以此作为管理地址。Kubernetes Masber 通过这个地址下发到 KVM 云主机内部配置容器实例。通过云主机的虚拟网卡出去到达宿主机上的虚拟交换机，再通过虚拟交换机进入到虚拟网络。所以 KVM 云主机容器和裸机容器在 VPC 中可完全通过私有网络互连。它和云主机之间是一个完全扁平的网络(两者之间是等价的)。

这张图，是如何配置 Kubernetes 和基础网络，云网络服务做了一个适配，支持容器网络和正常云主机 VPC 网络。首先 Controller 模块是我们自己做的，这个模块会监听 Kubernetes Pod 的创建和删除。当 Pod 创建或删除操作的事件触发时就会调用基础服务的云服务模块以此来创建或删除 Port，并将这个 Port 信息传递给 Kubernetes Master。而 Node 节点上的 kuberlet 模块会监听 Master 上的 Pod&Network 配置。

当事件触发后，通过本地的 NetEase CNI Plugin 模块调用基础服务的云网络模块，将这个 Port attach/detach 到容器实例。同时调用云网络模块，将分配的的私有网络 IP 地址通过 DHCP 配置到虚拟网卡上，然后下发初始路由到 Node 上。

最后基于这种扁平化云网络，租户可以根据应用的需要选择具体的部署实例，这样可以更加灵活，应用部署会更加多样化。对于部分租户，当在云内部署时，它的应用可以支持部分容器化，这样就可以实现整体向容器化的过渡。所以对于很多应用来说，更愿意选择支持云主机和容器这两种在云内的网络模式。

负载均衡

网易云提供的容器负载均衡，主要是对内负载均衡和对外负载均衡。这一页主要是对内的负载均衡。我们直接使用 Kubernetes 基于服务发现的负载均衡模式。租户在配置创建 Service 时，会生成一个虚拟私有 VIP，租户去访问这个 VIP 时，会命中一条 iptables 规则。

内部负载均衡是通过这种规则来配置实现。为了更好的在应用部署初始化过程中感知服务网络，可以结合 DNS 来提供内部域名服务，而容器应用不需要获取具体的 VIP。根据约定好的域名规则去访问其他服务。在对于容器集群这种无状态的节点，我们是建议使用 Service 内部负载均衡。

网易云对于容器提供的对外负载均衡，是基于自研的 NLB 结合 Kubernetes Ingress 。正常的负载均衡，是通过 NLB Manager 模块（负载均衡控制模块）将负载均衡配置下发到 NLB Cluster 上。对于容器实例，我们基于自己实现的 NLB Controller 模块，去监听 Kubernetes Ingress 配置。租户去配置 Ingress 时，可以选择公网类型或机房网的类型网络。

假如租户选择公网，此时 Kubernetes 向云网络服务请求分配一个公网地址。这个公网地址可以作为负载均衡实例的 VIP。租户将 Ingress 和 Service 做一个对应，Service 对应后端 Endpoint 的私网地址，作为负载均衡的 RealServer，通过 NLB Controller，在负载均衡实例上配置一个完整负载均衡，实现对外的负载均衡服务。

通过我的描述，也能了解到我们的负载均衡服务，无法同时去兼容容器和云主机。负载均衡如果不全是容器就全是云主机。因此基于 Ingress 的扩展能够支持 Kubernetes 版本。

这一页是对外公网类型的负载均衡的架构。从图上看，左上角是负载均衡集群。负载均衡，我们主要是通过 LVS +HAProxy 提供负载均衡。右侧是第三方服务，主要是为了监控负载均衡集群的服务状态，做一些日志和告警。下面这部分是管理模块，正常用户可以直接通过控制台去下发，或者通过 API Gateway 下发配置到基于云主机的负载均衡实例上，也可以通过调用 Kubernetes 来配置基于容器的负载均衡实例。

所以这三种配置方式，可以看出来我们是如何兼容负载均衡，如何提供容器、云主机负载均衡的模型。同时基于 DPDK 实现的高性能负载均衡，在数据上，用户的流量是从客户端通过 Internet 到 NLB 网关。在网关上，会将公网地址映射到一个私网地址，通过私有网络将流量路由到负载均衡实例上，利用负载均衡算法，再选择云主机或容器私有地址作为该请求的最终目的地址。

K8S 升级——1.0~1.3

网易云在进行容器服务开发时，依赖模块会比较多。基于现在生产状况以及我们实际的容器服务版本和基于 Kubernetes 1.0 到 1.9 版本现状。因为版本跨度太大，所以在容器服务整体升级上几乎无法实现。

今天是主要讲 Kubernetes 升级的一些经验，从 1.0 到 1.3。我们提供基于微服务版本的容器服务，从整个产品服务来看，改动是很大的。特别是对于 Kubernetes 原有的使用方式改造，产品使用形态是按照自己的产品设计去强行修改。

所以在面对差异版本时，包括技术架构、表结构、数据等，都很难做到兼容，由此造成的升级难度很大。从整体上来看，整体服务迁移主要涉及前端和 Web 服务，NCE 后端包括 Kubernetes 模块、NLB 的负载模式均衡、日志和性能数据等。

因为涉及的模块非常多，所以整体集群非常大。在这种情况下，我们在自己的测试环境上，做了一些针对 Kubernetes 自身升级遇到的问题。

Kubernetes 主要包括程序和元数据两个部分（基于 1.0 和 1.3）。首先来讲一下程序的升级。程序涉及到 Master 和 Node。在进行程序升级时，通过替换二进制文件实现升级，还要注意对于进程服务替换后，对应的初始化脚本升级。

另外，涉及到元数据的迁移和改造。因为在 1.0 版本时，Kubernetes 还没有像 Service 和 Ingress 的概念资源，所以一部分是对已有数据进行升级，包括 Namespace、Pod、Node、Deployment 等。

Kubernetes 存储的元数据是通过 etcd 的 Key-Value 的存储方式，而且 value 本身也支持表结构。所以它的升级，对于数据的处理是非常复杂的，而且要补齐包括 Service，Endpoint，Ingress 等资源的数据结构。在容器服务最早的 1.0 版本中，一个 Namespace 只对应一个用户。基于 2.0 版本时，一个用户可以有多个 Namespace。

对于这种模块，我们需要去对 Namespace 的名字和存储格式都进行修改。以上都是对于 Kubernetes 本身升级部分。对于除 Kubernetes 外的其他部分，最大的问题是在  Docker 升级及升级后 Docker 容器实例与 Kubernetes 兼容性。目前来看，整个社区都没有解决方案去升级 Kubernetes+Docker。

故障修复

现在说一下，网易云针对容器故障场景的应对措施。第一，容器级故障以及节点级故障。在容器级别故障下，我们会采取自动重启容器实例。如果我们对容器探测出现异常，我们会去触动自动修复。容器实例相对于虚拟机启动，耗时更短，业务感知度会比云主机低很多。

第二，节点级故障。比如服务器宕机故障，我们应对措施是设置 Node 心跳定时探测。如果 Node 一旦有心跳告警信息，我们会触发节点上的容器进行自动重建，主要是针对有状态容器的自动迁移。

这是网易云最开始的容器服务处理节点级故障。首先在 Node 节点上有配置机器的心跳检测。一旦心跳持续丢失识别出节点故障，会上报给 Kubernetes，Neatease Controller 模块会订阅 Master。关于节点故障时间触发基础服务的网络模块和存储模块会 detach 掉容器的网络配置和容器使用的系统盘和数据盘，同时会调度在新节点创建新的容器实例，将老的网络和存储配置重新 attach 到新的容器实例中。

从这些可以看到，最早改造的有状态容器实例迁移的方式与现在的原生 Kubernetes 使用的容器方式是有差异的。这就是在 Kubernetes 1.8 和1.9 时我们要去支持 Kubernetes 本身的一些配置理念原因。

我们不会让容器的系统盘直接外挂，而是使用本地的容器系统盘，容器不再是迁移的概念，而是变成完全新建的概念。新建即可用，不变的是网络配置和数据盘保留。它会直接使用服务镜像去创建一个新的容器节点，再重新挂载到老的容器实例数据盘中以此来实现回归到原生的方式。

 

结语

网易云在容器服务的管理结合微服务架构的探索涉及持续了很长时间，沉淀的经验也都是非常宝贵的，在未来网易云也将持续拥抱 Kubernetes，探索和完善更加丰富成熟的容器服务平台。

陈定斌  / 网易云资深云计算解决方案架构师

从事网易云基础服务解决方案工作，主要面向基础架构、虚拟化项目设计和部署。目前关注企业应用如何通过容器、Kubernetes、Cloud 等技术和解决方案解决实际问题，帮助企业从传统 IT 架构向云演进、并更好的利用云带来的益处来促进核心业务发展。