干货 | 携程混合云之kubernetes@AWS揭秘

作者简介

 

陈丹双，携程高级工程师，毕业于复旦大学，积累多家公有云对接经验，持续探索混合云，关注kubernetes、docker等容器技术。

一、引言

随着携程国际化战略的实施和业务海外的部署，混合云已经达到了一定的规模。为了支持容器，我们在AWS上部署了kubernetes。主要是弹性发布的考量。

应用交付效率上，初始化一台虚拟机在分钟级别，涉及操作庞杂，除了启动虚拟机，还需要进行应用环境的安装，而拉起一台容器的时间可以控制在秒级。

运维管理效率上，虚拟机的维护比容器要复杂得多，特别是在目前有着多个公有云合作厂商的情况下，工作量和复杂程度爆增。以镜像为例，自定义的镜像无法在不同公有云厂商之间进行统一，比如AWS的C5等系列要求我们安装ENA（Elastic Network Adapter）增强联网的驱动。目前我们在几家公有云上的自定义镜像是也是保持着异构的状态。

所以，引入了混合云的容器发布。借助着业务在AWS的应用部署，有了Kubernetes@AWS的主题。

 

二、为什么在AWS上自己搭建kubernetes

首先是网络上的重要考量，目前适配携程的技术体系需要满足两个网络适配的要求。

IP直连：存在应用互访是通过IP进行访问的情况，而且携程的应用并非全是跑在kubernetes集群中，所以为了保证全局应用的可用性，就需要容器的IP是kubernetes集群外可见的IP。

IP固定：假设应用在重新发布时IP发生变化，那必须有良好的机制通知各个相关的系统。但是目前存在有运维等系统的架构是基于IP固定这一前提条件。要完善这种架构不是一时之力，所以我们在这期项目的折中方案是适应当前的技术架构，保证容器应用在发布新版本、宿主机故障重新拉起容器时，IP保持不变。

这两个需求都不是kubernetes可以原生支持的，kubernetes提供了Service、Ingress等服务暴露的方法，但是不能完全满足我们上述的网络需求，社区现成的flannel、calico等容器网络方案不能采用，需要进行定制化。

同时，我们也针对kubernetes做了调度等层面的自定义开发。虽然AWS也发布了kubernetes产品——EKS，是一套打通公有云的方案，但也意味着失去了自定义开发及控制平面运维管控的能力。所以，我们也没有采用公有云的原生kubernetes产品。

出于对定制化能力和控制平面管控的需求，也为了与私有云IDC的技术栈保持一致，尽量减少运维成本，进行过一系列的调研之后，我们最终选择自己在云上搭建kubernetes集群。

 

三、如何在AWS上自己搭建kubernetes

主要从网络、镜像、日志监控这几个组件讲讲我们的方案选型及设计。

 

3.1 网络

容器网络的方案我们是基于VPC（Virtual Private Cloud）和弹性网络接口（Elastic Network Interface，ENI）进行实现的。

VPC是一个用户在公有云上自建的隔离的虚拟网络，可以自定义地址空间段。我们以一个地域（Region）为例，一个VPC在其中一个可用区内的架构大致如下：

每个可用区内有一个公有子网和一个私有子网。

公有子网：想对internet直接暴露的服务一般部署在公有子网，给实例绑定一个弹性IP（公有IP），Internet即可通过这个公网IP进行访问。公有子网里的缺省路由是Internet网关，由Internet网关实现VPC与Internet之间的通信。其中公有子网里有个NAT网关，有对应的私有IP和公有IP。NAT网关的作用是允许私有子网中的实例连接到Internet或其他AWS服务的能力，但能避免Internet直接连接这些实例。