点击这里查看第一章：Kubernetes快速入门
点击这里查看第二章：资源管理基础

第3章：资源管理基础

Kubernetes系统的API Server基于HTTP/HTTPS接收并响应客户端的操作请求，它提供了一种“基于资源”（resource-based）的RESTful风格的编程接口，将集群的各种组件都抽象成为标准的REST资源，如Node、Namespace和Pod等，并支持通过标准的HTTP方法以JSON为数据序列化方案进行资源管理操作。本章将着重描述Kubernetes的资源管理方式。

3.1　资源对象及API群组

REST是Representational State Transfer的缩写，意为“表征状态转移”，它是一种程序架构风格，基本元素为资源（resource）、表征（representation）和行为（action）。资源即对象，一个资源通常意味着一个附带类型和关联数据、支持的操作方法以及与其他对象的关系的对象，它们是持有状态的事物，即REST中的S（State）。REST组件通过使用“表征”来捕获资源的当前或预期状态并在组件之间传输该表征从而对资源执行操作。表征是一个字节序列，由数据、描述数据的元数据以及偶尔描述元数据的元数据组成（通常用于验证消息的完整性），表征还有一些其他常用但不太精确的名称，如文档、文件和HTTP消息实体等。表征的数据格式称为媒体类型（media type），常用的有JSON或XML。API客户端不能直接访问资源，它们需要执行“动作”（action）来改变资源的状态，于是资源的状态从一种形式“转移”（Transfer）为另一种形式。
资源可以分组为集合（collection），每个集合只包含单一类型的资源，并且各资源间是无序的。当然，资源也可以不属于任何集合，它们称为单体资源。事实上，集合本身也是资源，它可以部署于全局级别，位于API的顶层，也可以包含于某个资源中，表现为“子集合”。集合、资源、子集合及子资源间的关系如图3-1所示。

图3-1　集合、资源和子资源

Kubernetes系统将一切事物都抽象为API资源，其遵循REST架构风格组织并管理这些资源及其对象，同时还支持通过标准的HTTP方法（POST、PUT、PATCH、DELETE和GET）对资源进行增、删、改、查等管理操作。不过，在Kubernetes系统的语境中，“资源”用于表示“对象”的集合，例如，Pod资源可用于描述所有Pod类型的对象，但本书将不加区别地使用资源、对象和资源对象，并将它们统统理解为资源类型生成的实例—对象。

3.1.1　Kubernetes的资源对象

依据资源的主要功能作为分类标准，Kubernetes的API对象大体可分为工作负载（Workload）、发现和负载均衡（Discovery & LB）、配置和存储（Conf?ig & Storage）、集群（Cluster）以及元数据（Metadata）五个类别。它们基本上都是围绕一个核心目的而设计：如何更好地运行和丰富Pod资源，从而为容器化应用提供更灵活、更完善的操作与管理组件，如图3-2所示。

图3-2　Kubernetes常用资源对象

工作负载型资源用于确保Pod资源对象能够更好地运行容器化应用，具有同一种负载的各Pod对象需要以负载均衡的方式服务于各请求，而各种容器化应用彼此之间需要彼此“发现”以完成工作协同。Pod资源具有生命周期，存储型资源能够为重构的Pod对象提供持久化的数据存储机制，共享同一配置的Pod资源可从配置型资源中统一获取配置改动信息，这些资源作为配置中心为管理容器化应用的配置文件提供了极为便捷的管理机制。集群型资源为管理集群本身的工作特性提供了配置接口，而元数据型资源则用于配置集群内部的其他资源的行为。
（1）工作负载型资源
Pod是工作负载型资源中的基础资源，它负责运行容器，并为其解决环境性的依赖，例如，向容器注入共享的或持久化的存储卷、配置信息或密钥数据等。但Pod可能会因为资源超限或节点故障等原因而终止，这些非正常终止的Pod资源需要被重建，不过，这类工作将由工作负载型的控制器来完成，它们通常也称为pod控制器。
应用程序分为无状态和有状态两种类型，它们对环境的依赖及工作特性有很大的不同，因此分属两种不同类型的Pod控制器来管理，ReplicationController、ReplicaSet和Deployment负责管理无状态应用，StatefulSet用于管控有状态类应用。ReplicationController是上一代的控制器，其功能由ReplicaSet和Deployment负责实现，因此几近于废弃。还有些应用较为独特，它们需要在集群中的每个节点上运行单个Pod资源，负责收集日志或运行系统服务等任务，这些Pod资源的管理则属于DaemonSet控制器的分内之事。另外，有些容器化应用需要继续运行以为守护进程不间断地提供服务，而有些则应该在正常完成后退出，这些在正常完成后就应该退出的容器化应用则由Job控制器负责管控。下面是各Pod控制器更为详细的说明。
ReplicationController：用于确保每个Pod副本在任一时刻均能满足目标数量，换言之，它用于保证每个容器或容器组总是运行并且可访问；它是上一代的无状态Pod应用控制器，建议读者使用新型控制器Deployment和ReplicaSet来取代它。
ReplicaSet：新一代ReplicationController，它与ReplicationController的唯一不同之处仅在于支持的标签选择器不同，ReplicationController只支持等值选择器，而ReplicaSet还额外支持基于集合的选择器。
Deployment：用于管理无状态的持久化应用，例如HTTP服务器；它用于为Pod和ReplicaSet提供声明式更新，是建构在ReplicaSet之上的更为高级的控制器。
StatefulSet：用于管理有状态的持久化应用，如database服务程序；其与Deployment的不同之处在于StatefulSet会为每个Pod创建一个独有的持久性标识符，并会确保各Pod之间的顺序性。
DaemonSet：用于确保每个节点都运行了某Pod的一个副本，新增的节点一样会被添加此类Pod；在节点移除时，此类Pod会被回收；DaemonSet常用于运行集群存储守护进程—如glusterd和ceph，还有日志收集进程—如f?luentd和logstash，以及监控进程—如Prometheus的Node Exporter、collectd、Datadog agent和Ganglia的gmond等。
Job：用于管理运行完成后即可终止的应用，例如批处理作业任务；换句话讲，Job创建一个或多个Pod，并确保其符合目标数量，直到Pod正常结束而终止。
（2）发现和负载均衡
Pod资源可能会因为任何意外故障而被重建，于是它需要固定的可被“发现”的方式。另外，Pod资源仅在集群内可见，它的客户端也可能是集群内的其他Pod资源，若要开放给外部网络中的用户访问，则需要事先将其暴露到集群外部，并且要为同一种工作负载的访问流量进行负载均衡。Kubernetes使用标准的资源对象来解决此类问题，它们是用于为工作负载添加发现机制及负载均衡功能的Service资源和Endpoint资源，以及通过七层代理实现请求流量负载均衡的Ingress资源。
（3）配置与存储
Docker容器分层联合挂载的方式决定了不宜在容器内部存储需要持久化的数据，于是它通过引入挂载外部存储卷的方式来解决此类问题，而Kubernetes则为此设计了Volume资源，它支持众多类型的存储设备或存储系统，如GlusterFS、CEPH RBD和Flocker等。另外，新版本的Kubernetes还支持通过标准的CSI（Container Storage Interface）统一存储接口以及扩展支持更多类型的存储系统。
另外，基于镜像构建容器应用时，其配置信息于镜像制作时焙入，从而为不同的环境定制配置就变得较为困难。Docker使用环境变量等作为解决方案，但这么一来就得于容器启动时将值传入，且无法在运行时修改。ConfigMap资源能够以环境变量或存储卷的方式接入到Pod资源的容器中，并且可被多个同类的Pod共享引用，从而实现“一次修改，多处生效”。不过，这种方式不适于存储敏感数据，如私钥、密码等，那是另一个资源类型Secret的功能。
（4）集群级资源
Pod、Deployment、Service和Conf?igMap等资源属于名称空间级别，可由相应的项目管理员所管理。然而，Kubernetes还存在一些集群级别的资源，用于定义集群自身配置信息的对象，它们仅应该由集群管理员进行操作。集群级资源主要包含以下几种类型。
Namespace：资源对象名称的作用范围，绝大多数对象都隶属于某个名称空间，默认时隶属于“default”。
Node：Kubernetes集群的工作节点，其标识符在当前集群中必须是唯一的。
Role：名称空间级别的由规则组成的权限集合，可被RoleBinding引用。
ClusterRole：Cluster级别的由规则组成的权限集合，可被RoleBinding和ClusterRole
Binding引用。
RoleBinding：将Role中的许可权限绑定在一个或一组用户之上，它隶属于且仅能作用于一个名称空间；绑定时，可以引用同一名称空间中的Role，也可以引用全局名称空间中的ClusterRole。
ClusterRoleBinding：将ClusterRole中定义的许可权限绑定在一个或一组用户之上；它能够引用全局名称空间中的ClusterRole，并能通过Subject添加相关信息。
（5）元数据型资源
此类资源对象用于为集群内部的其他资源配置其行为或特性，如HorizontalPodAutoscaler资源可用于自动伸缩工作负载类型的资源对象的规模，Pod模板资源可用于为pod资源的创建预制模板，而LimitRange则可为名称空间的资源设置其CPU和内存等系统级资源的数量限制等。
一个应用通常需要多个资源的支撑，例如，使用Deployment资源管理应用实例（Pod）、使用Conf?igMap资源保存应用配置、使用Service或Ingress资源暴露服务、使用Volume资源提供外部存储等。
本书后面篇幅的主体部分就展开介绍这些资源类型，它们是将容器化应用托管运行于Kubernetes集群的重要工具组件。

