滴滴弹性云Kubernetes实践

当前Kubetnetes已经成为容器编排领域事实的行业标准，越来越多的公司选择使用Kubernetes来搭建其容器云平台。本次分享主要介绍滴滴弹性云在围绕Kubernetes打造企业级私有云过程中的一些实践经验和教训，为同样正走在企业云化转型道路上的朋友们提供一些启发和帮助。
当前滴滴国际化业务全部运行在弹性云平台上，国内的顺风车，金融，汽车后市场、企业安全、客服以及专车快车等业务的全部或部分模块也运行在我们的平台上。平台规模大约1K+宿主，2W+容器实例。 
今天的分享我主要聚焦一些我们平台相对有特色的地方，希望能给各位带来一些启发。

 

网络模型

首先介绍一下平台的网络模型，我们最开始使用的是Flannel，这种网络模型的问题大家应该都有体会，这里不多说。 
之后我们过度到了使用ONOS为主体集中式SDN网络，这种网络模型的功能可以说非常丰富，容器可以在overlay网络上随意漂移，且在容器名不变的情况下保证IP不变。于此同时容器IP相互独立，和物理网络双向互通，所以设置各类白名单也和物理机完全一致，不占用物理网络IP资源。利用Kubernetes的CNI可以很方便的为容器配置网络，用户使用起来和物理机无异。
但是此种模式的最大问题是：集中式的网络控制器在出现故障或是任何一点性能问题时，都会对集群的稳定性造成显著的影响。在经历了一些稳定性问题后，我们将网络模型演进到了当前的使用物理网络的模式。在此种场景下，容器只能在同一个接入交换机下的宿主上进行漂移，所以我们在部署新集群的时候每个交换机下的宿主数量尽量趋同。 
同时我们预先为每个APP提供一个IP池，用户在创建容器之前可以先申请一个IP池（默认30个IP，未来创建的容器的IP不会超出这个IP池的范围），使用平台提供的白名单功能，预先将IP池内的IP自动化的加入到MySQL或Codis这样的公共服务白名单中，最后再启动容器。这样就实现了容器启动后不会因为连不上数据库而报错，或者扩容后新容器异常。当然，IP池是能够随着业务的变化而随时扩缩容的。调度系统在预分配IP池的时候也会根据各个tor IP的实际使用量均匀分配。 
值得一提的是我们利用Kubernetes提供的nodeAffinity和podAntiAffinity实现同一服务、同一产品线、同一服务等级等多种维度下的容器实例平均分配到不同的接入交换机和宿主下的目的。

 

服务发现