Kubernetes API主要由资源类型和控制器两部分组成，资源通常是声明为JSON或YAML格式并写入集群的对象，而控制器则在集群将资源存储完成后自动创建并启动。Kubernetes把应用及辅助应用容器化和编排的各种组件均抽象成了API资源。

Kubernetes系统的API Server基于HTTP/HTTPS协议接收并响应客户端的操作请求，它提供了一种“基于资源”的RESTful风格的编程接口，把集群各种组件都抽象成标准的RESTful资源，并支持通过标准的HTTP方法、以JSON为数据序列化方案进行资源管理操作。

以资源的主要功能作为分类标准，Kubernetes的API对象大体可分为工作负载、发现与负载均衡、配置与存储、集群和元数据几个类别。它们基本都是围绕一个核心目的而设计：如何更好地运行和丰富Pod资源，从而为容器化应用提供更灵活和更完善的操作与管理组件。

应用程序分为无状态和有状态两种类型，无状态应用中的每个Pod实例均可被其他同类实例所取代，但有状态应用的每个Pod实例均有其独特性，必须单独标识和管理，因而它们分别由两种不同类型的Pod控制器进行管理。

ReplicationController：用于确保每个Pod副本在任一时刻均能满足目标数量，即它用于保证每个容器或容器组总是运行并可访问；它是上一代的无状态Pod应用控制器，建议读者使用新型控制器Deployment和ReplicaSet来取代它。

ReplicaSet：新一代ReplicationController，它与ReplicationController唯一不同之处在于支持的标签选择器不同，ReplicationController只支持“等值选择器”，而ReplicaSet还支持基于集合的选择器。

Deployment：用于管理无状态的持久化应用，例如HTTP服务等；它用于为Pod和ReplicaSet提供声明式更新，是构建在ReplicaSet之上的、更为高级的控制器。

StatefulSet：用于管理有状态的持久化应用，例如数据库服务程序；与Deployment的不同之处在于，StatefulSet会为每个Pod创建一个独有的持久性标识符，并会确保各Pod间的顺序性。

DaemonSet：用于确保每个节点都运行了某Pod的一个副本，包括后来新增的节点；而节点移除将导致Pod回收；DaemonSet常用于运行各类系统级守护进程，例如kube-proxy和Flannel网络插件，以及日志收集和临近系统的Agent应用，例如fluentd、Logstash、Prometheus的Node Exporter等。

Job：用于管理运行完成后即可终止的应用，例如批处理作业任务；Job创建一个或多个Pod，并确保其符合目标数量，直到应用完成而终止。

一个应用通常需要多个资源的支撑，例如用Deployment资源编排应用实例（Pod）、用ConfigMap和Secret资源保存应用配置、用Service或Ingress资源暴露服务、用Volume资源提供持久化存储等。

kubernetes还支持由用户自定义资源类型，目前常用的方式有3种：一是修改Kubernetes源代码自定义类型；二是创建一个自定义的API Server，并将其聚合至集群中；三是使用CRD（Custom Resource Definition，自定义资源），它们都可用于API群组扩展。

为安全起见，kubeadm部署的API Server通常仅支持双向SSL/TLS认证的HTTPS通信，客户端需要事先在服务器端认证才能与之建立通信。