3.1.2　资源及其在API中的组织形式

在Kubernetes上，资源对象代表了系统上的持久类实体，Kubernetes用这些持久类实体来表达集群的状态，包括容器化的应用程序正运行于哪些节点，每个应用程序有哪些资源可用，以及每个应用程序各自的行为策略，如重启、升级及容错策略等。一个对象可能会包含多个资源，用户可对这些资源执行增、删、改、查等管理操作。Kubernetes通常利用标准的RESTful术语来描述API概念。
资源类型（resource type）是指在URL中使用的名称，如Pod、Namespace和Service等，其URL格式为“GROUP/VERSION/RESOURCE”，如apps/v1/deployment。
所有资源类型都有一个对应的JSON表示格式，称为“种类”（kind）；客户端创建对象必须以JSON提交对象的配置信息。
隶属于同一种资源类型的对象组成的列表称为“集合”（collection），如PodList。
某种类型的单个实例称为“资源”（resource）或“对象”（object），如名为pod-demo的Pod对象。
kind代表着资源对象所属的类型，如Namespace、Deployment、Service及Pod等，而这些资源类型大体又可以分为三个类别，具体如下。
对象（Object）类：对象表示Kubernetes系统上的持久化实体，一个对象可能包含多个资源，客户端可用它执行多种操作。Namespace、Deployment、Service及Pod等都属于这个类别。
列表（List）类：列表通常是指同一类型资源的集合，如PodLists、NodeLists等。
简单（Simple）类：常用于在对象上执行某种特殊操作，或者管理非持久化的实体，如/binding或/status等。
Kubernetes绝大多数的API资源类型都是“对象”，它们代表着集群中某个概念的实例。有一小部分的API资源类型为“虚拟”（virtual）类型，它们用于表达一类“操作”（operation）。所有的对象型资源都拥有一个独有的名称标识以实现其幂等的创建及获取操作，不过，虚拟型资源无须获取或不依赖于幂等性时也可以不使用专用标识符。
有些资源类型隶属于集群范畴，如Namespace和PersistentVolume，而多数资源类型则受限于名称空间，如Pod、Deployment和Service等。名称空间级别的资源的URL路径中含有其所属空间的名称，这些资源对象在名称空间被删除时会被一并删除，并且这些资源对象的访问也将受控于其所属的名称空间级别的授权审查。

Kubernetes将API分割为多个逻辑组合，称为API群组，它们支持单独启用或禁用，并能够再次分解。API Server支持在不同的群组中使用不同的版本，允许各组以不同的速度演进，而且也支持同一群组同时存在不同的版本，如apps/v1、apps/v1beta2和apps/v1beta1，也因此能够在不同的群组中使用同名的资源类型，从而能在稳定版本的群组及新的实验群组中以不同的特性同时使用同一个资源类型。群组化管理的API使得其可以更轻松地进行扩展。当前系统的API Server上的相关信息可通过“kubectl api-versions”命令获取。命令结果中显示的不少API群组在后续的章节中配置资源清单时会多次用到：

