DockOne微信分享(一二〇):基于Kubernetes的私有容器云建设实践

  • 时间:
  • 浏览:1

Swarm当时是0.4版本,功能还相对简单,优势是技术栈比较简单,小团队即可驾驭,否则考虑到它都在稳定版,确实它发展加快速度,否则没哟处置亲戚亲戚亲们现有的问题报告 报告 ,就说 我Swarm不被优先考虑。Mesos当时是0.23版本,它可以 胜任大规模场景的容器编排,偏重于资源抽象,与亲戚亲戚亲们大多数是Java Web的应用的场景不符,另外,Mesos技术栈与亲戚亲戚亲们现有技术栈差别太少,不得不放弃这个 选择。自主研发容器编排引擎亲戚亲戚亲们也考虑过,否则经过认真的探讨,自研编排引擎对标一四个 开源的组件的功能,研发投入前要就说 我的成本,否则结果并只有达到预期,投入产出比低。另外,容器云作为底层的基础设施,选择更要慎重,否则自研项目失败,否则会离主流的容器技术没哟远,否则成本太高,就说 我自研的路线也被否定。Kubernetes是亲戚亲戚亲们的最终选择,它当时是1.0.2版本,否则是"Production Ready",亲戚亲戚亲们选择Kubernetes的最主要的原因分析是它理念的先进,否则非常适合亲戚亲戚亲们公司的主流应用,Java Web应用都在Long time running的任务,Kubernetes的"Replication controller"对它支持非常好。Kubernetes以应用为中心的理念和社区的活跃度更是坚定了亲戚亲戚亲们的选择,历时一四个 月的技术选型终于落下帷幕,亲戚亲戚亲们决定使用Kubernetes构建亲戚亲戚亲们的私有容器云平台。

理论基础和原则

在亲戚亲戚亲们决定使用Kubernetes的作为容器编排引擎后,关于选型的争论持续了很长的一段时间,当时国内Kubernetes的使用者还比较少,没能找到成功的案例。亲戚亲戚亲们前要深入的研究Docker, Kubernetes相关的容器技术,确保亲戚亲戚亲们的决策是正确的,这对亲戚亲戚亲们构建容器云至关重要。经过就说 我的调研和讨论,亲戚亲戚亲们发现容器云的是有一套完成的理论基础支撑的,那此理论又引申出亲戚亲戚亲们构建容器云的原则:

按照亲戚亲戚亲们预先的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平台的工作流示意图:

否则资源限制,技术人员往往过于关注单机的资源利用率。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的方式,它会引发不选择的行为。

容器云管理平台

日志采集方案如下图所示:

以上内容根据2017年4月25日晚微信群分享内容采集。分享人李大伟,易宝支付有限公司,架构师,主要负责易宝容器云的建设与落地,DevOps平台建设和理念推广。北京大学硕士,7年工作经验,有坚实的理论基础和多年的底层开发经验。开源爱好者,现专注于容器技术与DevOps实践,对Docker、 Kubernetes、DevOps、微服务等有浓厚兴趣。DockOne每周都在组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题否则想分享的话题可以 给亲戚亲戚亲们留言。

遇到过RBD盘被锁住,新产生的Pod无法挂载的情况汇报,处置方式是将RBD盘手工解锁,新的Pod会自动挂载。Kubernetes的一四个 Bug,Kubernetes的ReplicaSets名称是根据Deployment的PodTemplate的摘要产生,使用的Adler算法,Hash碰撞非常频繁,会在升级过程中,Deployment只有创建最新的ReplicaSets而造成升级失败。处置方式是讲adler算法换成FNV算法,来减少Hash碰撞的频率,这显然都在最终的处置方案,最终的方案还在持续讨论中,有兴趣的亲戚亲们可以 参与:https://github.com/kubernetes/community/pull/384,https://github.com/kubernetes/ ... 29735否则一个劲没来得及迁移Harbor,亲戚亲戚亲们一个劲直接使用Docker registry 2.1版本作为私有镜像仓库,使用Restful API时,_catalog默认返回字母序的前3000个镜像,客户端前要处置分页的问题报告 报告 。应用向容器云迁移是容器云建设过程中花费最多精力的地方,否则前要适应容器云面前的理念转变和对现有应用改造进行改造,迁移过程中受到了就说 我挑战,最大的挑战是Dubbo应用的迁移问题报告 报告 ,否则Flannel的Overlay网络使容器化的Dubbo应用只有与Overlay网络之外的应用连通,最后亲戚亲戚亲们修改了网络策略,使得Dubbo的应用可以 无缝的迁移到容器云中。下一阶段容器云工作的重点,是推动应用向Cloud Native和微服务化方向改造。容器云面临的最大挑战来自于理念转变,容器技术改变了软件交付的生态,容器时代前要技术人员以新的理念构建应用,怎么让技术人员顺利的完成理念的转变是每个容器云的建设者们前要认真考虑的问题报告 报告 。

