设为首页 - 加入收藏 平凉站长网 (http://www.0933zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 2018 input
当前位置: 首页 > 新潮汕台湾神算 > 外闻 > 正文

云时代运维转型必读:容器运维模式的五大场景

发布时间:2019-08-16 17:19 所属栏目:[外闻] 来源:DBAplus社群
导读:其实我挺早就接触Docker和Kubernetes,时间大概在3、4年前吧,但是由于当时所在技术团队的业务模式所限制,还没有真正对容器云有技术需求,所以我更多还是以一种技术玩具的心态接触容器技术。 直到去年开始才正式接触基于容器云平台的技术架构,我从业务运

其实我挺早就接触Docker和Kubernetes,时间大概在3、4年前吧,但是由于当时所在技术团队的业务模式所限制,还没有真正对容器云有技术需求,所以我更多还是以一种技术玩具的心态接触容器技术。

直到去年开始才正式接触基于容器云平台的技术架构,我从业务运维和DevOps的角度来看,容器云平台与之前的物理机和虚拟机等IaaS层基础上的运维模式有着非常大的差异。

云时代运维转型必读:容器运维模式的五大场景

根据这段时间的运维经验,我尝试总结一下某些容器云的运维方法的共同特性,并将其称为“容器运维模式”,简单百度谷歌了一下,没有这个名词,希望是我的首创:)

这个名词灵感来自软件工程的“设计模式”,设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式的目的:为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编写真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。

而“容器运维模式”,指的是由DevOps(题外话:DevOps、SRE、SA、运维等等,其实都差不多是同一个意思,业界喜欢创一个新的名词来代替运维,主要是为了区分自己和一些低端系统维护人员)在日常运维容器化项目的一些经验总结,为了区别于传统的物理机、虚拟机的运维套路,而归纳出来的容器运维方法。

回顾过去

从大概10年前,大家都是以【自建IDC】+【物理服务器】的形式进行生产环境基础架构的建设。

然后持续到大概5年前,私有云技术和公有云的兴起,让大批中小型企业减少对物理设备资源建设的人力和资金投入,可以专注于业务研发和运营。

最后到大概3、4年前,容器技术Docker和以Kubernetes为代表的容器编排技术的崛起,以及微服务技术的同步普及,宣告了容器云平台的来临。

而事实上,以Kubernetes为首的相关周边项目,已经成为了容器云领域的首选标准,所以绝大部分技术团队如果现在需要选型容器编排体系,可以无脑选k8s了。

需求的根本——应用交付

在传统裸机(bare metal)或虚拟化的时代,当开发团队将代码交付给运维进行生产环境中部署,但是它却未能正常工作时,挑战就出现了。

“运行环境不一致”、“没有安装相关依赖软件”、“配置文件不一样”等等已经成了开发和运维沟通的惯用语。

在传统的开发场景中,开发和测试团队使用的是与生产环境不同的基础设施,尽管做到了代码和配置解耦,但是在运行环境的转换中,依然会得到像前面所述的团队协作和环境依赖问题。

而贯穿软件生命周期共享相同的容器镜像是容器化带来的最大好处,它简化了开发与运维团队之间的协作关系。

由于本地开发/测试服务器和生产环境的不一致以及应用程序打包部署的过程,一直是让研发和运维纠结的难题,但有了容器之后,由于容器镜像里打包的不仅是应用,而是整个操作系统的文件和目录,即其运行所需的所有依赖,都能被封装一起。

有了容器镜像的打包能力之后,这些应用程序所需的基础依赖环境,也成为了这个应用沙盒的一部分,这可以给这个应用包赋予这样的能力:无论在开发、测试还是生产环境运行,我们只需要解压这个容器镜像,那么这个应用所需的所有运行依赖都是存在的、一致的。

如果熟悉Docker容器技术原理的话,我们知道它主要由Linux内核的Namespace和CGroups以及rootfs技术隔离出来一种特殊进程。

把Docker形容为一个房子的话,Namespace构成了四面墙,为PID\NET\MNT\UTS\IPC等资源进行隔离;CGroups形成了它的天花板,限制了对系统资源的占用;而rootfs是其地基,是通过copy-on-write机制构成的分层镜像,也是开发者最为关心的应用信息的传递载体。

作为开发者,他们可能不关心由前两者构成的容器运行时的环境差异,因为真正承载容器化应用的传递载体,是这个不变的容器镜像。

在Docker技术的普及后不久,为了整个完整的DevOps链条的打通,包括CI/CD、监控、网络、存储、日志收集等生产环境的刚需,以及整个容器生命周期的管理和调度,以Kubernetes为首的容器编排体系也作为上层建筑也迎来了一波快速的增长。从容器到容器云的蜕变,标志着容器运维时代的来临。

容器运维模式的主要场景分析

1、声明式 vs 命令行

  1. apiVersion:?apps/v1?
  2. kind:?Deployment?
  3. metadata:?
  4. ??name:?nginx-deployment?
  5. ??labels:?
  6. ????app:?nginx?
  7. spec:?
  8. ??replicas:?3?
  9. ??selector:?
  10. ????matchLabels:?
  11. ??????app:?nginx?
  12. ??template:?
  13. ????metadata:?
  14. ??????labels:?
  15. ????????app:?nginx?
  16. ????spec:?
  17. ??????containers:?
  18. ??????-?name:?nginx?
  19. ????????image:?nginx:1.12.2?
  20. ????????ports:?
  21. ????????-?containerPort:?80?

我们知道Kubernetes是通过yaml文件(样例如上所示)来对其API对象,如Deployment、Pod、Service、DaemonSet等进行期望状态的描述,然后k8s的控制器有一套状态调谐的机制让各种API对象按要求所述的状态运行。由于这样一套运行机制的存在,所以使得k8s和过往运维常见的命令行,也包括脚本式的运行方式有着很大的差异。

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章