[root@master ~]# kubectl api-versions
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
apps/v1beta1
apps/v1beta2
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

Kubernetes的API以层级结构组织在一起，每个API群组表现为一个以“/apis”为根路径的REST路径，不过核心群组core有一个专用的简化路径“/api/v1”。目前，常用的API群组可归为如下两类。
核心群组（core group）：REST路径为/api/v1，在资源的配置信息apiVersion字段中引用时可以不指定路径，而仅给出版本，如“apiVersion: v1”。
命名的群组（named group）：REST路径为/apis/$GROUP_NAME/$VERSION，例如/apis/apps/v1，它在apiVersion字段中引用的格式为“apiVersion:

$GROUP_NAME/
$VERSION”，如“apiVersion: apps/v1”

。
总结起来，名称空间级别的每一个资源类型在API中的URL路径表示都可简单抽象为形如“/apis///namespaces//”的路径，如default名称空间中Deployment类型的路径为/apis/apps/v1/namespaces/default/deployments，通过此路径可获取到default名称空间中所有Deployment对象的列表：

~]$ kubectl get --raw /apis/apps/v1/namespaces/default/deployments | jq .
{
  "kind": "DeploymentList",
  "apiVersion": "apps/v1",
  ……
  "items": [……]
}

另外，Kubernetes还支持用户自定义资源类型，目前常用的方式有三种：一是修改Kubernetes源代码自定义类型；二是创建一个自定义的API Server，并将其聚合至集群中；三是使用自定义资源（Custom Resource Def?inition，CRD）。

3.1.3　访问Kubernetes REST API

以编程的方式访问Kubernetes REST API有助于了解其流式化的集群管理机制，一种常用的方式是使用curl作为HTTP客户端直接通过API Server在集群上操作资源对象模拟请求和响应的过程。不过，由kubeadm部署的Kubernetes集群默认仅支持HTTPS的访问接口，它需进行一系列的认证检查，好在用户也可以借助kubectl proxy命令在本地主机上为API Server启动一个代理网关，由它支持使用HTTP进行通信，其工作逻辑如图3-3所示。
例如，于本地127.0.0.1的8080端口上启动API Server的一个代理网关：

~]$ kubectl proxy --port=8080
Starting to serve on 127.0.0.1:8080

而后即可于另一终端使用curl一类的客户端工具对此套接字地址发起访问请求，例如，请求Kubernetes集群上的NamespaceList资源对象，即列出集群上所有的Namespace对象：

~]$  curl localhost:8080/api/v1/namespaces/
{
  "kind": "NamespaceList",
  "apiVersion": "v1",
  ……
}

或者使用JSON的命令行处理器jq命令对响应的JSON数据流进行内容过滤，例如，下面的命令仅用于显示相关的NamespaceList对象中的各成员对象：

~]$ curl -s localhost:8080/api/v1/namespaces/ | jq .items[].metadata.name
"default"
"kube-public"
"kube-system"

给出特定的Namespace资源对象的名称则能够直接获取相应的资源信息，以kube-system名称空间为例：

~]$ curl -s localhost:8080/api/v1/namespaces/kube-system
{
  "kind": "Namespace",
  "apiVersion": "v1",
  "metadata": {

"name": "kube-system",
"selfLink": "/api/v1/namespaces/kube-system",
"uid": "eb6bf659-9d0e-11e8-bf0d-000c29ab0f5b",
"resourceVersion": "33",
"creationTimestamp": "2018-08-11T02:33:23Z"

},
"spec": {

"finalizers": [
  "kubernetes"
]

},
"status": {

"phase": "Active"

}

上述命令响应的结果中展现了Kubernetes大多数资源对象的资源配置格式，它是一个JSON序列化的数据结构，具有kind、apiVersion、metadata、spec和status五个一级字段，各字段的意义和功能将在3.2节中重点介绍。

3.2　对象类资源格式

Kubernetes API仅接受及响应JSON格式的数据（JSON对象），同时，为了便于使用，它也允许用户提供YAML格式的POST对象，但API Server需要事先自行将其转换为JSON格式后方能提交。API Server接受和返回的所有JSON对象都遵循同一个模式，它们都具有kind和apiVersion字段，用于标识对象所属的资源类型、API群组及相关的版本。
进一步地，大多数的对象或列表类型的资源还需要具有三个嵌套型的字段metadata、spec和status。其中metadata字段为资源提供元数据信息，如名称、隶属的名称空间和标签等；spec则用于定义用户期望的状态，不同的资源类型，其状态的意义也各有不同，例如Pod资源最为核心的功能在于运行容器；而status则记录着活动对象的当前状态信息，它由Kubernetes系统自行维护，对用户来说为只读字段。
每个资源通常仅接受并返回单一类型的数据，而一种类型可以被多个反映特定用例的资源所接受或返回。例如对于Pod类型的资源来说，用户可创建、更新或删除Pod对象，然而，每个Pod对象的metadata、spec和status字段的值却又是各自独立的对象型数据，它们可被单独操作，尤其是status对象，是由Kubernetes系统单独进行自动更新，而不能由用户手动操作它。

3.2.1　资源配置清单

3.1节中曾使用curl命令通过代理的方式于API Server上请求到了kube-system这个Namespace活动对象的状态信息，事实上，用户也可以直接使用“kubectl get TYPE/NAME -o yaml”命令获取任何一个对象的YAML格式的配置清单，或者使用“kubectl get TYPE/NAME -o json”命令获取JSON格式的配置清单。例如，可使用下面的命令获取kube-system的状态：

~]$ kubectl get namespace kube-system -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: 2018-08-11T02:33:23Z
  name: kube-system
  resourceVersion: "33"
  selfLink: /api/v1/namespaces/kube-system
  uid: eb6bf659-9d0e-11e8-bf0d-000c29ab0f5b
spec:
  finalizers:

• kubernetes
  status:

phase: Active
除了极少数的资源之外，Kubernetes系统上的绝大多数资源都是由其使用者所创建的。创建时，需要以与上述输出结果中类似的方式以YAML或JSON序列化方案定义资源的相关配置数据，即用户期望的目标状态，而后再由Kubernetes的底层组件确保活动对象的运行时状态与用户提供的配置清单中定义的状态无限接近。因此，资源的创建要通过用户提供的资源配置清单来进行，其格式类似于kubectl get命令获取到的YAML或JSON形式的输出结果。不过，status字段对用户来说为只读字段，它由Kubernetes集群自动维护。例如，下面就是一个创建Namespace资源时提供的资源配置清单示例，它仅提供了几个必要的字段：

