Google Kubernetes设计文档之服务篇

摘要: Kubernetes是Google开源的容器集群管理系统,构建于Docker之上,为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等功能。 Pod是创建、调度和管理的最小部署单位,本文详细介绍这些Pod之间的通信和调度。

概述

Kubernetes中 Pods 不是一成不变的。它们可以随着时间进行迁移,特别是当受到 ReplicationControllers支配时。虽然每个pod都有属于自己的IP地址,但是却不能保证每个Pod的IP地址随着时间的变化依然保持不变。这就导致了一个问题:如果在Kubernetes集群里,有一系列的pods(我们姑且称之为后端)为其他的pods(称为前端)提供功能,那前端该如何去找到后端?

服务

Kubernetes中的服务是一种抽象概念,它定义了一个pods逻辑集合以及访问它们的策略,有时它也被称为微服务(Micro-service)。服务的目标是提供一种桥梁,使得非Kubernetes原生应用程序,在无需为Kubernetes编写特定代码的前提下,轻松访问后端。服务会为用户提供一对IP地址和port端口,用于在访问时重定向到相应的后端。服务里Pods集合的选定是由一个标签选择器(label selector)来完成的。

举个例子,首先假设一个“镜像处理”后端,它运行着三个可用的副本。这些副本是无状态的,前端根本不关心自己具体使用的是后端的哪个副本。因此,尽管组成后端集合的实际pods可能已经发生了改变,但是前端用户完全不需要知晓这些改变。这种服务的抽象性实现了前端访问与后端服务的解耦。

定义服务

这里是一个使用服务的例子。在Kubernetes中,服务是REST对象,类似于pod。如pod一般,服务的定义,可以通过一个发给apiserver的POST请求,来完成创建一个新的实例。例如,假设你有一组pods,都暴露9376端口,并携带一个”app=MyApp”的标签。

上述定义将创建一个名为”myapp”的新服务,它使得所有带有”app=MyApp”标签的pod都监听TCP协议上的端口9376。而客户可以通过端口$MYAPP_SERVICE_PORT连接到$MYAPP_SERVICE_HOST,从而访问该服务。

服务是如何工作的?

在Kubernetes集群中的每个节点(node)上都运行着一个服务代理(service proxy)。该代理应用监听Kubernetes Master,以此来添加和删除服务对象及端点(endpoints,即满足服务标签选择器的pods),同时该代理应用还存储一个服务到端点列表的映射。它为每个服务在本地节点上打开一个端口,并转发该端口上的所有流量到后端。名义上是依据策略来执行的,但现在唯一支持的策略是轮转调度(round-robin)。

当一个pod被编入,Master为每一个存活的服务增加一组环境变量。我们支持Docker-links-compatible变量(参见makeLinkVariables)以及更简单的{SVCNAME}_SERVICE_HOST和{SVCNAME}_SERVICE_PORT变量,其中的服务名要求大写,破折号将转换为下划线。具体的服务工作图如图1 。例如,服务”redis-master”监听TCP端口637,并分配IP地址10.0.0.11,将产生以下环境变量:

这意味着要有先后次序,即一个pod希望访问的服务必须在pod本身创建之前被创建,否则环境变量不会被加载。不过支持DNS服务后,该限制将不再存在。

服务通过它的标签选择器,可以解析到0或多个端点。在服务的生命周期内,组成该服务的pods集合可以增加、缩减,或全部失效。用户只有在当他们正在使用的后端从服务中被移除时,才会遇到问题(即使如此,已经打开的连接也会因为某些协议的缘故,继续保持)。 15


图1.服务工作图

细节明细

前文的内容对于大多数只是想要使用服务的人来说应该已经足够了。然而,有很多发生在这背后的事情也值得去深入了解。

避免冲突

Kubernetes的一个主要理念是,用户不应该遭遇可能导致其操作失败的情景,尤其是用户本身并未引起错误。在此背景下,我们考虑网络端口的问题—不应该让用户选择一个可能与其他用户发生冲突的端口号。否则,将是隔离上的失败。

