加入收藏 | 设为首页 | 会员中心 | 我要投稿 宁德站长网 (https://www.0593zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 安全 > 正文

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

发布时间:2021-01-16 15:57:28 所属栏目:安全 来源:网络整理
导读:副标题#e# 《基于Kubernetes的私有容器云建设实践》要点: 本文介绍了基于Kubernetes的私有容器云建设实践,希望对您有用。如果有疑问,可以联系我们。 本次分享为大家介绍易宝支付私有容器云从0到1的建设之路.包括技术选型、理论基

由于资源限制,技术人员往往过于关注单机的资源利用率.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会自动挂载.

(编辑:宁德站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!