apiVersion: v1
kind: Namespace
metadata:
  name: dev
spec:
  finalizers:

• kubernetes
  将如上所述配置清单中的内容保存于文件中，使用“kubectl create -f /PATH/TO/FILE”命令即可将其创建到集群中。创建完成后查看其YAML或JSON格式的输出结果，可以看到Kubernetes会补全其大部分的字段，并提供相应的数据。事实上，Kubernetes的大多数资源都能够以类似的方式进行创建和查看，而且它们几乎都遵循类似的组织结构，下面的命令显示了第2章中使用kubectl run命令创建的Deployment资源对象myapp的状态信息：

~]$ kubectl get deployment myapp -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
……
  name: myapp
spec:
  replicas: 3
  selector:

matchLabels:
  run: myapp

……
status:
……

为了节约篇幅，上面的输出结果省去了大部分内容，仅保留了其主体结构。从命令结果可以看出，它也遵循Kubernetes API标准的资源组织格式，由apiVersion、kind、metadata、spec和status五个核心字段组成，只是spec字段中嵌套的内容与Namespace资源几乎完全不同。
事实上，对几乎所有的资源来说，apiVersion、kind和metadata字段的功能基本上都是相同的，但spec则用于资源的期望状态，而资源之所以存在类型上的不同，也在于它们的嵌套属性存在显著差别，它由用户定义和维护。而status字段则用于记录活动对象的当前状态，它要与用户在spec中定义的期望状态相同，或者正处于转换为与其相同的过程中。

3.2.2　metadata嵌套字段

metadata字段用于描述对象的属性信息，其内嵌多个字段用于定义资源的元数据，例如name和labels等，这些字段大体可分为必要字段和可选字段两大类。名称空间级别的资源的必选字段包括如下三项。
namespace：指定当前对象隶属的名称空间，默认值为default。
name：设定当前对象的名称，在其所属的名称空间的同一类型中必须唯一。
uid：当前对象的唯一标识符，其唯一性仅发生在特定的时间段和名称空间中；此标识符主要是用于区别拥有同样名字的“已删除”和“重新创建”的同一个名称的对象。
可选字段通常是指由Kubernetes系统自行维护和设置，或者存在默认，或者本身允许使用空值等类型的字段，常用的有如下几个：
labels：设定用于标识当前对象的标签，键值数据，常被用作挑选条件。
annotations：非标识型键值数据，用来作为挑选条件，用于labels的补充。
resourceVersion：当前对象的内部版本标识符，用于让客户端确定对象变动与否。
generation：用于标识当前对象目标状态的代别。
creationTimestamp：当前对象创建日期的时间戳。
deletionTimestamp：当前对象删除日期的时间戳。
此外，用户通过配置清单创建资源时，通常仅需要给出必选字段，可选字段可按需指定，对于用户未明确定义的嵌套字段，则需要由一系列的f?inalizer组件自动予以填充。而用户需要对资源创建的目标资源对象进行强制校验，或者在修改时需要用到initializer组件完成，例如，为每个待创建的Pod对象添加一个Sidecar容器等。不同的资源类型也会存在一些专有的嵌套字段，例如，Conf?igMap资源还支持使用clusterName等。

3.2.3　spec和status字段

Kubernetes用spec来描述所期望的对象应该具有的状态，而用status字段来记录对象在系统上的当前状态，因此status字段仅对活动对象才有意义。这两个字段都属于嵌套类型的字段。在定义资源配置清单时，spec是必须定义的字段，用于描述对象的目标状态，即用户期望对象需要表现出来的特征。status字段则记录了对象的当前状态（或实际状态），此字段值由Kubernetes系统负责填充或更新，用户不能手动进行定义。Master的controller-manager通过相应的控制器组件动态管理并确保对象的实际状态匹配用户所期望的状态，它是一种调和（reconciliation）配置系统。
例如，Deployment是一种用于描述集群中运行的应用的对象，因此，创建Deployment类型的对象时，需要为目标Deployment对象设定spec，指定期望需要运行的Pod副本数量、使用的标签选择器以及Pod模板等。Kubernetes系统读取待创建的Deployment对象的spec以及系统上相应的活动对象的当前状态，必要时进行对象更新以确保status字段吻合spec字段中期望的状态。如果这其中任一实例出现问题（status字段值发生了变化），那么Kubernetes系统则需要及时对spec和status字段的差异做出响应，例如，补足缺失的Pod副本数目等。
spec字段嵌套的字段对于不同的对象类型来说各不相同，具体需要参照Kubernetes API参考手册中的说明分别进行获取，核心资源对象的常用配置字段将会在本书后面的章节中进行讲解。

3.2.4　资源配置清单格式文档

定义资源配置清单时，尽管apiVersion、kind和metadata有章可循，但spec字段对不同的资源来说却是千差万别的，因此用户需要参考Kubernetes API的参考文档来了解各种可用属性字段。好在，Kubernetes在系统上内建了相关的文档，用户可以使用“kubectl explain”命令直接获取相关的使用帮助，它将根据给出的对象类型或相应的嵌套字段来显示相关的下一级文档。例如，要了解Pod资源的一级字段，可以使用类似如下的命令，命令结果会输出支持使用的各一组字段及其说明：

~]$ kubectl explain pods

需要了解某一级字段表示的对象之下的二级对象字段时，只需要指定其一级字段的对象名称即可，三级和四级字段对象等的查看方式依此类推。例如查看Pod资源的Spec对象支持嵌套使用的二级字段，可使用类似如下的命令：

~]$ kubectl explain pods.spec
RESOURCE: spec 

对象的spec字段的文档通常包含RESOURCE、DESCRIPTION和FIELDS几节，其中FIELDS节中给出了可嵌套使用的字段、数据类型及功能描述。例如，上面命令的结果显示在FIELDS中的containers字段的数据类型是一个对象列表（[]Object），而且是一个必选字段。任何值为对象类型数据的字段都会嵌套一到多个下一级字段，例如，Pod对象中的每个容器也是对象类型数据，它同样包含嵌套字段，但容器不支持单独创建，而是要包含于Pod对象的上下文中，其详细信息可通过三级字段来获取，命令及其结果示例如下：

