API 对象

API 对象是 k8s 集群中的管理操作单元。k8s 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，用于对该功能的管理操作。例如：副本集 Replica Set 对应的 API 对象是 RS。

每个 API 对象都有 3 大类属性： 

  • 元数据 metadata ：元数据是用来标识 API 对象的，每个对象都至少有 3 个元数据：
  • namespace：用来标识该 api 对象 是在哪个 namespace 下
  • name：为该 api 对象起一个名字
  • uid： k8s 自动为对象生成的，可以唯一标识该对象的字符串
  • 除此之外，还有各种各样的标签 label 用来 env=testing、env=production 来标识开发、测试、生产的不同服务

k8s 中的 namespace 就类似于 windows 中的多个桌面，或者 linux 中的多个终端；namespace 之间的 api 对象是不可见的。只有在同一个 namespace 中的 api 对象，才能互相可见。

  • 规格 spec
  • spec 描述了用户期望 k8s 集群中分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器 Replication Controller 可以在 spec 中设置期望的 Pod 副本数为 3；

k8s 中所有的配置都是通过 API 对象的 spec 去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 k8s 重要设计理念之一：所有的操作都是声明式的而不是命令式的。

上一篇文章中写 声明式与命令式的区别是也写过：声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为 3 的操作运行多次也还是一个结果，而给副本数 +1 的操作就不是声明式的，运行多次结果就错了。 

  • 状态 status
  • status 描述了系统实际当前达到的状态（Status），例如系统当前实际的 Pod 副本数为 2；那么复制控制器就会自动启动新的 Pod，争取达到副本数为 3。

常用的 api 对象

1. Pod

k8s 有很多技术概念，对应很多 API 对象。但是 k8s 中最重要的也最基础的是微服务 Pod。

Pod 是在 k8s 集群中运行部署应用或服务的最小单元，它支持多容器运行。

pod 的设计理念是支持多个容器在一个 pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。 

pod 对多容器的支持是 k8s 最基础的设计理念。 

pod 是 k8s 集群中所有业务类型的基础，可以看作是运行在 k8s 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。 

目前 k8s 中业务可以分为

  • 长期伺服型（long-running） —— Deployment
  • 批处理型（batch）—— Job
  • 节点后台支撑型（node-daemon）—— DaemonSet
  • 有状态应用型（stateful application）—— PetSet

2. 复制控制器（Replication Controller ，RC） 

目前 k8s 最新版本已弃用，被 RS 所代替。

RC 是 k8s 集群中最早的保证 pod 高可用的 api 对象。通过监控运行中的 pod 来保证集群中运行指定数目的 pod 副本。

指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动运行新的 pod 副本；多于指定数目，RC 就会杀死多余的 pod 副本。

即使在指定数目为 1 的情况下，通过 RC 运行 pod 也比直接运行 pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 pod 在运行。 RC 是 k8s 较早期的技术概念，只适用于长期伺服的业务类型。

 3. 副本集（Replica Set, RS）

RS 是新一代 RC，提供同样的高可用能力， RS 较于 RC 的优势，在于 RS 能支持更多种类的匹配模式。 

副本集对象一般不单独使用，而是作为 Deployment 的离线状态使用。 

4.  服务（Service）

RC、RS 和 Deployment 只是保证了支撑服务 pod 的数量，但是没有解决如何访问这些服务的问题。

一个 pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 ip 启动一个新的 pod，因此不能以确定的 ip 和端口号提供服务。因此 k8s 有要稳定地提供服务需要服务发现和负载均衡能力。

服务发现: 新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

服务发现的工作：针对客户端访问的服务，可以找到对应的后端服务实例。

在 k8s 集群中，服务发现是有 servcie 实现的，客户端需要访问的服务是 service 服务，每个 service 会对应一个集群内部有效的虚拟 ip。

在 k8s 集群中，微服务的负载均衡是由 kube-proxy 实现的。 kube-proxy 是 k8s 内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个。

END

未完待续...