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

众所周知，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的应用。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!