云时代运维转型必读：容器运维模式的五大场景
|
深度使用过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等硬件对象，以及软件安装卸载、系统服务启停、环境变量、内核版本等软件对象等等，就足以理解和把控整个操作系统运行环境。 理解这些对象可以当成是一种面向过程的思维，因为最初操作系统的设计就是当时的计算机大牛们通过面向过程的思维所写出来的，所以系统很多组成概念无需要面向对象思维就可以理解。 众所周知，Kubernetes是根据谷歌内部运行多年的Borg项目的架构体系所创造出来，所以它具备天生的项目架构前瞻性。一般的开源项目是理论基础走在工程应用的后面，比如docker + swarm为代表，都是现实应用中遇到什么需求，就新增一个功能，慢慢从一个单独容器docker再到了具备基本编排能力的swarm。反观Kubernetes，是一套自顶向下的架构设计，几乎能适配当前所有的应用架构模式，应对什么web-db、lb-web-redis-db、db-master-slave之类的常见架构根本不在话下。 再回到Kubernetes的API对象，k8s使用这些API对象来描述一个集群所期望的运行状态。 通常一个Kubernetes对象包含以下信息：需要运行的应用以及运行在哪些Node上、应用可以使用哪些资源、应用运行时的一些配置，例如副本数、重启策略、升级以及容错性等等。
通过上图可见API对象种类非常多，其实我们应该先重点掌握最核心的Node、Pod、Deployment、RS、Service、Namespace，以及它们之间的关系，这里就不详述了，请参考相关文档。 3、控制器模式 在说Kubernetes的控制器模式之前，我们先看看软件架构中十分常见的MVC模式，即Model(模型)、View(视图)、Controller(控制器)。 1)模型(Model) 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“ Model ”有对数据直接访问的权力，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。比如：观察者模式(软件设计模式)。 2)视图(View) 能够实现数据有目的的显示(理论上，这不是必需的)。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型(Model)，因此应该事先在被它监视的数据那里注册。 3)控制器(Controller) 起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。 MVC 模式强调职责分离，即视图和数据模型的分离，并利用控制器来作为这两者的逻辑控制的中介，使之具有逻辑复用、松散耦合等优点。 数据模型(Model)，它描述了“应用程序是什么”，用于封装和保存应用程序的数据，同时定义操控和处理该数据的逻辑和运算。而且，Model通常是可以复用的。 一个良好的MVC应用程序应该将所有重要的数据都封装到Model中，而应用程序在将持久化的数据(文件、数据库)加载到内存中时，也应该保存在Model中。 因为Model本身就代表着业务的特定数据对象，而在k8s里面，最典型的Model就是Pod。 视图(View)，它是展现给用户的界面，这个不用多说。这个在k8s的应用不多，例如kubectl的信息输出或者Dashbord等，都可以算是一种View的应用。 （编辑：鞍山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
