基于Kubernetes的私有容器云建设实践(2)

容器云第一步是实现应用的全生命周期管理,让应用实现秒级的上线、回滚、升级、扩容/缩容、下线.由于历史的原因,有些应用的配置和环境耦合在一起,有的应用是对于外部依赖是硬编码(例如服务方的IP地址)等,这些应用在迁移至容器云之前需要进行改造.

容器云要实现多数据中心多活,以保证数据中心级的高可用性.对于弹性扩容,我们的计划是先实现手动扩容,再实现自动扩容; 对于自动扩容,先实现基于CPU/Memory的自动扩容,再实现基于Custom Metrics的自动扩容.与大多数构建容器云的方式不同,我们首先解决生产环境的运维自动化的问题,其次再解决容器的构建问题(即CI/CD).我们的网络选型是flannel,万兆网络,flannel虽说有性能损失,但远能满足我们的实际需要.存储我们使用Ceph的RBD方式,使用一年多来,RBD的方案非常稳定.Ceph FS的方式我们也有尝试,但是由于团队精力有限和可能的风险,一直没有正式使用.

高可用基础设施

容器云要实现高可用的基础设施,多维度保证应用/服务的高可用性：

在应用层面,每个应用有至少3个副本,通过Kubernetes ReplicationController/ReplicaSets来保证.强制每个应用暴露健康检查接口,通过设置liveness和readness保证应用异常后能够被及时的发现,从而用新的实例代替.

Kubernetes的组件也要实现高可用,特别是ETCD集群的高可用,定期备份ETCD的数据是个好习惯.

为了保证数据中心级别的高可用,我们在每个数据中心部署了一套Kubernetes集群,每个数据中心能够独立存活,多个数据中心互相灾备.

计算资源QoS与超卖

由于资源限制,技术人员往往过于关注单机的资源利用率.Docker(Cgroup、Namespace)提供的资源共享与隔离的机制,让我们对资源利用率有了新的认识,特别是使用容器编排引擎后,我们对资源的理解应该在集群维度进行考量,而不是在考虑单机的利用率.同样,在整个数据中心,甚至多个数据中心进行资源利用率的综合考量也是非常必要的.

在提高资源利用率、降低成本的同时,需要在服务的QoS与优化资源利用率之间有个平衡.我们的原则是在保证服务质量的同时,尽量提高资源的利用率.

根据Kubernetes的资源模型,在Pod level的QoS分为三个等级：Guarantee、Burstable、BestEffort,我们也是依照这三个级别对应我们应用的优先级来制定资源超卖的标准.

我们对应用设置的QoS标准：

• Kubernetes自带的组件使用Guarantee
• 重要的组件和应用,比如ZooKeeper、Redis,用户服务等使用Guarantee
• 普通的应用(Burstable)按照重要性分级,按重要程度CPU分为2,5,10三个超卖标准,10倍超卖适合boss后台类的应用,大多数适合访问量不高.内存使用固定的1.5倍超卖标准.

有一点需要特别注意,在生产环境中,不要使用BestEffort的方式,它会引发不确定的行为.

容器云管理平台

随着越来越多的应用迁移到容器云中,需要建立一个可视化的管理系统,我们使用Kubernetes原生API搭建一套Web管理系统,通过对Namespace/ResourceQuota/Deployment/Service/Endpoint等API的调用实现资源配额的划分和应用生命周期的管理.

容器云平台在易用性方面最大的挑战是Troubleshooting的环节,容器云最终是要交付开发人员使用,他们对Kubernetes并不了解,这让Troubleshooting的环节充满挑战,我们现在只是想通过websocket将kubectl exec的console展示给用户,或者让用户在日志中心(EFK)中查看日志,还没有更好的方案,如果各位有更好的方案,请不吝赐教.

容器云未来要实现整个数据中心的可视化,让运维对所有的数据中心的实时运行情况一目了然,当然,实现这一目标有相当的难度.

容器云的监控采用Heapster的方案,正在向Prometheus方式转变.

日志收集是主流的EFK的组合方式.

容器云管理系统的基本功能如下图所示：

日志收集方案如下图所示：

我们为Java应用提供了一个公共日志组件——Appenders,它会将Java的日志流式输出到Fluentd中转,输出到Fluentd中转的原因是与现有的日志中心并行运行.其他的部分跟主流的EFK模式没有任何区别.使用DaemonSet运行Fluentd和Fluentd与应用以Sidecar的方式进行日志采集也是比较好的选择.

在容器时代,CloudNative应用是必然的选择,构建云原生应用的原则请参考12因子.

容器云管理系统自身也是CloudNative应用,它同样运行在Kubernetes中,与传统的上线工具不同的是,它能够进行自我生命周期管理.

Container based、Mircoservices Oriented是Cloud Native倡导,只有应用向Cloud Native转化,才能更好的发挥容器云的效力.

CI/CD建设

按照我们预先的Roadmap,先解放生产环境的运维工作,再解决应用的构建、集成的问题.现在,容器云的管理系统基本上替代了日常维护的手工操作,频繁的手工触发构建成了容器云推进的瓶颈,所以,构建CI/CD平台变得非常紧迫.

经过前期调研,我们决定使用Gitlab + Jenkins + Docker Registry的技术栈构建CI/CD平台.为了统一技术标准和尽量减少构建过程中的不确定性,我们采用自动生成Dockerfile的方式,而不是让开发自己编写Dockerfile.我们采用稳定主干的方式,MR自动触发构建过程,经过单元测试,打包,编译和Docker构建,容器云的界面会实时显示构建的过程,在构建结束后,用户会收到构建的结果的邮件.最终,CI产出的Docker镜像会被推送至QA环境的Registry上.

对我们来说,CI/CD最重要和最难的环节是自动化测试,尤其是自动化集成测试,我们正在努力解决.

CI的过程我们还做了代码的依赖库检查,代码版本追踪和Docker镜像自描述等,让Docker镜像从产生开始,在测试,生产测试,生产等每个环节都是可追溯的.这样便于我们查找问题和对CI的过程进行持续的改进.

对常用技术栈和配置进行标准化也是CI建设的一个重要目标.保证CI产出的镜像的质量(类似次品率)是对CI系统考核的重要标准.

下图是我们CI/CD平台的工作流示意图：

下图展示了整个部署流水线,镜像从构建到生产部署的全过程,以及过程、结果的反馈：

遇到的问题和挑战

到目前为止,回顾整个容器云的构建过程,来自技术上的挑战并不多,但是也踩了一些坑.

遇到过RBD盘被锁住,新产生的Pod无法挂载的情形,解决办法是将RBD盘手工解锁,新的Pod会自动挂载.

（编辑：ASP站长网）