容器运维模式（二）-- API对象

继续上文未完的内容

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，以及它们之间的关系，这里就不详述了，请参考相关文档。