uu快3神彩_uu快3app开户_彩神争8

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

时间:2020-01-07 10:23:47 出处:uu快3神彩_uu快3app开户_彩神争8

  • 不可变基础设施,是利用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为中心构建容器云

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

可能资源限制,技术人员往往过于关注单机的资源利用率。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的组合最好的最好的办法。容器云管理系统的基本功能如下图所示:

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

按照大伙儿预先的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平台的工作流示意图:

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

实现运维自动化是大伙儿立项之初最主要的目标,而它又是实现中间目标的基础。这俩因素直接决定了大伙儿的技术选型。

技术选型

大伙儿是在2015年6月份结束了了了了调研技术,2015年8月份结束了了了了容器云立项,首先要面对的疑问报告 ,却说如何进行容器编排引擎的选型,可供取舍的有Swarm,Mesos,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建设

遇到过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默认返回字母序的前30个镜像,客户端并能 处里分页的疑问报告 。应用向容器云迁移是容器云建设过程中花费最多精力的地方,可能并能 适应容器云转过身的理念转变和对现有应用改造进行改造,迁移过程中受到了许多许多挑战,最大的挑战是Dubbo应用的迁移疑问报告 ,可能Flannel的Overlay网络使容器化的Dubbo应用没有 与Overlay网络之外的应用连通,最后大伙儿修改了网络策略,使得Dubbo的应用都并能 无缝的迁移到容器云中。下一阶段容器云工作的重点,是推动应用向Cloud Native和微服务化方向改造。容器云面临的最大挑战来自于理念转变,容器技术改变了软件交付的生态,容器时代并能 技术人员以新的理念构建应用,如何让技术人员顺利的完成理念的转变是每个容器云的建设者们并能 认真考虑的疑问报告 。

Q&A

Q:请教一下处里CI时,比如集群自动化部署方面的粒度是如何的?比如修复另一个多 bug改了另一个多 class文件,后来本地测试完日后并能 到线上部署进AB测试,没有 就直接通过CI自动部署到集群服务器吗?

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

本文来自云栖社区公司战略合作 伙伴Dockerone.io,了解相关信息都并能 关注Dockerone.io。

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

计算资源QoS与超卖

原文标题: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的最好的最好的办法大伙儿详细后该尝试,后来可能团队精力有限和可能的风险,总是没有 正式使用。

高可用基础设施

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

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相关的容器技术,确保大伙儿的决策是正确的,这对大伙儿构建容器云至关重要。经过许多许多的调研和讨论,大伙儿发现容器云的是有一套完成的理论基础支撑的,有有哪些理论又引申出大伙儿构建容器云的原则:

热门

热门标签