作者简介
陈丹双,携程高级工程师,毕业于复旦大学,积累多家公有云对接经验,持续探索混合云,关注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直接连接这些实例。