~]$ kubectl explain pods.spec.containers
RESOURCE: containers <[]Object>

DESCRIPTION:

 List of containers belonging to the pod. Containers cannot currently be added

or removed. There must be at least one container in a Pod. Cannot be updated.

 A single application container that you want to run within a pod.

FIELDS:
args <[]string>

 Arguments to the entrypoint. The docker image's CMD is used if this is not 
     provided. ……

command <[]string>

 Entrypoint array. Not executed within a shell. The docker image's
 ENTRYPOINT is used if this is not provided. ……

env <[]Object>

 List of environment variables to set in the container. Cannot be updated.

……

内建文档大大降低了用户手动创建资源配置清单的难度，尝试使用某个资源类型时，explain也的确是用户的常用命令之一。熟悉各常用字段的功用之后，以同类型的现有活动对象的清单为模板可以更快地生成目标资源的配置文件，命令格式为“kubectl get TYPE NAME -o yaml --export”，其中--export选项用于省略输出由系统生成的信息。例如，基于现在的Deployment资源对象myapp生成配置模板deploy-demo.yaml文件，可以使用如下命令：

~]$ kubectl get deployment myapp -o yaml --export > deploy-demo.yaml

通过资源清单文件管理资源对象较之直接通过命令行进行操作有着诸多优势，具体包括命令行的操作方式仅支持部分资源对象的部分属性，而资源清单支持配置资源的所有属性字段，而且使用配置清单文件还能够进行版本追踪、复审等高级功能的操作。本书后续章节中的大部分资源管理操作都会借助于资源配置文件进行。

3.2.5　资源对象管理方式

Kubernetes的API Server遵循声明式编程（declarative programming）范式而设计，侧重于构建程序程序逻辑而无须用户描述其实现流程，用户只需要设定期望的状态，系统即能自行确定需要执行的操作以确保达到用户期望的状态。例如，期望某Deployment控制器管理三个Pod资源对象时，而系统观察到的当前数量却是两个，于是系统就会知道需要创建一个新的Pod资源来满足此期望。Kubernetes的自愈、自治等功能都依赖于其声明式机制。
与此对应的另一种范式称为陈述式编程（imperative programming），代码侧重于通过创建一种告诉计算机如何执行操作的算法来更改程序状态的语句来完成，它与硬件的工作方式密切相关，通常，代码将使用条件语句、循环和类继承等控制结构。为了便于用户使用，Kubernetes的API Server也支持陈述式范式，它直接通过命令及其选项完成对象的管理操作，前面用到的run、expose、delete和get等命令都属于此类，执行时用户需要告诉系统要做什么，例如，使用run命令创建一个有着3个Pod对象副本的Deployment对象，或者通过delete命令删除一个名为myapp的Service对象。
Kubernetes系统的大部分API对象都有着spec和status两个字段，其中，spec用于让用户定义所期望的状态，系统从中读出相关的定义；而status则是系统观察并负责写入的当前状态，用户可以从中获取相关的信息。Kubernetes系统通过控制器监控着系统对象，由其负责让系统当前的状态无限接近用户所期望的状态。
kubectl的命令由此可以分为三类：陈述式命令（imperative command）、陈述式对象配置（imperative object conf?iguration）和声明式对象配置（declarative object conf?iguration）。第一种方式即此前用到的run、expose、delete和get等命令，它们直接作用于Kubernetes系统上的活动对象，简单易用，但不支持代码复用、修改复审及审计日志等功能，这些功能的使用通常要依赖于资源配置文件，这些文件也称为资源清单。在这种模式下，用户可以访问每个对象的完整模式，但用户还需要深入学习Kubernetes API。
如3.2.4节所述，资源清单本质上是一个JSON或YAML格式的文本文件，由资源对象的配置信息组成，支持使用Git等进行版本控制。而用户可以资源清单为基础，在Kubernetes系统上以陈述式或声明式进行资源对象管理，如图3-4所示。

图3-4　基于资源配置清单管理对象

陈述式管理方式包括create、delete、get和replace等命令，与陈述式命令的不同之处在于，它通过资源配置清单读取需要管理的目标资源对象。陈述式对象配置的管理操作直接作用于活动对象，即便仅修改配置清单中的极小一部分内容，使用replace命令进行的对象更新也将会导致整个对象被替换。进一步地，混合使用陈述式命令进行清单文件带外修改时，必然会导致用户丢失活动对象的当前状态。
声明式对象配置并不直接指明要进行的对象管理操作，而是提供配置清单文件给Kubernetes系统，并委托系统跟踪活动对象的状态变动。资源对象的创建、删除及修改操作全部通过唯一的命令apply来完成，并且每次操作时，提供给命令的配置信息都将保存于对象的注解信息（kubectl.kubernetes.io/last-applied-conf?iguration）中，并通过对比检查活动对象的当前状态、注解中的配置信息及资源清单中的配置信息三方进行变更合并，从而实现仅修改变动字段的高级补丁机制。
陈述式对象配置相较于声明式对象配置来说，其缺点在于同一目录下的配置文件必须同时进行同一种操作，例如，要么都创建，要么都更新等，而且其他用户的更新也必须反映在配置文件中，不然其更新在一下次的更新中将会被覆盖。因此，声明式对象配置是优先推荐给用户使用的管理机制。
然而，对于新手来说，陈述式命令的配置方式最易于上手，对系统有所了解后易于切换为使用陈述式对象配置管理方式。因此，若推荐给高级用户则推荐使用声明式配置，并建议同时使用版本控制系统存储所期望的状态，以及跨对象的历史信息，并启用变更复审机制。另外，推荐使用借助于kube-applier等一类的项目实现自动化声明式配置，用户将配置推送到Git仓库中，然后借助此类工具即能将其自动同步于Kubernetes集群上。

3.3　kubectl命令与资源管理

API Server是Kubernetes集群的网关，用户和管理员以及其他客户端仅能通过此网关接口与集群进行交互。API是面向程序员的访问接口，目前可较好地支持Golang和Python编程语言，当然，终端用户更为常用的是通用命令行工具kubectl。访问集群之前，各类客户端需要了解集群的位置并拥有访问集群的凭据才能获取访问许可。使用kubeadm进行集群初始化时，kubeadm init自动生成的/etc/kubernetes/admin.conf文件是客户端接入当前集群时使用的kubeconf?ig文件，它内建了用于访问Kubernetes集群的最高管理权限的用户账号及相关的认证凭据，可由kubectl直接使用。

