Kubernetes资源对象管理-CFANZ编程社区

API对象：也就是K8S的资源对象，是K8S集群中的管理操作单元。K8S集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。

一、Kubernetes资源对象查询

1.1 查询资源类型

#列出当前集群中所有的资源类型
kubectl api-resources

Kubernetes资源对象管理_Kubernetes

字段说明

NAME：资源名(复数形式)
SHORTNAMES：资源名称的简写
APIVERSION：API版本。每个资源都有自己的API组，这样划分的目的是便于管理资源类型及其版本演进(即以组为单位进行版本演进。单独的资源类型作单位去管理粒度太小，所有资源类型放在一起管理粒度又太粗糙)
NAMESPACED：说明是否为命名空间级别的资源类型。true表示该资源类型是名称空间级别，false表示该资源类型为集群级别，而非名称空间级别
KIND：资源类型标识(单数形式)

关于NAMESPACED的相关说明如下：

简单的说，Pod是资源类型，创建出来的nginx-pod就是实例化出来的对象。对象的标识符即对象名，不能重复(eg：只能有一个名叫nginx-pod的pod)。为降低名称冲突的概率，使用名称作用域(名称空间，这里特指Kubernetes的名称空间，与Linux内核的namespace有区别)做区分。

名称作用域存在两个级别：Cluster和Namespace。资源类型也有级别的概念，类型所属的级别，代表着创建资源对象所属的级别。如果某个资源类型是namespace级别，则它只能在namespace内创建

1.2 查看资源对象的字段

以Pod资源类型为例

kubectl explain pod：查看资源的模板(有哪些字段)

由于以上列出的字段只是一级字段，可能包含二级甚至三级字段，未列出所有字段。可以加上--recursive来列出所有可能的字段，即 kubectl explain pod --recursive

Kubernetes资源对象管理_资源对象_02

Kubernetes资源对象管理_资源对象_03

kubectl explain pod.apiVersion 查看详细字段

Kubernetes资源对象管理_Kubernetes_04

1.2.1 API资源规范说明

apiVersion: <String> 标明该类型所属的API群组(API版本)
Kind: <String> 指定资源类型。可以通过 kubectl api-resources 查询，或者直接看 explain 的结果
metadata: <Object> 元数据，标识API对象(名称、标签、命名空间(不含集群级别的资源))
spec: <Object>，定义资源对象的终态。描述了资源对象的期望状态，希望资源对象所具有的特征

注意：以上四个需用户定义

status: <Object>, 资源的实际状态，由系统组件自行负责维护

1.3 查看API版本

相近的资源类型，会被划分至同一个组中；不同的功能，会被分类到不同的组合。每个组的版本号可独立演进(eg：v0.1->v0.2)。

#查看api版本
kubectl api-versions
#显示效果。也可以看作是一个个分组
admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
autoscaling/v1
autoscaling/v2
batch/v1
certificates.k8s.io/v1
coordination.k8s.io/v1
discovery.k8s.io/v1
events.k8s.io/v1
flowcontrol.apiserver.k8s.io/v1beta2
flowcontrol.apiserver.k8s.io/v1beta3
networking.k8s.io/v1
node.k8s.io/v1
policy/v1
rbac.authorization.k8s.io/v1
scheduling.k8s.io/v1
storage.k8s.io/v1
v1

其中，v1指的是core/v1(核心群组)，可省略。位于该组中的资源基本上都是支撑Kubernetes基本功能的资源类型。

版本号可分为如下几类：

alpha：内测版。可能会发生bug，由此或产生较大变动。
beta：公测版。可能会有变动，但变动频率不像alpha那么高。已启用的功能被认为是安全的，相比alpha算是稳定的。
stable：稳定版，可安全使用。

二、对Kubernetes功能的理解

K8S核心功能：以应用为中心的应用编排平台。围绕编排运行应用的各种需求，被分别组织到多个资源类型中(这些需求由多个不同的资源类型实现)。

比如，创建一个mysql，需要创建pod。为了更好的管理pod，则创建一个Deployment资源(选择合适的工作负载型控制器，便于编排)。

那如何让客户端访问？使用Service，甚至是Ingress作为服务的访问入口。

为了实现高可用，要做pod销毁预算(最多销毁几个)。流量大了还要做动态扩缩容(HPA水平扩展，VPA垂直扩展)。

为了让应用持久化的存储数据，要配置Volume(ConfigMap，PVC，Secret)。

所以，要定义一个应用，要创建多个资源对象来完成一个应用编排所期望的所有功能。

Kubernetes资源对象管理_Kubernetes_05

三、Kubernetes的三种对象管理机制

3.1 指令式命令

通过命令行直接作用于集群上的活动对象，完成一次性的操作。

kubectl create deployment
kubectl create service nodeport
kubectl get nodes
kubectl delete node k8s-node1

3.2 指令式对象配置

对指令式对象配置的简单理解就是，比如创建一个目录，一开始这个目录没有，创建是成功的。再执行创建命令就会报错。对于Kubernetes而言，同一个pod.yml多次创建会报错。原因在于，K8S中资源名称必须唯一。该名称的pod已创建过了。

指令式对象配置体现的是要怎么样创建资源。

指令式对象配置只能独立引用每个配置清单文件。

关于指令式对象配置，简单的认为是：命令+yml配置文件(里面是命令需要的各种参数)

kubectl get -f xxx.yml
kubectl delete -f xxx.yml

3.3 声明式对象配置

声明式对象配置只支持kubectl apply命令。

声明式对象配置体现的是我要什么样的效果。

其实声明式对象配置就是使用apply描述一个资源最终的状态（在yaml中定义状态)。

声明式对象配置可直接引用目录下的所有配置清单文件，也可直接作用于单个配置文件。

使用apply操作资源时：　　　　　　　　　　

如果资源不存在，就创建，相当于 kubectl create　　　　　　　　
如果资源已存在，就更新，相当于 kubectl patch