k8s 重启pod_k8s中的所有api-resources类型简介

想要清楚了解k8s的功能和运作方式，知道apiserver的工作方式远远不够，需要知道apiserver中有哪些类型的资源(api-resources)才能知道k8s的能力边界在哪里，在看到新功能/新故障时才能快速得出自己的理解和判断。

那么直接进入正题，有哪些api-resources呢？运行kubectl api-resources可以得到一个完整的列表，我们可以依次分析他们。而分析的方法也非常简单，使用kubectl explain $resource_name即可，如果仍有不明白的则可以结合网上资料/代码理解。

在阅读以下内容前至少需要了解的内容：apiServer，etcd

本次分析的版本为1.17.4，使用Calico作为网络组件，总共有67种不同的api-resources。

1. Binding: 已弃用。用于记录一个object和另一个object的绑定关系。实际上主要用于将pod和node关系，所以在1.7版本后已经改为在pods.bindings中记录了。
2. ComponentStatus: 是一个全局的list（即不受命名空间影响），记录了k8s中所有的组件的的相关信息，比如创建时间，现在状态等。
3. Configmap: 是一种用于记录pod本身或其内部配置信息的API资源，可以认为是通过API形式存储的配置文件。
4. Endpoints: 用于记录每个service的pod的真实物理ip和port的对应关系，包括service是TCP还是UDP等。
5. Event: 用于记录集群中的事件，可以认为类似于日志里的一条记录。
6. LimitRange: 用于记录各个命名空间中的pod或container对每种资源的使用限制，一般被包含在pod的定义中。
7. Namespace: 是一个全局的list，保存集群中所有的命名空间。
8. Node: 是一个全局的list，详细记录了每个节点的name, labels, PodCIDR, host IP, hostname, 总资源（cpu，内存），可分配资源，各心跳状态（网络，内存，硬盘，PID数量，kubelet等），kubelet的物理port，各k8s组件image信息，node环境信息（os, CRI version, kubeProxy version, kubelet version等）。
9. PersistentVolumeClaim: 记录用户对持久化存储的要求。
10. PersistentVolume: 是一个全局的object，记录了所有的持久化存储设备的信息（类似于node）</