3.3.1　资源管理操作概述

资源的管理操作可简单归结为增、删、改、查四种，kubectl提供了一系列的子命令用于执行此类任务，如create、delete、patch、apply、replace、edit、get等，其中有些命令必须基于资源清单来进行，如apply和replace命令，也有些命令既可基于清单文件进行，也可实时作用于活动资源之上，如create、get、patch和delete等。
kubectl命令能够读取任何以.yaml、.yml或.json为后缀的文件（可称为配置清单或配置文件，后文将不加区别地使用这两个术语）。实践中，用户既可以为每个资源使用专用的清单文件，也可以将多个相关的资源（例如，属于同一个应用或微服务）组织在同一个清单文件中。不过，如果是YAML格式的清单文件，多个资源彼此之间要使用“---”符号作为单独的一行进行资源分割。这样，多个资源就将以清单文件中定义的次序被create、apply等子命令调用。
kubectl的多数子命令支持使用“-f”选项指定使用的清单文件路径或URL，也可以是存储有清单文件的目录，另外，此选项在同一命令中也可重复使用多次。如果指定的目录路径存在子目录中时，那么可按需同时使用“-R”选项以递归获取子目录中的配置清单。
再者，支持使用标签和注解是Kubernetes系统的一大特色，它为资源管理机制增色不少，而且delete和get等命令能够基于标签挑选目标对象，有些资源甚至必须依赖于标签才能正常使用和工作，例如Service和Pod控制器Deployment等资源对象。子命令label用于管理资源标签，而管理资源注解的子命令则是annotate。
就地更新（修改）现有的资源也是一种常见的操作。apply命令通过比较资源在清单文件中的版本及前一次的版本执行更新操作，它不会对未定义的属性产生额外的作用。edit命令相当于先使用get命令获取资源配置，通过交互式编辑器修改后再自动使用apply命令将其应用。patch命令基于JSON补丁、JSON合并补丁及策略合并补丁对资源进行就地更新操作。
为了利用apply命令的优势，用户应该总是使用apply命令或create --save-conf?ig命令创建资源。

3.3.2　kubectl的基本用法

kubectl是最常用的客户端工具之一，它提供了基于命令行访问Kubernetes API的简洁方式，能够满足对Kubernetes的绝大部分的操作需求。例如，需要创建资源对象时，kubectl会将JSON格式的清单内容以POST方式提交至API Server。本节主要描述kubectl的基本功能。
如果要单独部署kubectl，Kubernetes也提供了相应的单独发行包，或者适配于各平台的程序管理器的相关程序包，如rpm包或deb包等，用户根据平台类型的不同获取相匹配的版本安装完成即可，操作步骤类似于前面的安装方法，因此这里不再给出其具体过程。
kubectl是Kubernetes系统的命令行客户端工具，特性丰富且功能强大，是Kubernetes管理员最常用的集群管理工具。其最基本的语法格式为“kubectl [command] [TYPE] [NAME] [f?lags]”，其中各部分的简要说明如下。
1）command：对资源执行相应操作的子命令，如get、create、delete、run等；常用的核心子命令如表3-1所示。
2）TYPE：要操作的资源对象的类型，如pods、services等；类型名称区分字符大小写，但支持使用简写格式。
3）NAME：对象名称，区分字符大小写；省略时，则表示指定TYPE的所有资源对象；另外，也可以直接使用“TYPE/NAME”的格式来表示资源对象。
4）f?lags：命令行选项，如“-s”或“--server”；另外，get等命令在输出时还有一个常用的标志“-o ”用于指定输出格式，如表3-1所示。

表3-1　kubectl的子命令列表

命令 命令类别 功能说明
create 基础命令（初级） 通过文件或标准输入创建资源
expose 基于rc、service、deployment或pod创建Service资源
run 通过创建Deployment在集群中运行指定的镜像
set 设置指定资源的特定属性
get 基础命令（中级） 显示一个或多个资源
explain 打印资源文档
edit 编辑资源
delete 基于文件名、stdin、资源或名字，以及资源和选择器删除资源
rollout 部署命令 管理资源的滚动更新
rolling-update 对ReplicationController执行滚动升级
scale 伸缩Deployment、ReplicaSet、RC或Job的规模
autoscale 对Deployment、ReplicaSet或RC进行自动伸缩
certif?icate 集群管理命令 配置数字证书资源
cluster-info 打印集群信息
top 打印资源（CPU/Memory/Storage）使用率
cordon 将指定node设定为“不可用”（unschedulable）状态
uncordon 将指定node设定为“可用”（schedulable）状态
drain “排干”指定的node的负载以进入“维护”模式
taint 为node声明污点及标准行为
describe 排错及调试命令 显示指定的资源或资源组的详细信息
logs 显示一个Pod内某容器的日志
attach 附加终端至一个运行中的容器
exec 在容器中执行指定命令
port-forward 将本地的一个或多个端口转发至指定的Pod
proxy 创建能够访问Kubernetes API Server的代理
cp 在容器间复制文件或目录
auth 打印授权信息
apply 高级命令 基于文件或stdin将配置应用于资源
patch 使用策略合并补丁更新资源字段
replace 基于文件或stdin替换一个资源
convert 为不同的API版本转换配置文件
label 设置命令 更新指定资源的label
annotate 更新资源的annotation
completion 输出指定的shell（如bash）的补全码
version 其他命令 打印Kubernetes服务端和客户端的版本信息
api-versions 以“group/version”格式打印服务器支持的API版本信息
conf?ig 配置kubeconf?ig文件的内容
plugin 运行命令行插件
help 打印任一命令的帮助信息

kubectl命令还包含了多种不同的输出格式（如表3-2所示），它们为用户提供了非常灵活的自定义输出机制，如输出为YAML或JSON格式等。

表3-2　kubectl get命令的常用输出格式

输出格式 格式说明
-o wide 显示资源的额外信息
-o name 仅打印资源的名称
-o yaml YAML格式化输出API对象信息
-o json JSON格式化输出API对象信息
-o go-template 以自定义的go模板格式化输出API对象信息
-o custom-columns 自定义要输出的字段

