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

results matching ""

    No results matching ""