云时代运维转型必读：容器运维模式的五大场景
|
深度使用过puppet的运维工程师可能会比较清楚两者的区别，puppet也是一套基于声明式机制的配置管理和状态管理的工具。在没有puppet之前，运维工程师喜欢用简单的shell、python脚本对众多服务器进行统一的软件安装、配置管理，但随着服务器数量增多和配置项的递增，命令行式的配置管理往往出现各种缺陷。如状态不一致、历史版本无法回滚、配置没有幂等性、需要很多状态判断才能执行最终的操作等等。 而声明式的配置管理方法，可以规避以上弊端，原因如下： 当我们确认了一个版本yaml配置文件后，表示向k8s的Kube-Controller-Manager提交了我们所期望的对象状态信息，然后k8s使用patch的方式对API对象进行修改。而声明式API是k8s项目编排能力的核心所在，它可以在无需干预的情况下对api对象进行增删改查，完成对“期望状态”和“实际状态”的reconcile过程。 以我们最常用的deployment对象为例。 1)方式一
2)方式二 首次创建使用 create ，修改yaml使用edit，然后用replace使之生效。 k8s对这两种机制的处理方法是完全不同的，前者是声明式，后者是命令式。 两者的结果虽然都是触发滚动更新，但是前者是对原有API对象打patch，后者是对象的销毁和替换。前者能一次处理多个yaml配置变更的写操作并具备相同配置项的merge能力，后者只能逐个处理，否则有冲突的可能。 所以，我们只需要确认yaml文件的版本，一律通过 kubectl apply 命令进行执行，无需再考虑第一步创建、第二步修改、第三步替换之类的命令行。那么我们统一用apply命令，可以通过history命令进行回溯版本，也可以保证apply的结果的幂等性等等。 使用声明式只需要描述最终所需的状态，无需用户关心过多的实现流程和细节，没有像命令行式的那么多上下文关系或者运行环境依赖，甚至可以由开发人员直接编写，运维进行code review即可。特别在使用Kubernetes这样的容器编排工具，更加要深刻理解和灵活运用声明式的运维模式。 2、API对象 Kubernetes大量的API对象的存在是导致其运维方法和传统系统层运维有区别较大的重要原因之一。 如果我们要深入了解k8s，则需要理解一些它核心的API对象，才能更好地理解这个容器的运行系统。如果把容器理解成一种特殊带有资源隔离、资源限制的进程，那么Pod对象是一组进程组，最后，k8s是运行众多有关联的进程组(Pod)的操作系统。 这一层操作系统运行在PaaS层，比我们传统运维的Linux系统所在的IaaS层要高一层。 而我们在理解这个在PaaS层的k8s对象的概念时，需要一些面向对象的编程思想，会让整个思路梳理地更加清晰。 所谓的面向对象，即在编码过程中设定一切事物皆对象，通过面向对象的方式，将现实世界的事物抽象成对象，现实世界中的关系抽象成类、继承，帮助人们实现对现实世界的抽象与数字建模。 通过面向对象的方法，更利于用人理解的方式对复杂系统进行分析、设计与编程。同时，面向对象能有效提高编程的效率，通过封装技术，消息机制可以像搭积木的一样快速开发出一个全新的系统。 面向对象是指一种程序设计范型，同时也是一种程序开发的方法。对象指的是类的集合。它将对象作为程序的基本单元，将程序和数据封装其中，以提高软件的重用性、灵活性和扩展性。 在系统层运维时候，我们关注的有CPU、内存、IO等硬件对象，以及软件安装卸载、系统服务启停、环境变量、内核版本等软件对象等等，就足以理解和把控整个操作系统运行环境。 理解这些对象可以当成是一种面向过程的思维，因为最初操作系统的设计就是当时的计算机大牛们通过面向过程的思维所写出来的，所以系统很多组成概念无需要面向对象思维就可以理解。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
