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

  • 时间:
  • 浏览:1
  • 来源:uu快3官网pk10_uu快3官方邀请码_官网ios版

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

以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建设的3个 重要目标。保证CI产出的镜像的质量(类事次品率)是对CI系统考核的重要标准。下图是有之后 人CI/CD平台的工作流示意图:

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

日志派发方案如下图所示:

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

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

本文作者:李大伟

肯能资源限制,技术人员往往过于关注单机的资源利用率。Docker(Cgroup、Namespace)提供的资源共享与隔离的机制,让有之后 人对资源利用率有了新的认识,不得劲是使用容器编排引擎后,有之后 人对资源的理解应该在集群维度进行考量,而删改删改都是在考虑单机的利用率。同样,在整个数据中心,甚至多个数据中心进行资源利用率的综合考量也是非常必要的。在提高资源利用率、降低成本的一齐,前要在服务的QoS与优化资源利用率之间有个平衡。有之后 人的原则是在保证服务质量的一齐,尽量提高资源的利用率。根据Kubernetes的资源模型,在Pod level的QoS分为3个 等级:Guarantee、Burstable、BestEffort,有之后 人也是依照这兩个 级别对应有之后 人应用的优先级来制定资源超卖的标准。有之后 人对应用设置的QoS标准:

  • Kubernetes自带的组件使用Guarantee
  • 重要的组件和应用,比如ZooKeeper、Redis,用户服务等使用Guarantee
  • 普通的应用(Burstable)按照重要性分级,按重要程度CPU分为2,5,103个 超卖标准,10倍超卖适合boss后台类的应用,大多数适合访问量不高。内存使用固定的1.5倍超卖标准。
有有之后 前要不得劲注意,在生产环境中,无须使用BestEffort的土办法,它会引发不选着的行为。

容器云管理平台

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

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

容器云的目标决定了有之后 人面对的是应用的管理,即应用对应的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的土办法有之后 人删改删改都是尝试,有之后肯能团队精力有限和肯能的风险,总爱 没办法 正式使用。

高可用基础设施

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

实现运维自动化是有之后 人立项之初最主要的目标,而它又是实现后边目标的基础。这种 因素直接决定了有之后 人的技术选型。

技术选型

有之后 人是在2015年6月份开始英语 调研技术,2015年8月份开始英语 容器云立项,首不难 面对的问题,统统 如保进行容器编排引擎的选型,可供选着的有Swarm,Mesos,Kubernetes,甚至自主研发集群编排,有之后 人认真调研了每有一种方案:

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

理论基础和原则

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

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

计算资源QoS与超卖

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

遇到过RBD盘被锁住,新产生的Pod无法挂载的情况汇报,防止土办法是将RBD盘手工解锁,新的Pod会自动挂载。Kubernetes的3个 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默认返回字母序的前400个镜像,客户端前要防止分页的问题。应用向容器云迁移是容器云建设过程中花费最多精力的地方,肯能前要适应容器云转过身的理念转变和对现有应用改造进行改造,迁移过程中受到了统统 挑战,最大的挑战是Dubbo应用的迁移问题,肯能Flannel的Overlay网络使容器化的Dubbo应用还还都可以 了与Overlay网络之外的应用连通,最后有之后 人修改了网络策略,使得Dubbo的应用还还都可以 无缝的迁移到容器云中。下一阶段容器云工作的重点,是推动应用向Cloud Native和微服务化方向改造。容器云面临的最大挑战来自于理念转变,容器技术改变了软件交付的生态,容器时代前要技术人员以新的理念构建应用,如保让技术人员顺利的完成理念的转变是每个容器云的建设者们前要认真考虑的问题。

Q&A

Q:请教一下防止CI时,比如集群自动化部署方面的粒度是如保的?比如修复3个 bug改了3个 class文件,有之后本地测试完之后前要到线上部署进AB测试,没办法 就直接通过CI自动部署到集群服务器吗?

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

CI/CD建设