Q&A

Q:请教一下处置CI时,比如集群自动化部署方面的粒度是怎么的?比如修复一四个 bug改了一四个 class文件,否则本地测试完前一天前要到线上部署进AB测试,没哟就直接通过CI自动部署到集群服务器吗?

随着太少的应用迁移到容器云中,前要建立一四个 可视化的管理系统,亲戚亲戚亲们使用Kubernetes原生API搭建一套Web管理系统,通过对Namespace/ResourceQuota/Deployment/Service/Endpoint等API的调用实现资源配额的划分和应用生命周期的管理。容器云平台在易用性方面最大的挑战是Troubleshooting的环节,容器云最终是要交付开发人员使用,亲戚亲们对Kubernetes并不了解,这让Troubleshooting的环节充满挑战,亲戚亲戚亲们现在就说 我想通过websocket将kubectl exec的console展示给用户,否则让用户在日志中心(EFK)中查看日志,还没哟更好的方案,否则各位有更好的方案,请不吝赐教。容器云未来要实现整个数据中心的可视化,让运维对所有的数据中心的实时运行情况汇报一目了然,当然,实现这个 目标有相当的难度。容器云的监控采用Heapster的方案,正在向Prometheus方式转变。日志采集是主流的EFK的组合方式。容器云管理系统的基本功能如下图所示:

原文标题:DockOne微信分享(一二〇):基于Kubernetes的私有容器云建设实践

实现运维自动化是亲戚亲戚亲们立项之初最主要的目标,而它又是实现顶端目标的基础。这个 因素直接决定了亲戚亲戚亲们的技术选型。

技术选型

亲戚亲戚亲们是在2015年6月份现在开始了了英文调研技术,2015年8月份现在开始了了英文容器云立项,首没能面对的问题报告 报告 ,就说 我怎么进行容器编排引擎的选型,可供选择的有Swarm,Mesos,Kubernetes,甚至自主研发集群编排,亲戚亲戚亲们认真调研了每三种方案:

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

本文来自云栖社区媒体商务合作伙伴Dockerone.io,了解相关信息可以 关注Dockerone.io。

本文作者:李大伟

原文发布时间为:2017-05-19

  • 不可变基础设施,是利用Docker镜像的不可变性,以更加便捷的方式维护基础设施:当基础设施损坏否则变更时,以直接替换的方式达到目的,而都在通过修缮损坏的基础设施,没哟做前要替换的成本足够低,Docker显然做到了这个 点;对于否则运行的Docker容器,否则它一个劲跳出异常,不再是传统ssh上去调试的方式,应该是杀掉这个 容器,重新启动一四个 新的容器;替换操作具有快速和可重复的底部形态,任何操作可以 随时回滚,安全可靠;对于生产环境的运维,不可变基础设施的理念尤为重要,就说 我事故都在在生产环境中直接修改造成的。
  • 基础设施即代码,管理基础设施像管理代码一样,每个基础设施都在“可描述”的,累似 Kubernetes中的Node概念,亲戚亲们也应该作为“代码”的一次要以代码的方式进行管理。
  • 可编程的基础设施,基础设施不仅仅是提供计算、存储、网络资源,前要为上层应用提供可编程的接口,让上层应用可以 更加灵活的使用基础设施,容器云从立项之初就考虑到了这个 点,容器云平台有一套全部的对外Restful API,可供上层应用,甚至组织组织结构应用调用。
