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

Kubernetes（以下简称K8s）对象模型是K8s的又一精妙设计。我们知道，K8s建立的容器化生态是复杂多变的，对象模型就是将一系列的资源实体抽象成K8s中可以识别的对象。为了方便大家更全面的了解K8s的设计思路，本文对K8s的对象模型进行了梳理，并在文末添加了面试常见问题总结。K8s常用对象模型介绍——哪些对象模型可以作为我们使用的K8s对象模型的组织形式以及如何创建yaml——我们如何使用对象K8s对象模型概述总结——为什么我们需要了解对象模型？还需要考虑吗？存在就是合理呗。那我们就来看看他为什么存在。在官方文档中，K8s对象模型是这样定义的：“在Kubernetes系统中，Kubernetes对象是持久化的实体。Kubernetes使用这些实体来表示整个集群的状态。具体来说，它们描述了以下信息：容器化应用程序正在运行（以及在哪个节点上），应用程序可以使用的资源与应用程序的运行时性能策略有关，例如重启策略、升级策略和容错策略。”简单来说，对象模型有两个主要目标：1.服务于K8s集群对象模型的一个功能是抽象描述K8s集群的状态、实体以及实体之间的关联。该类的代表是Label，它在簇对象之间建立灵活的、松耦合的多维关系。我们可以使用标签选择器进行查询和过滤，建立对象之间的关系。2.为用户服务。K8s提供了多种抽象对象，方便用户将自己的应用部署到集群中。这些抽象对象为用户屏蔽了复杂的底层逻辑，让用户更专注于如何使用它们。这种类型的例子有很多，比如Pod、Node、Deployment等，比如我们要在8s集群中部署一个应用，首先需要将我们的应用转化为K8s可以实现的Pod这样的实体对象管理;对于多副本应用，我们需要考虑统一管理，比如Deployment；进一步考虑副本之间的负载均衡和服务发现，我们也可以考虑使用Service来实现。用户无需关注其内部实现，可以更专注于自己的应用。K8s常用对象模型——我们可以使用哪些对象模型既然K8s对象模型这么神奇，那我们就得看看他是不是真的这么神奇。我们先看一下K8s的常用对象。这里再放一张图更形象地介绍一下K8s中各个对象的位置。工作负载类对象Pod位置：位于图中标示Pod的位置说明：Pod是集群中可以创建和部署的最小最简单的Kubernetes对象单元，代表一个容器或者容器的一个小集合，它们紧密相连耦合和共享资源。抽象封装：Pod封装了应用容器、存储资源、独立网络IP、容器运行的策略选项。Docker是目前KubernetesPod中最常用的容器运行时，所以本文所说的容器都是指docker容器。目前Docker是KubernetesPod中最常用的容器运行时，所以本文提到的容器都是指docker容器。在K8s中，每个pod中都预置了一个Pause容器，它的命名空间、IPC资源、网络和存储资源都被该pod中的其他容器共享。Pod中的所有容器紧密协作，作为一个整体进行管理、调度和运行。Controllers位置：位于图中Master中的Controller-Manager位置。说明：ControllerManager作为集群内的管理控制中心，负责管理集群内的Node、Pod、服务端点（Endpoint）、命名空间（Namespace）、服务账户（ServiceAccount）、资源配额（ResourceQuota）.他们的职责是保证集群中各种资源的状态与用户定义的状态（yaml）一致。每个controller通过APIServer提供的接口实时监控整个集群中各个资源对象的当前状态。当各种故障导致系统状态改变时，试图将系统状态恢复到“期望的状态”。例如，当一个Node意外宕机时，NodeController会及时发现并执行自动修复流程，确保Node始终处于预期的工作状态。下图列出了一些controller的图例：抽象与封装：从逻辑上讲，每个controller都是一个独立的进程，它们为用户封装了对资源对象的管理逻辑。用户创建资源对象后，控制器会帮助用户实时监控整个集群中每个资源对象的当前状态，自动保证资源对象始终处于预期的工作状态。还。K8s支持用户自定义扩展控制器。Deployment/Statefulset/Daemonset/Job位置：Deployment位于图中④位置，Statefulset位于图中位置5，Daemonset/Job位于图中绿色Pod位置。说明：这类资源对象为Pod提供了声明式的方法，但同时它们又分别负责处理不同的使用场景。Deployment为Pod和ReplicaSet提供了一种声明式的方式，用于替代之前的ReplicationController方便的管理应用，主要是针对Kubernetes中用于处理无状态服务的资源。典型的应用场景包括：定义一个Deployment来创建Pod和ReplicaSets滚动升级和回滚应用程序扩容和缩容暂停和继续DeploymentStatefulSets是用来支持有状态服务的资源。典型的应用场景是Zookeeper和Kafka。它可以保证部署的顺序和规模。其应用场景包括：稳定的持久化存储。稳定的网络标志。有序布局扩容。有序缩减。DaemonSet不同于上述两种方法。解决了在集群所有节点上同时提供基础服务和守护进程的场景。DaemonSet可以保证集群中全部或部分节点可以运行同一个Pod副本，比如kube-router、flannel等都是用DaemonSet部署的。Job负责批处理任务，即只执行一次的任务。它确保批处理任务的一个或多个Pod成功完成。适用场景如收集数据等。雇主可能希望将定时任务自动化，就像crontab一样。不用担心，K8s还提供了定时任务的cronjob资源对象，可以支持类似于crontab的定时功能。Discovery&Loadbalance类对象Service/Endpoints/Ingress位置：Service在图中①和②位置。入口在图中③处。描述：KubernetesService是对Pod的逻辑分组的抽象，它提供了访问它们的策略，通常称为微服务。K8s通过抽象Service的概念，为后端绑定的pod服务提供服务发现和负载均衡功能，为一组具有相同功能的容器应用提供统一的入口地址，将请求的负载分发给后端endcontainers应用程序上的控制器。Service可以访问这组Pod，通常是通过LabelSelector。Endpoint是K8s集群中的资源对象，存储在etcd中，用于记录一个Service对应的所有pod的访问地址。服务配置选择器，端点控制器会自动创建对应的端点对象；否则，不会生成Endpoint对象。Ingress也是Service相关的资源对象，授权入站连接到达集群服务的规则集。我们可以为Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过将Ingress资源发布到API服务器来请求Ingress。偷懒，借用网上一张图来说明三者的关系（图中的Pod可以理解为EndPoints）：Config&Storage类对象Configmap/Secret/Volume/PersistentVolume位置：Configmap、Secret都位于图中标有Configmap，秘密的位置。PersistentVolume位于图中的PV1、PV2、PV3。说明：在K8s中，为了解决容器的存储问题，定义了volume，称为Volume。它不仅可以解决Container中文件的临时问题，还可以让同一个Pod中的多个Container共享文件。这里所说的体积（Volume）其实是一个比较具体的概念。它不是持久存储，可能会随着Pod的删除而被删除。常见卷包括EmptyDir、HostPath、ConfigMap和Secret。这些卷与它们所属的ThePod相关，具有相同的生命周期。与Volume对应的是持久化卷的概念，即PersistentVolume，它提供持久化存储方案，将Pod与卷的生命周期分离。抽象和封装：Volume和PersistentVolume为用户屏蔽了集群中容器存储的底层逻辑。集群中的每个卷在被Pod使用时都会经历两个操作，即Mount和Unmount。比如Configmap和Secret也会进行Attach和Detach操作，但是用户不需要关心这些操作，只需要在yaml中设置数据源和挂载路径即可。同时，存储对象的管理也是由对象自动进行的。存储资源的创建和删除，用户只需要简单的创建和删除，但实际上，存储资源的分配和回收也是由K8s自动完成的。Cluster类对象Node/Namespace/Role/ClusterRole位置：Node位于图中黄色方块内，用Node标注。命名空间是图中标有命名空间的框。Role是图中盾牌的位置，ClusterRole是图中盾牌的完整集合。说明：Cluster对象代表了K8s中的一些全局资源对象。不用说，Node是K8s存在的物理基础。命名空间类似于编程语言中的作用域。K8s支持通过Namespace在一个物理集群中划分多个虚拟集群，这些虚拟集群使用独立的命名空间。各个Namespace之间的容器是不透明的，这也便于对用户进行更细粒度的权限控制。Role和ClusterRole负责为用户提供集群内的权限管理。Role对象用于授予对单个命名空间中资源的访问权限，而整个Kubernetes集群中的有效角色是通过ClusterRole对象实现的。在使用中，我们可以对以下类型的资源授予权限：集群范围的资源（如节点）非资源类型的端点跨命名空间的资源（如跨命名空间的pod）抽象和封装：集群类型的对象屏蔽用户来自集群管理逻辑。整个簇被抽象成一个扁平的结构。我们可以将集群比作棋盘。Pod（棋子）首先部署在各自的命名空间中。有些Pod（棋子）只能在各自的区域运行，而有些Pod（棋子）可以跨区域运行。用户只需要学会使用这些Pod（棋子），具体规则和执行逻辑由K8s制定。K8s对象模型的组织形式和yaml创建方式——我们如何使用对象在K8s中，为用户组织和创建对象的方式是通过yaml文件。对于编写良好的yaml文件，您可以使用以下说明创建对象资源kubectlcreate/apply-f***.yaml您可以通过以下说明查看Pod对象的组织方式。kubectldescribepod***-n下面，本节详细分析对象yaml的字段以及各个资源的创建方法。首先，我们要树立一个观念。yaml文件是对象描述的可视化，即将描述一个对象的概念映射到yaml上的各个kv字段。在描述一个K8s对象时，需要嵌套两个字段，负责管理对象的配置：spec和status。spec必须提供，它描述了对象的期望状态——对象期望具有的特征。status描述了对象的实际状态，由K8s系统提供和更新。在任何时候，K8s管理模块始终处于活动状态，管理对象的实际状态以匹配我们想要的状态。例如：可以看到Deployment对象的Spec和Status描述结构。除了yaml之外，对于不同的对象，yaml配置的内容是不同的，但是以下几项是必须的：apiVersion#创建对象所使用的KubernetesAPI的版本kind#要创建的对象的类型metadata#标识对象唯一数据，包括名称字符串、UID和可选的namespacespec字段。spec不是强制性的，但用户在使用时需要提供该字段的内容。同样由于个体对象的差异，每个Kubernetes对象的规范的确切格式都不同，包括特定于该对象的嵌套字段。详细字段内容请参考K8sAPI（https://kubernetes.io/docs/api/）。下面我们举例说明如何创建各个资源：Workload类对象Pod类资源我们用经典案例——busybox创建模板来简单说明一下：这个模板首先指定了yaml、apiVersion、kind、metadata这三个元素。Pod-specificspec中指定了所需的镜像busybox，并简单设置了镜像拉取和容器重启的策略。在使用过程中，我们会发现，经过简单的配置，K8s会自动帮您完成镜像拉取或容器重启导致的异常管理问题，也就是上面提到的对象的实际状态与我们的预期是一致的。状态匹配。再举个例子，经典的nginx模板用例：Deployment用来描述一组Pod，所以这里指定了副本数，设置了一个selector来描述Pod和Deployments的关系。Discovery&Loadbalanceclassobjects这类资源代表了一个具有网络特征的对象，代表对象是Service。这里我们也列举一个Service的经典用例来说明。在Service对象的yaml模板中，我们可以指定一个或一组Pod的通信端口和通信协议，指定服务的暴露方式。Config&Storage类对象Configmap是非持久化存储的代表。举个例子来说明一下：Configmap的部署用例没有spec字段，直接指定数据的内容。除了上面使用yaml创建之外，当我们将ConfigMap或Secret包装成一个volume并挂载到某个目录时，实际上是在创建一个Volume。这些Volumes不是Kubernetes中的对象，它们只存在于当前的Pod中。它会随着Pod的删除一起被删除，但是需要注意的是，删除这些临时Volume并不会导致相关的ConfigMap或者Secret对象的删除。让我们再举一个持久化存储的例子。持久存储的创建用例有点类似于Pod对象。有必要指定预期的存储状态。这里设置1G的容量，以可读写的方式挂载到多个节点，使用nfs挂载PV存储。这样创建完成后，就可以在Pod中使用PVC进行存储绑定了。集群对象大多数集群对象都是集群资源对象。默认情况下，用户不需要使用yaml来创建它们。例如，命名空间可以直接使用命令kubectlcreatens****创建。这里我们举一个ClusterRole的yaml例子。在这个例子中，我们定义了一个ClusterRole对象，它可以授予对secrets资源对象的get、watch和list权限。接下来我们使用ClusterRoleBinding来使用它。ClusterRoleBinding可以将角色中定义的权限授予用户或用户组。ClusterRoleBinding包含一组权限列表（主题）。权限列表包含不同类型的资源类型被授予权限（如USER、GROUP、SERVICEACCOUNT）。ClusterRoleBinding适用于集群范围内的授权，对应的RoleBinding适用于一定命名空间内的授权。示例：在这个用例中，我们将ClusterRolesecret绑定到用户dazhuang，授权用户dazhuang只能访问myspace中的secret。总结K8s的对象模型是K8s非常重要的一部分，是K8s构建的基础。K8s中的每个对象都为用户屏蔽了复杂的底层细节，通过不断获取集群的运行状态并与预期状态进行对比，帮助用户确保对象能够以预期的状态运行。希望本文能帮助读者更全面的了解K8s的对象模型。