3.1.1 Kubernetes 的资源对象
依据资源的主要功能作为分类标准。Kubernetes的API对象大体可分为工作负载（Workload）、发现和负载均衡（Discovery & LB）、存储和配置（Config & Storage）、集群（Cluster）以及元数据（Metadata）五个类别。它们基本上都是围绕一个核心目的而设计：如何更好的运行和丰富Pod资源，从而为容器和应用提供更灵活、更完善的操作与管理组件，如图3-2所示：
工作负载型资源用于确保Pod资源对象能够更好地运行容器化应用，具有同一种负载的各Pod对象需要以负载的方式服务于各请求，而各种容器化应用彼此之间需要彼此“发现”以完成工作协同。Pod资源具有生命周期，存储型资源能够为重构的Pod对象提供持久化的数据存储机制，共享同一配置的Pod资源可从配置型资源中统一获取配置改动信息，这些资源作为配置中心为管理容器化应用的配置文件提供了极为便捷的管理机制。集群型资源为管理集群本身的工作特性提供了配置接口，而元数据型资源则用于配置集群内部的其他资源的行为。
工作负载型资源
Pod 是工作负载型资源中的基础资源，它负责运行容器，并为其解决环境的依赖，例如，向容器内注入共享的或持久化的存储卷、配置信息或秘钥数据等。但Pod可能会因为资源超限或节点故障等原因而终止，这些非正常终止的Pod资源需要被重建，不过，这类工作将由工作负载型的控制器来完成，它们通常也称为Pod控制器。
应用程序分为无状态和有状态两种类型，它们对环境的依赖及工作特性有很大的不同，因此分属两种不同类型的Pod控制器来管理，ReplicationController、ReplicaSet和Deployment负责管理无状态应用，StatufulSet用于管控有状态类应用。ReplicationController是上一代的控制器，其功能由ReplicaSet和Deployment负责实现，因此几近于废弃。还有些应用较为独特，它们需要在集群中的每个节点上运行单个Pod资源，负责收集日志或运行系统服务等任务，这些Pod资源的管理则属于DaemonSet控制器的分内之事。另外，有些容器化应用需要继续运行以为守护进程不间断地提供服务，而有些则因该在正常完成后退出，这些在正常完成后就应该退出的容器化应用则由Job控制器负责管控。下面是各Pod控制器更为详细的说明。
ReplicationController：用于确保每个Pod副本在任一时刻均能满足目标数量，换言之，用于保证每个容器或容器组总是运行并且可访问；它是上一代的无状态Pod应用控制器，建议读者使用新型控制器Deployment和ReplicaSet来取代它。
ReplicaSet：新一代ReplicationController，它与ReplicationController的唯一不同之处仅在于支持的标签选择器不同，ReplicationController只支持等值选择器，而ReplicaSet还额外支持基于集合的选择器。
Deployment：用于管理无状态的持久化应用，例如 HTTP 服务器；它用于为 Pod 和 ReplicaSet 提供声明式更新，是构建在 ReplicaSet 之上更为高级的控制器。
StatufulSet：用于管理无状态的持久化应用，如Database服务程序；其与Deployment的不同之处在于StatufulSet会为每个Pod创建一个独有的持久性标识符，并会确保各Pod之间的顺序性。
DaemonSet：用于确保每个节点都运行了某Pod的一个副本，新增的节点一样会被添加此类Pod；在节点移除的时，此类Pod会被回收；DaemonSet常用于运行集群存储守护进程——如glusterd和ceph，还有日志收集进程——如fluentd和logstash，以及监控进程——如Prometheus的Node exporter、collectd、Datadog agent和Ganglia的gmond等。
Job： 用于管理运行完成后即可终止的应用，例如批处理作业任务；换句话说，Job创建一个或多个Pod，并确保其符合目标数量，直到Pod正常结束而中。
发现和负责均衡
Pod资源可能会因为任何意外故障而被重建，于是它需要固定的可被“发现”的方式。另外，Pod资源仅在集群内可见，它的客户端也可能是集群内的其他Pod资源，若要开放给外部网络中的用户访问，则需要事先将其暴露到集群外部，并且要为同一种工作负载的访问流量进行负载均衡。Kubernetes使用标准的资源对象来解决此类问题，它们是用于为工作负载添加发现机制及负载均衡功能的Service资源和Endpoint资源，以及通过七次代理实现请求流量负载均衡的Ingress资源。
配置和存储
Docker容器分层联合挂载的方式决定了不宜再容器内部存储需要持久化的数据，于是它通过引入挂载外部存储卷的方式来解决此类问题，而Kubernetes则为此设计了Volume资源，它支持众多类型的存储设备和存储系统，如GlusterFS、CEPH RBD和Flocker等，另外，新版本的kubernetes还支持通过标准的CSI(Container Storage interface)统一存储接口以及扩展支持更多类型的存储系统。
另外，基于镜像构建容器应用时，其配置信息于镜像制作时焙人，从而为不同的环境定制配置就变得比较困难。Docker使用环境变量等作为解决方案，但这么一来就得于容器启动时将值传入，且无法在运行时修改。ConfigMap资源能够以环境变量或存储卷的方式接入到Pod资源的容器中，并且被多个同类的Pod共享引用，从而实现“一次修改，多处生效”。不过，这种方式不适用于存储敏感数据，如私钥、密码等，那是另一个资源类型Secret的功能。
集群级资源
Pod、Deployment、Service和ConfigMap等资源属于名称空间级别，可由相应的项目管理员所管理。然而，Kubernetes还存在一些集群级别的资源，用于定义集群自身配置信息的对象，它们仅应该有集群管理员进行操作。集群级资源主要包含以下集中类型。
- Namespace：资源对象名称的作用范围，绝大多数对象都隶属与某个名称空间，默认隶属于“default”。
- Node：Kubernetes集群的工作节点，其标识符再当前的集群中必须是唯一的。
- Role：名称空间级别的有规则组成的权限集合，可被RoleBinding引用。
- ClusterRole：Cluster级别的由规则组成的权限集合，可被Rolebinding和ClusterRoleBinding引用。
- RoleBinding：将Role中的许可权限绑定在一个或一组用户之上，它隶属与且仅能作用于一个名称空间；绑定时，可以引用同一名称空间的Role，也可以引用全局名称空间中的ClusterRole。
- ClusterRoleBinding：将ClusterRole中定义的许可权限绑定在一个或一组用户之上；它能够引用全局名称空间中的ClusterRole，并能通过Subject添加相关信息。
元数据型资源
此类资源对象用于为集群内部的其他资源配置其行为或特性，如HorizontalPodAutoscaler资源可用于自动伸缩工作负载类型的资源对象的规模，Pod模板资源可用于为Pod资源的穿件预制模板，而LimitRange则可以为名称空间的资源设置其CPU和内存等系统级资源的数量限制等。
一个应用通常需要多个资源的支撑，例如，使用Deployment资源管理应用实例（Pod）、使用ConfigMap资源保存应用配置、使用Service和Ingress资源暴露服务、使用Volume资源提供外部存储等。
本书后面篇幅的主题部分就展开介绍这些资源类型，它们是将容器化应用托管运行于Kubernetes集群的重要工具组件。