02- Kubernetes的核心-API对象

1. 什么是 API 对象

作为一个集群操作系统，Kubernetes 归纳总结了 Google 多年的经验，在理论层面抽象出了很多个概念，用来描述系统的管理运维工作，这些概念就叫做 “API 对象”。这些 API 对象全面地描述了集群的节点、应用、配置、服务、账号等等信息，apiserver 会把它们都存储在数据库 etcd 里，然后 kubelet、scheduler、controller-manager 等组件通过 apiserver 来操作它们，就在 API 对象这个抽象层次实现了对整个集群的管理。

kubectl api-resources 查看系统支持的API对象

2. API 对象的4大属性

API 对象是Kubernetes集群中的管理操作单元。

Kubernetes 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持该功能的管理操作。

每个API对象都有四大属性：

• typemeta
• metaData
• spec
• status

typemeta

Kubernetes对象的最基本定义，它通过引入GKV（Group、Kind、apiVersion）模型定义了一个对象的类型。

① apiVersion：

社区每个季度会推出一个Kubernetes版本，随着Kubernetes版本的演进，对象从创建之初到能够完全生产化就绪的版本是不断变化的。与软件版本类似，通常社区提出一个模型定义以后，随着该对象不断成熟，其版本可能会从v1alpha1到vqaplha2,或者到v1beta1，最终变成生产就绪版本v1。

② Group：

Kubernetes定义了非常多的对象，如何将这些对象进行归类是一门学问，将对象依据其功能范围归入不同的分组，比如把支撑最基本功能的对象归入 core 组，把与应用部署相关的对象归入 apps 组，会使这些对象的可维护性和可理解性更高。

核心组的组名可以省略，如pod对象，

③ kind：

定义一个对象的基本类型，比如Node、Pod、Deployment等

metadata

定义了对象的 名称、命名空间 归属、对象拥有的标签和一些拓展属性。名称和命名空间归属唯一定义了某个对象实例。

① name：

定义了对象的名称

② namespace：

定义了对象所处的命名空间，有些对象是集群层级的，就不涉及命名空间了，如 pv。

③ label：

顾名思义就是给对象打标签，一个对象可以有任意对标签，其存在形式是键值对。

• Label 定义了对象的可识别属性，Kubernetes API支持以Label作为过滤条件查询对象。
• Label 是识别Kubernetes对象的标签，以key/value 的方式附加到对象上。
• Key 最长不能超63字节，value可以为空，也可以是不超过253字节的字符串。
• Label 不提供唯一性，并且实际上经常是有很多对象（如Pods）都使用相同的label来标志具体的应用。
• Label 定义好后其他对象可以使用 Label Selector来选择一组相同label的对象。
• Label 也是调度中污点、容忍度的重要依据。

④ annotation：

annotation 与 label 一样用键值对来定义，但 annotation 是作为属性扩展，更多面向系统管理员和开发人员，因此需要像其他属性一样做合理归类。

• Annotations 是 key/value 形式附加于对象的注解。
• 不同于 Labels 用于标志和选择对象，Annotation则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。

比如 ingress controller 控制器就会使用这些拓展引入 https属性。

spec 和 status

Spec 和 Status 才是对象的核心。

Spec 是用户的期望状态，由创建对象的用户端来定义。

Status 是对象的实际状态，由对应的控制器收集实际状态并更新。

与TypeMeta和Metadata等通用属性不同，Spec和Status是每个对象独有的。

3. 常用对象及分组

核心对象的资源清单编写时候，apiVersion的group可以省略，core/v1 → v1

本图只是作为参考，随着 Kubernets 的版本更新，版本可能会随之改变，每个人的具体情况，可以通过 kubectl kubectl api-resources 进行查看。

4. 如何创建 API对象

当使用 Kubernetes API 创建对象时（直接创建或经由 kubectl 创建）， API 请求必须在请求主体中包含 JSON 格式的信息。 大多数情况下，你会通过 清单（Manifest) 文件为 kubectl 提供这些信息。 按照惯例，清单是 YAML 格式的（你也可以使用 JSON 格式）。

5. 编写资源清单

技巧一：kubectl api-resources

kubectl api-resources 是一个命令行工具，用于列出 Kubernetes 集群中当前可用的 API 资源。

通过运行 kubectl api-resources，你可以快速查找集群中支持的资源类型，并探索它们的属性、功能和用法。这对于管理和操作 Kubernetes 集群中的资源非常有用，特别是在编写 YAML 文件或执行命令时需要指定资源类型时。

技巧二：kubectl explain

查看 API 对象或对象中某个字段 的详细使用信息。以.作为层级区分。

kubectl explain pod
kubectl explain pod.metadata
kubectl explain pod.spec
kubectl explain pod.spec.containers 

技巧三：kubectl run 生成样板文件

kubectl run pod nginx --image=nginx:1.22.1 --dry-run=client -o yaml

该条命令的含义是

• kubectl run: 这个部分指定要运行的 Kubernetes 资源类型，这里是一个 pod。
• nginx: 这个参数指定 pod 的名称。
• --image=nginx:1.22.1: 这个参数指定了要使用的容器镜像及其版本。这里使用的是 nginx 容器的 1.22.1 版本。
• --dry-run=client: 这个参数告诉 kubectl 不要真正创建 pod，而是输出创建的 pod 配置的 YAML 文件。
• -o yaml: 这个参数指定输出的格式为 YAML。

6. 资源清单案例

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: default
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80