此外，kubectl命令还有许多通用的选项，这个可以使用“kubectl options”命令来获取。下面列举几个比较常用命令。
-s或--server：指定API Server的地址和端口。
--kubeconf?ig：使用的kubeconf?ig文件路径，默认为~/.kube/conf?ig。
--namespace：命令执行的目标名称空间。
kubectl的部分子命令在第2章已经多次提到，余下的大多数命令在后续的章节中还会用到，对于它们的使用说明也将在首次用到时进行展开说明。

3.4　管理名称空间资源

名称空间（Namespace）是Kubernetes集群级别的资源，用于将集群分隔为多个隔离的逻辑分区以配置给不同的用户、租户、环境或项目使用，例如，可以为development、qa和production应用环境分别创建各自的名称空间。
Kubernetes的绝大多数资源都隶属于名称空间级别（另一个是全局级别或集群级别），名称空间资源为这类的资源名称提供了隔离的作用域，同一名称空间内的同一类型资源名必须是唯一的，但跨名称空间时并无此限制。不过，Kubernetes还是有一些资源隶属于集群级别的，如Node、Namespace和PersistentVolume等资源，它们不属于任何名称空间，因此资源对象的名称必须全局唯一。
Kubernetes的名称空间资源不同于Linux系统的名称空间，它们是各自独立的概念。另外，Kubernetes名称空间并不能实现Pod间的通信隔离，它仅用于限制资源对象名称的作用域。

3.4.1　查看名称空间及其资源对象

Kubernetes集群默认提供了几个名称空间用于特定的目的，例如，kube-system主要用于运行系统级资源，而default则为那些未指定名称空间的资源操作提供一个默认值，前面章节中的绝大多数资源管理操作都在default名称空间中进行。“kubectl get namespaces”命令则可以查看namespaces资源：

~]$ kubectl get namespaces
NAME          STATUS    AGE
default       Active    6d
kube-public   Active    6d
kube-system   Active    6d

也可以使用“kubectl describe namespaces”命令查看特定名称空间的详细信息，例如：

~]$ kubectl describe namespaces default

kubectl的资源查看命令在多数情况下应该针对特定的名称空间来进行，为其使用“-n”或“--namespace”选项即可，例如，查看kube-system下的所有Pod资源：

~]$ kubectl get pods -n kube-system
NAME                                 READY    STATUS     RESTARTS    AGE
etcd-master.ikubernetes.io           1/1      Running    1           6d
kube-apiserver-master.ikubernetes.io 1/1      Running    1           6d
……

命令结果显示出kube-system与default名称空间的Pod资源对象并不相同，这正是Namespace资源的名称隔离功能的体现。有了Namespace对象，用户再也不必精心安排资源名称，也不用担心误操作了其他用户的资源。

3.4.2　管理Namespace资源

Namespace是Kubernetes API的标准资源类型之一，如3.2.1节中所述，它的配置主要有kind、apiVersion、metadata和spec等一级字段组成。将3.2.1节中的名称空间配置清单保存于配置文件中，使用陈述式对象配置命令create或声明式对象配置命令apply便能完成创建：

~]$ kubectl apply -f namespace-example.yaml
namespace/dev created

名称空间资源属性较少（通常只需要指定名称即可），简单起见，kubectl为其提供了一个封装的专用陈述式命令“kubectl create namespace”。Namespace资源的名称仅能由字母、数字、连接线、下划线等字符组成。例如，下面的命令可用于创建名为qa的Namespace对象：

~]$ kubectl create namespace qa
namespace/qa created

namespace资源的名称仅能由字母、数字、连接线、下划线等字符组成。
实践中，不建议混用不同类别的管理方式。考虑到声明式对象配置管理机制的强大功能，强烈推荐用户使用apply和patch等命令进行资源创建及修改一类的管理操作。
使用kubectl管理资源时，如果一并提供了名称空间选项，就表示此管理操作仅针对指定名称空间进行，而删除Namespace资源会级联删除其包含的所有其他资源对象。表3-3给出了几个常用的命令格式。

表3-3　结合名称空间使用的删除命令

命令格式 功能
kubectl delete TYPE RESOURCE -n NS 删除指定名称空间内的指定资源
kubectl delete TYPE --all -n NS 删除指定名称空间内的指定类型的所有资源
kubectl delete all -n NS 删除指定名称空间内的所有资源
kubectl delete all --all 删除所有名称空间中的所有资源

需要再次指出的是，Namespace对象仅用于资源对象名称的隔离，它自身并不能隔绝跨名称空间的Pod间通信，那是网络策略（network policy）资源的功能。
3.5　Pod资源的基础管理操作
Pod是Kubernetes API中的核心资源类型，它可以定义在JSON或YAML格式的资源清单中，由资源管理命令进行陈述式或声明式管理。创建时，用户通过create或apply命令将请求提交到API Server并将其保存至集群状态存储系统etcd中，而后由调度器将其调度至最佳目标节点，并被相应节点的kubelet借助于容器引擎创建并启动。这种由用户直接通过API创建的Pod对象也称为自主式Pod。

3.5.1　陈述式对象配置管理方式

陈述式对象配置管理机制，是由用户通过配置文件指定要管理的目标资源对象，而后再由用户借助于命令直接指定Kubernetes系统要执行的管理操作的管理方式，常用的命令有create、delete、replace、get和describe等。
1.创建Pod资源
Pod是标准的Kubernetes API资源，在配置清单中使用kind、apiVersion、metadata和spec字段进行定义，status字段在对象创建后由系统自行维护。Pod对象的核心功用在于运行容器化应用，在其spec字段中嵌套的必选字段是containers，它的值是一个容器对象列表，支持嵌套创建一到多个容器。下面是一个Pod资源清单示例文件，在spec中定义的期望的状态是在Pod对象中基于ikubernetes/myapp: v1镜像运行一个名为myapp的容器：

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  containers:

• name: myapp
  image: ikubernetes/myapp:v1

  
  把上面的内容保存于配置文件中，使用“kubectl [COMMAND] -f /PATH/TO/YAML_FILE”命令以陈述式对象配置进行资源对象的创建，下面是相应的命令及响应结果：

~]$ kubectl create -f pod-example.yaml
pod/pod-example created

