一篇文章为你说明Kubernetes对象模型

Kubernetes(以下简写为K8s)的对象模型是K8s又一精巧的设计。我们知道，K8s所建立的容器化生态是复杂且多变的，而对象模型就是将一系列的资源实体抽象成K8s中所能识别的对象。为了方便大家更全面的了解K8s的设计思想，本文对K8s的对象模型进行了梳理，同时在文章末尾增加了常见面试题问题汇总，章节内容分配如下：

K8s对象模型概述-我们为什么要了解对象模型

K8s常见对象模型介绍-哪些对象模型可以为我们所用

K8s对象模型的组织形式及yaml创建方法-我们该如何使用对象

总结

K8s对象模型概述-我们为什么要了解对象模型

这问题还用想?存在即合理呗。那咱们就先来看看他为什么存在。

在官方文档中，对K8s的对象模型有这样的定义：

“在 Kubernetes 系统中，Kubernetes 对象是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：

哪些容器化应用在运行(以及在哪个 Node 上)

可以被应用使用的资源

关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略”

简单说来，对象模型主要有两点目标：

1.服务于K8s集群

对象模型一个功能是用以抽象化描述K8s集群状态，实体及实体间关联。此类的代表就是Label，它建立集群对象之间的灵活、松耦合的多维关联关系，我们可以用通过lable selector 查询和筛选建立对象间的关系的。

2.服务于用户。

K8s提供多种抽象对象便于用户部署自己的应用到集群中，这些抽象对象为用户屏蔽了复杂的底层逻辑，让用户更专注于如何去使用。此类的例子就比较多，比如Pod，Node，Deployment等。举个例子来说，比如我们要部署应用在8s集群内，首先要我们的应用需要转换为K8s所能管理的实体对象如Pod;对于多副本应用，我们需要考虑进行统一的管理，可以考虑如Deployment;进一步考虑副本间的负载均衡和服务发现，我们又可以考虑采用Service来实现，用户无需关注其内部实现，从而更专注于自身的应用。

K8s常见对象模型-哪些对象模型可以为我们所用

既然把K8s对象模型吹得这么神，那得看看他是不是真有这么神。下面来一起看看K8s常见的对象。

这里再用一幅图来更形象地介绍各个对象在K8s中的所处位置。

一篇文章为你图解Kubernetes对象模型

Workload类对象

Pod

位置：位于图中标有Pod标记的位置

说明：Pod是集群中可以创建和部署的最小且最简单的Kubernetes对象的单元，其表示单个 容器 或少量紧密耦合并共享资源的容器集合。

抽象与封装：Pod封装了应用容器，存储资源、独立的网络IP以及容器运行的策略选项。目前Docker 是 Kubernetes Pod 中最常用的容器运行时，因此在本文中所提到的容器均值docker容器。目前Docker 是 Kubernetes Pod 中最常用的容器运行时，因此在本文中所提到的容器均指docker容器。

在K8s中，每个pod中预置了一个Pause容器，其namespace、IPC资源、网络和存储资源被pod内其它容器共享。Pod中的所有容器紧密协作，并且作为一个整体被管理、调度和运行。

Controllers

位置：位于图中Master中的Controller-Manager位置。

说明：Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理。他们的职责是保证集群中各种资源的状态和用户定义(yaml)的状态一致, 每个controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。例如，当某个Node意外宕机时，Node Controller会及时发现并执行自动化修复流程，确保Node始终处于预期的工作状态