依据资源的主要功能作为分类标准，Kubernetes的API对象大体可分为工作负载（Workload）、发现和负载均衡（Discovery & LB）、配置和存储（Config & Storage）、集群（Cluster）和元数据（Metadata）几个类别。它们基本都是围绕一个核心目的而设计：如何更好地运行和丰富Pod资源，从而为容器化应用提供更灵活和更完善的操作与管理组件。
工作负载型资源用于确保Pod资源对象更好地运行容器化应用，具有同一种负载的各Pod对象需要以“负载均衡”的方式服务于各请求，而各种容器化应用彼此间需要彼此“发现”以完成工作协同。Pod资源具有生命周期，存储型资源能够为重构的Pod对象提供持久化数据存储机制，共享同一配置的Pod资源可从“配置”型资源中统一获取配置改动信息，这些资源作为“配置中心”为管理容器化应用的配置文件提供了极为便捷的管理机制。集群型资源为管理集群本身的工作特性提供了配置接口，而元数据型资源用于配置集群内部的其他资源的行为。
Pod用于承载容器化应用，它代表着Kubernetes之上工作负载的表现形式。它负责运行容器，并为其解决环境性的依赖，例如向容器注入临时或持久化的存储空间、配置信息或密钥数据等。而诸如滚动更新、扩容和缩容一类的编排任务则由“控制器”对象负责，专用于Pod编排任务的控制器也可统称为Pod控制器。
应用程序分为无状态和有状态两种类型，无状态应用中的每个Pod实例均可被其他同类实例所取代，但有状态应用的每个Pod实例均有其独特性，必须单独标识和管理，因而它们分属两种不同类型的Pod控制器进行管理，ReplicationController、ReplicaSet和Deployment负责管理无状态应用，StatefulSet则专用于管控有状态类应用。还有些应用较为独特，有些需要在集群中的每个节点上运行单个Pod资源，负责收集日志或运行系统服务等任务，该类编排操作由DaemonSet控制器对象进行，而那些需要在正常完成后退出而无需始终处于运行状态任务的编排工作则隶属Job控制器对象，CronJob控制器对象还能为Job型的任务提供定期执行机制。
- ReplicationController：用于确保每个pod副本在任一时刻均能满足目标数量，换言之，即它用于保证每个容器或容器组总是运行并可访问；它是上一代的无状态Pod应用控制器，建议读者使用新型控制器Deployment和ReplicaSet来取代它。
- ReplicaSet：新一代ReplicationController，它与ReplicationController的唯一不同之处仅在于支持的标签选择器不同：ReplicationController只支持“等值选择器”，而ReplicaSet还额外支持基于集合的选择器。
- Deployment：用于管理无状态的持久化应用，例如http服务等；它用于为Pod和ReplicaSet提供声明式更新，是建构在ReplicaSet之上的更为高级的控制器。
- StatefulSet：用于管理有状态的持久化应用，例如database服务程序；与Deployment的不同之处在于StatefulSet会为每个Pod创建一个独有的持久性标识符，并会确保各Pod间的顺序性。
- DaemonSet：用于确保每个节点都运行了某Pod的一个副本，包括后来新增的节点；而节点移除将导致Pod回收；DaemonSet常用于运行各类系统级守护进程，例如kube-proxy和flannel网络插件，以及日志收集和临近系统的agent应用，例如fluentd、logstash、Prometheus的Node Exporter等。
- Job：用于管理运行完成后即可终止的应用，例如批处理作业任务；Job创建一个或多个Pod，并确保其符合目标数量，直到应用完成而终止。
Service是Kubernetes标准的资源类型之一，用于为工作负载实例提供固定的访问入口及负载均衡服务，它把每个可用后端实例定义为Endpoint资源对象，通过IP地址和端口等属性映射至Pod实例或相应的服务端点。Ingress资源则为工作负载提供7层（HTTP/HTTPS）代理及负载均衡功能。
Kubernetes也支持在Pod级别附加Volume资源对象为容器附加可用的外部存储。它支持众多类型的存储设备或存储系统，例如GlusterFS、CEPH RBD和Flocker等，还可通过FlexVolume及CSI（Container Storage Interface）存储接口扩展支持更多类型的存储系统。