为了让用户能够选择他们的服务端口号,我们必须确保不会引起两个服务间的冲突。我们通过为每个服务分配自己的IP地址来做到这一点。

IP和Portal

不同于路由到一个固定的pod的IP地址,服务的IP实际上并不是由单个Master响应的。相反的,我们用iptables(Linux中的数据包处理逻辑)来定义这些需要透明重定向的“虚拟”IP地址。我们将服务IP和服务端口的元组称为Portal。当用户连接到portal上,其访问会被自动转移到一个相应的端点上。实际上,服务的环境变量是依据portal的IP和端口来设定的。此外,我们将增加DNS来支撑服务的访问。

举例来说,考虑上图所展示的应用处理过程。在创建后端服务时,Kubernetes Master分配一个Portal的IP地址,例如10.0.0.1。假设服务端口是1234,portal即为是10.0.0.1:1234。Master将存储该信息,它也被集群中所有的服务代理实例所获取。当代理监测到一个新的portal,它会打开一个新的随机端口,建立一个从Portal到新端口的iptables重定向,然后开始接受对其的连接。

当用户使用portal端口连接MYAPP_SERVICE_HOST时(不论他们将其视为静态端口或视为MYAPP_SERVICE_PORT),iptables规则生效,重定向数据包到服务代理自身的端口上。服务代理选择一个后端,并开始从客户端到后端的代理通信流量。具体原理如图2。

最终的结果是,用户可以选择他们想要的任何服务端口,而没有冲突的危险。客户可以轻松连接IP和端口,而无需了解到他们正在访问哪个pods。

16


图2.服务中IP和portal原理图

外部服务

对于用户应用程序的某些部分(如前端),用户希望在外部可访问的IP地址(公网IP)上暴露一个服务。

如果你希望你的服务暴露在一个公网IP地址上,你可以选择提供一个服务可以响应的”publicIPs”列表。这些IP地址将被绑定上服务端口,同时被映射到由服务选择的pods集合上。你随后需要负责确保到该公网IP地址的通信流量被发送到一个或多个kubernetes工作节点。与映射内部IP地址一致,每个主机上的每一条IPTables规则,将公网特定IP地址的数据包映射到内部的服务代理。

对于提供外部负载均衡设备的云服务提供商,还有一个更简单的方式来达到同样的效果。在这类供应商(如GCE)上,你可以让publicIPs为空,作为代替,你可以在服务上设置createExternalLoadBalancer标志。这会启动一个云服务提供商的特定负载均衡设备(假设它由你的云提供商支持),并用适当的值来填充这个公网IP值域。

缺点

我们预计,portals使用的iptables将在小规模上可用,而无法扩展到有着成千上万服务的大型集群。查看 portals的原始设计方案 ,可了解更多详情。

今后的工作

在将来,我们设想,代理策略可以变得比简单的轮循调度更加细致入微,比如master筛选或分片。我们还设想,一些服务将具有“真正的”负载均衡器,在这种情况下,portal将可以直接简单地传输数据包。

原文链接:Services in Kubernetes(编译/仇臣 审校/孙宏亮、张磊)

译者介绍:仇臣,浙江大学SEL实验室硕士研究生,目前在云平台团队从事科研和开发工作。浙大团队对PaaS,Docker,大数据和主流开源云计算技术有深入的研究和二次开发经验,团队现将部分技术文章贡献出来,希望能对读者有所帮助。

浙江大学SEL实验室是本网站上所有页面设计、页面内容的著作权人,对该网站所载的作品,包括但不限于网站所载的文字、数据、图形、照片、有声文件、动画文件、音视频资料等拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本实验室书面授权的情況下抄袭、转载、摘编、修改本网站內容,或链接、转帖或以其他方式复制用于商业目的或发行,或稍作修改后在其它网站上使用,前述行为均将构成对本网站版权之侵犯,本网站將依法追究其法律责任。
本网站与他人另有协议授权下载的或法律另有规定的,在下载使用时必须注明“稿件来源:浙江大学SEL实验室”。

Leave a Reply

Your email address will not be published. Required fields are marked *