Kubernetes API 元件

Kubernetes的API 元件（Primitive）用于描述在Kubernetes上运行应用程序的基本组件，这些元件也就是俗称的Kubernetes对象（Object），它们持久存储于API Server上，用于描述集群的状态，例如，支行了哪些容器化的应用程序，这些应用支行于哪些节点之上以及使用了哪些存储，可用的资源有哪些，受控于何种编排机制以完成升级、回滚和容错等等。
绝大多数的Kubernetes对象都包含spec和status两个嵌套字段：
spec字段存储对象的期望状态（或称为应有状态），由用户在创建时提供，随后也可按需进行更新（但有些属性并不支持就地更新机制）；
status字段存储对象的实际状态（或称为当前状态），由Kubernetes系统控制平面相关的组件负责实时维护和更新；
每个对象还会有名称、标签、注解和隶属的名称空间（不包括集群级别的资源）等元数据，它们统一定义在metadata这一嵌套字段中，统称为对象元数据。
除此之外，kind和apiVersion两个字段负责指明对象的类型（资源类型）元数据，前者用于指定类型标识，而后者负责标明该类型所隶属的API群组（API Group）。
为了便于维护和扩展，Kubernetes将其API按功能等标准划分成了多个逻辑组合（Group），每个组合可称为一个API群组，支持多个版本并存。
API Server基于HTTP(S)协议暴露了一个RESTful风格的API，我们可借助于kubectl命令或其它UI通过该API查询或请求变更API对象的状态。施加于对象之上的基本操作包括增、删、改、查等，它们通过HTTP协议的GET、POST、DELETE和PUT等方法完成，而对应于kubectl命令，它们则是create、get、describe、delete、patch和edit等子命令。
创建对象时，我们必须向API Server提供描述其所需状态的对象规范、对象元数据及类型元数据，这些信息需要在请求报文的body中以JSON格式提供。但更常见的做法是，以YAML格式定义对象，提交给API Server后由其自行完成格式转换。
kubectl create 命令支行于dry-run模式时生成的结果可作为定义相应资源的基础框架模板。

Kubernetes的核心资源类型

依据资源的主要功能作为分类标准，Kubernetes的API对象大体可分为工作负载（Workload）、发现和负载均衡（Discovery & LB）、配置和存储（Config & Storage）、集群（Cluster）和元数据（Metadata）几个类别。它们基本都是围绕一个核心目的而设计：如何更好地运行和丰富Pod资源，从而为容器化应用提供更灵活和更完善的操作与管理组件。
对象及资源规范 - 图1
工作负载型资源用于确保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）存储接口扩展支持更多类型的存储系统。