API对象是K8S集群中的管理操作单元。

k8s集群系统每支持一项新功能，引入一项新技术，都会对应的引入新的API对象。

例如，副本集Replica Set对应的API对象就是RS。

每个API对象都有3类属性：元数据metadata、规范spec和状态status。

metadata

元数据是用来标识API对象的，每个对象至少有3个元数据：namespace、name和uid。

除此之外，还可以使用标签labels标识和匹配不同的对象。例如，用户可以使用env标识区分不同的服务部署环境。

env=dev、env=testing、env=production标识开发、测试和生产。

status

status描述了系统实际当前达到的状态，例如系统当前实际的副本数为2，则控制器将会自动启动新的Pod，争取达到副本数为3.

spec

k8s中所有的配置都是通过API对象的spec设置的，用户通过配置系统的理想状态阿来改变系统。

声明式操作在分布式系统中的好处是稳定，比如设置副本数为3，当运行多次时还是一个结果；而给副本数加1的操作，则可能因为运行多次出现错误。

Pod

k8s中最重要也是最基础的微服务是Pod。

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

Pod对多容器的支持是k8s最基础的设计理念。比如，你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步。这两个容器可能并不是同一个团队开发，但是它们需要配合才能提供微服务。

目前k8s中的业务主要分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application），分别对应的控制器是Deployment、Job、DaemonSet和PetSet。

复制控制器（Replication Controller，RC）

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

指定的数目可以是多个，或者是1个。当少于指定数目时，RC会启动运行新的Pod副本；当多于指定数目时，RC会杀死多余的Pod副本。

即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智。

RC是k8s较早期的技术概念，只适用于长期伺服的业务类型，比如提供高可用的web服务。

副本集（Replica Set，RS）

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

副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。

部署（Deployment）

部署表示用户对k8s集群的一次更新操作，是比RS应用模式更广的API对象。

可以是创建一个新的服务，更新一个新的服务，滚动升级一个服务。

滚动升级一个服务，实际上是创建一个新的RS，然后逐渐将RS中副本数增加到理想状态，将旧RS中的副本数量减小到0的复合操作。

未来对长期伺服型业务的管理，都会通过Deployment管理。

服务（Service）

RC/RS/Deployment都只是保证支撑服务的pod数量，并不解决访问服务的问题。

在k8s集群中，客户端需要访问的服务，就是Service对象。

Service是应用服务的抽象，通过labels为应用提供负载均衡和服务发现。

每个Service对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

每个Service会自动分配一个cluster IP（仅在集群内部可访问的虚拟地址）和DNS。

其他容器可以通过该地址或DNS访问服务，而不需要了解后端容器的运行。

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

因此，需要访问的服务的节点越多，提供负载均衡能力的kube-proxy越多，高可用的节点也越多。

定义nginx的service配置

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 8078
    name: http
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx