Kubernetes系统的API server基于HTTP/HTTPS接收并响应客户端的请求，并提供了基于资源的RESTful风格的编程接口并将集群中的各种组件都抽象成标准的REST资源，并通过标准的HTTP方法以JSON为数据序列化方案进行资源的管理操作。
1、kubernetes的资源对象（依据资源类型分类）
（1）工作负载型资源
工作负载型资源用于确保Pod资源对象能够更好的运行容器化应用。Pod是工作负载型资源中的基础资源，负责运行容器，并为其解决环境依赖。
Pod资源的运行是由工作负载型的资源Pod控制器来管理的；应用程序又有”有状态”和“无状态”两种，所以，管理Pod资源的Pod控制器资源又分以下几种：
1）ReplicationController：用来管理无状态应用，为上一代控制器；用于确保每个Pod副本在任意一时刻都能满足目标数量。
2）ReplicaSet：用来管理无状态应用，新一代ReplicationController控制器；支持基于集合的选择器
3）Deployment：用于管理无状态的持久化应用，建立在ReplicaSet之上，用于为Pod和ReplicaSet提供申明式更新。
4）StatefulSet：管理有状态持久化应用，会为每个Pod创建一个独有的持久性标识符，并会确保各Pod之间的顺序性。
5）DaemonSet：用于确保每个节点都运行了某Pod的一个副本。
6）Job：用于管理运行完成后即可终止的应用。
（2）、发现和负载均衡性资源
发现和负载均衡性资源用于让具有同一种负载的各Pod对象以负载均衡的方式服务于各请求，并让各种容器化应用彼此之间需要彼此发现以完成工作协同。
（3）配置与存储
存储型资源能够为重构的pod对象提供持久化数据存储机制；configmap资源能够以环境变量或存储卷的方式将配置接入到Pod资源的容器中，并且可被多个同类的的Pod共享引用。
（4）集群级资源
集群类型的资源为管理集群本身的工作提醒提供了配置接口；集群资源仅供集群管理员操作，集群资源主要类型有：
1）Namespace：集群对象名称的作用范围，即名称空间，新创建资源默认属于“default”
2）Node：kubernetes集群工作的节点
3）Role：名称空间级别的由规则组成的权限集合，可被RoleBinding引用
4）ClusterRole：Cluster级别的由规则组成的权限集合，可被RoleBinding和ClusterRole Binding应用
5）RoleBinding：将Role中的许可权限绑定在一个或一组用户至上隶属于且仅能作用于一个名称空间。
6）ClusterRoleBinding：将ClusterRole中定义的许可权限绑定在一个或一组用户至上。
（5）元数据型资源
元数据型资源用于配置集群内部其他资源的行为。
2、对象类资源格式以及配置
Kubernetes系统上的大多数资源都是由使用者自己创建的；在创建资源时，需要用户以YAML（创建资源时API server会将yaml格式的资源配置清单转化为json格式）或者json序列化的方式定义资源的配置清单。
# 查看名称空间kube-system的资源配置清单
[root@master01 ~]# kubectl get namespace kube-system -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2019-01-07T08:21:37Z"
name: kube-system
resourceVersion: "35"
selfLink: /api/v1/namespaces/kube-system
uid: 40350bba-1255-11e9-9f5c-000c298d15e0
spec:
finalizers:
- kubernetes
status:
phase: Active
# 查看service的资源配置清单
[root@master01 ~]# kubectl get svc nginx-svc -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2019-01-07T09:04:37Z"
labels:
run: nginx-deploy
. . . . . .
spec:
clusterIP: 10.96.249.26
externalTrafficPolicy: Cluster
ports:
- nodePort: 30003
port: 80
selector:
run: nginx-deploy
status:
loadBalancer: {}
通过查看系统默认的名称空间以及创建的service的资源配置清单可以发现资源配置清单中主要包括”apiVersion”、”kind”、”meadata”、”spec”、”status”等五个字段以及这五个字段下的各个子字段。
（1）apiVersion
apiVersion主要用于定义API的群组以及相关的版本，定义的格式为groupname/version
（2）kind
Kind主要用于定义资源的类型，如Namespace、Pod、Service、Deployment
（3）metadata
Metadata字段用于描述对象的属性信息，其内嵌单个字段用于定义资源的元数据，这些字段大体可分为必要字段和可选字段两大类：
1）名称空间内的必选字段：
namespace：指定当前隶属的名称空间，默认为default
name：设定当前对象名称，在其所属的名称空间的同一类型中必须唯一
uid：当前对象的唯一表示符
2）常用的可选字段
labels：标识当前对象的标签，键值数据，常被用作挑选条件
annotation：作为挑选条件，作为labels的补充
resourceVersion：当前对象的内部版本标识符
generation：用于表示当前对象目标状态的代码
creationTimestamp：当前对象创建日期的时间戳
deletionTimestamp：当前对象删除日期的时间戳
（4）spec字段
Spec字段用来描述所期望的对象应该具有的状态
（5）status
Status字段用来记录对象在系统上的当前状态，而status字段仅对活动对象有意义；在资源配置清单中不需要定义status字段，此字段是由kubernetes系统填充或更新。
在创建资源的配置清单时，由于metadata字段及spec字段中多个及多层次的嵌套字段，要想了解某个某个字段及嵌套字段的用法可使用”kubectl explain ”命令查看。
# 查看pod资源的定义
[root@master01 ~]# kubectl explain pod
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
# 查看pod资源中metadata字段下的namespace字段的用法
[root@master01 ~]# kubectl explain pod.metadata.namespace
KIND: Pod
VERSION: v1
FIELD: namespace <string>
DESCRIPTION:
Namespace defines the space within each name must be unique. An empty
namespace is equivalent to the "default" namespace, but "default" is the
canonical representation. Not all objects are required tobe scoped to a
namespace - the value of this field for those objects will be empty. Must
be a DNS_LABEL. Cannot be updated. More info:
http://kubernetes.io/docs/user-guide/namespaces