如果读者熟悉JSON，也可以直接将清单文件定义为JSON格式；YAML格式的清单文件本身也是由API Server事先将其转换为JSON格式而后才进行应用的。
命令的返回信息表示目标Pod对象pod-example得以成功创建。事实上，create命令中的-f选项也支持使用目录路径或URL，而且目标路径为目录时，还支持使用-R选项进行子目录递归。另外，--record选项可以将命令本身记录为目标对象的注解信息kubernetes.io/change-cause，而--save-conf?ig则能够将提供给命令的资源对象配置信息保存于对象的注解信息kubectl.kubernetes.io/last-applied-conf?iguration中，后一个命令的功用与声明式对象配置命令apply的功能相近。
2.查看Pod状态
get命令默认显示资源对象最为关键的状态信息，而describe等命令则能够打印出Kubernetes资源对象的详细状态。不过，虽然创建时给出的资源清单文件较为简洁，但“kubectl get”命令既可以使用“-o yaml”或“-o json”选项输出资源对象的配置数据及状态，也能够借助于“--custom-columns”选项自定义要显示的字段：

~]$ kubectl get -f pod-example.yaml
NAME          READY     STATUS    RESTARTS    AGE
pod-example   1/1       Running   0           1m
~]$ kubectl get -f pod-example.yaml -o custom-columns=NAME:metadata.name,STATUS:status.phase
NAME          STATUS
pod-example   Running

使用“-o yaml”或“-o json”选项时，get命令能够返回资源对象的元数据、期望的状态及当前状态数据信息，而要打印活动对象的详细信息，则需要describe命令，它可根据资源清单、资源名或卷标等方式过滤输出符合条件的资源对象的信息。命令格式为“kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)”。例如，显示pod-example的详细信息，可使用类似如下的命令：
~]$ kubectl describe -f pod-example.yaml
对于Pod资源对象来说，它能够返回活动对象的元数据、当前状态、容器列表及各容器的详情、存储卷对象列表、QoS类别、事件及相关信息，这些详情对于了解目标资源对象的状态或进行错误排查等操作来说至关重要。
3.更新Pod资源
对于活动对象，并非其每个属性值都支持修改，例如，Pod资源对象的metadata.name字段就不支持修改，除非删除并重建它。对于那些支持修改的属性，比如，容器的image字段，可将其完整的配置清单导出于配置文件中并更新相应的配置数据，而后使用replace命令基于陈述式对象配置的管理机制进行资源对象的更新。例如，将前面创建pod-example时使用的资源清单中的image值修改为“ikubernetes/myapp: v2”，而后执行更新操作：

~]$ kubectl get pods pod-example -o yaml > pod-example-update.yaml
~]$ sed -i 's@(image:).*@ikubernetes/myapp:v2@' pod-example-update.yaml
~]$ kubectl replace -f pod-example-update.yaml
pod/pod-example replaced

更新活动对象的配置时，replace命令要重构整个资源对象，故此它必须基于完整格式的配置信息才能进行活动对象的完全替换。若要基于此前的配置文件进行替换，就必须使用--force选项删除此前的活动对象，而后再进行新建操作，否则命令会返回错误信息。例如，将前面第一步“创建Pod资源”内的配置清单中的镜像修改为“ikubernetes/myapp: v2”后再进行强制替换，命令如下：

~]$ kubectl replace -f pod-example.yaml --force
pod "pod-example" deleted
pod/pod-example replaced

4.删除Pod资源
陈述式对象配置管理方式下的删除操作与创建、查看及更新操作类似，为delete命令使用-f选项指定配置清单即可，例如，删除pod-example.yaml文件中定义的Pod资源对象：

~]$ kubectl delete -f pod-example.yaml
pod "pod-example" deleted

之后再次打印相关配置清单中定义的资源对象即可验正其删除的结果，例如：

~]$ kubectl get -f pod-example.yaml
No resources found.
Error from server (NotFound): pods "pod-example" not found

3.5.2　声明式对象配置管理方式

陈述式对象配置管理机制中，同时指定的多个资源必须进行同一种操作，而且其replace命令是通过完全替换现有的活动对象来进行资源的更新操作，对于生产环境来说，这并非理想的选择。声明式对象配置操作在管理资源对象时将配置信息保存于目标对象的注解中，并通过比较活动对象的当前配置、前一次管理操作时保存于注解中的配置，以及当前命令提供的配置生成更新补丁从而完成活动对象的补丁式更新操作。此类管理操作的常用命令有apply和patch等。
例如，创建3.5.1节中定义的主容器使用“ikubernetes/myapp: v1”镜像的Pod资源对象，还可以使用如下命令进行：

~]$ kubectl apply -f pod-example.yaml
pod/pod-example created

而更新对象的操作，可在直接修改原有资源清单文件后再次对其执行apply命令来完成，例如，修改Pod资源配置清单中的镜像文件为“ikubernetes/myapp: v2”后再次执行如上的apply命令：

~]$ kubectl apply -f pod-example.yaml
pod/pod-example configured

命令结果显示资源重新配置完成并且已经生效。事实上，此类操作也完全能够使用patch命令直接进行补丁操作。而资源对象的删除操作依然可以使用apply命令，但要同时使用--prune选项，命令的格式为“kubectl apply -f --prune -l ”。需要注意的是，此命令异常凶险，因为它将基于标签选择器过滤出所有符合条件的对象，并检查由-f指定的目录中是否存在某配置文件已经定义了相应的资源对象，那些不存在相应定义的资源对象将被删除。因此，删除资源对象的操作依然建议使用陈述式对象配置方式的命令“kubectl delete”进行，这样的命令格式操作目标明确且不易出现偏差。

3.6　本章小结

本章介绍了Kubernetes系统上常用的资源对象类型及其管理方式，在说明kubectl命令行工具的基础用法后借助于Namespace资源对象简单说明了其使用方式，具体如下。
Kubernetes提供了RESTful风格的API，它将各类组件均抽象为“资源”，并通过属性赋值完成实例化。
Kubernetes API支持的资源类型众多，包括Node、Namespace、Pod、Service、Deployment、Conf?igMap等上百种。
标准格式的资源配置大多都是由kind、apiVersion、metadata、spec和status等一级属性字段组成，其中spec是由用户定义的期望状态，而status则是由系统维护的当前状态。
Kubernetes API主要提供的是声明式对象配置接口，但它也支持陈述式命令及陈述式对象配置的管理方式。
kubectl命令功能众多，它将通过子命令完成不同的任务，如create、delete、edit、replace、apply等。
Namespace和Pod是Kubernetes系统的基础资源类型。