保证构建容器云的过程可以 正确的进行,还前要其他原则,”Build once,Run anywhere",一四个 Docker镜像要贯穿QA到生产环境的每个环节,不允许QA和生产的镜像一个劲跳出不一致的情况汇报。"All in one",对于Java Web应用,否则历史原因分析,否则多个Web App运行在同一四个 Tomcat中,要求每个Docker镜像中只运行一四个 Web App。以应用为中心,是亲戚亲戚亲们最重要的原则,也是建设容器云的出发点,这个 原则确保亲戚亲戚亲们关注的重点是应用,而都在进行计算资源的抽象和资源的调度,亲戚亲戚亲们的理想目标是,在“优雅地“管理应用的整个生命周期一同,顺便做好资源抽象,提高资源的利用率。分层治理,基础设施的治理由容器云完成,上层应用的治理由应用治理层负责,从SaaS,到PaaS,再到CaaS,分层治理,各层通过接口相互调用,层与层之间互不侵入。

以Kubernetes为中心构建容器云

亲戚亲戚亲们为Java应用提供了一四个 公共日志组件——Appenders,它会将Java的日志流式输出到Fluentd中转,输出到Fluentd中转的原因分析是与现有的日志中心并行运行。其他的次要跟主流的EFK模式没哟任何区别。使用DaemonSet运行Fluentd和Fluentd与应用以Sidecar的方式进行日志采集也是比较好的选择。在容器时代,CloudNative应用是必然的选择,构建云原生应用的原则请参考12因子。容器云管理系统自身也是CloudNative应用,它同样运行在Kubernetes中,与传统的上线工具不同的是,它可以 进行自我生命周期管理。Container based、Mircoservices Oriented是Cloud Native倡导,只有应用向Cloud Native转化,可以 更好的发挥容器云的效力。

CI/CD建设

容器云的目标决定了亲戚亲戚亲们面对的是应用的管理,即应用对应的docker容器的管理,这就要求亲戚亲戚亲们要以Kubernetes为中心构建容器云,而都在以docker为中心。Docker只作为应用打包、传递、运行时的工具,所有的API都在面向Kubernetes进行设计。容器云要实现高可用的基础设施,可以 支持多个数据中心。对于应用,要有多维度的高可用保证,要贯通部署流水线,通过CI/CD实现快速交付,另外,容器云的建设肩负的额外目标是要为未来2~4年的技术发展做铺垫,为应用的CloudNative改造和整个技术团队的DevOps实践奠定基础。容器云第一步是实现应用的全生命周期管理,让应用实现秒级的上线、回滚、升级、扩容/缩容、下线。否则历史的原因分析,其他应用的配置和环境耦合在一同,有的应用是对于组织组织结构依赖是硬编码(累似 服务方的IP地址)等,那此应用在迁移至容器云前一天前要进行改造。容器云要实现多数据中心多活,以保证数据中心级的高可用性。对于弹性扩容,亲戚亲戚亲们的计划是先实现手动扩容,再实现自动扩容; 对于自动扩容,先实现基于CPU/Memory的自动扩容,再实现基于Custom Metrics的自动扩容。与大多数构建容器云的方式不同,亲戚亲戚亲们首先处置生产环境的运维自动化的问题报告 报告 ,其次再处置容器的构建问题报告 报告 (即CI/CD)。亲戚亲戚亲们的网络选型是flannel,万兆网络,flannel虽说有性能损失,但远能满足亲戚亲戚亲们的实际前要。存储亲戚亲戚亲们使用Ceph的RBD方式,使用一年多来,RBD的方案非常稳定。Ceph FS的方式亲戚亲戚亲们都在尝试,否则否则团队精力有限和否则的风险,一个劲没哟正式使用。

高可用基础设施

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

在应用层面,每个应用有至少四个 副本,通过Kubernetes ReplicationController/ReplicaSets来保证。强制每个应用暴露健康检查接口,通过设置liveness和readness保证应用异常里可以 被及时的发现,从而用新的实例代替。Kubernetes的组件也要实现高可用,怪怪的是ETCD集群的高可用,定期备份ETCD的数据是个好习惯。为了保证数据中心级别的高可用,亲戚亲戚亲们在每个数据中心部署了一套Kubernetes集群,每个数据中心可以 独立存活,多个数据中心互相灾备。

计算资源QoS与超卖