作者：Jesse Meng

eBay自2014年末开始kubernetes的落地工作，并在2015年扩大研发投入。目前kubernetes已经部署在eBay的生产环境，并将作为下一代云计算平台。本文结合社区kubernetes的设计和实现，并结合openstack云基础架构，深入分析kubernetes服务部署的设计与实现。如果您在寻找服务发布的方案或者在寻找kubernetes服务相关的模块的原理或行为，阅读本文会让你有比较明确的方向。

总揽

Kubernetes架构

下图是kubernetes的架构图，当用户将应用从传统平台转移至kubernetes时，首当其冲的任务就是将应用容器话，并定义pod和replicaset（或者petsets，如果迁移的是有状态应用）来运行应用，kubernetes提供针对应用的PDMR（provision, deployment, monitoring, remediation）。通常来讲，kubernetes为pod分配的是私有ip。如果需要提供应用的跨集群访问，则需要通过Service以及Ingress来实现。

服务的发布

下图展示的是kubernetes 集群包括集群联邦中服务相关的组件以及组件之间的关系。

Federated-apiserver作为集群联邦推荐的面向用户的接口，接受用户请求，并根据联邦层面的调度器和控制器，将用户请求分裂／转发至kubernetes集群。

根据用户IaaS环境的不同，可能需要采用不同的provider来实现与外部组件的整合，目前这些定制化provider 包括：

• DNS provider：社区实现包括 gce googledns，aws dns，eBay采用自己的GTM client

• Load Balancer provider for service: 主流云平台都有自己的provider，eBay的Kubernetes部署在openstack之上，采用社区版本的openstack provider。

• Load Balancer provider for ingress：社区目前有gclb和nginx两个版本的ingress controller，eBay与自己的内部load balancer management system（LBMS）对接，采用自己订制的基于LBMS client的ingress controller。

关于kubernetes的基本概念如pod, service等，网上有很多相关文章，可以参考kubernetes官网或网上的入门文章，本文不再一一赘述。本文希望针对kubernetes服务发布，进行end to end的分析，并针对特定云环境如eBay采用的openstack的具体实践。

服务发布

第一步：定义你的服务

eBay很多应用都采用微服务架构，这使得在大多数情况下，作为服务所有者，除了实现业务逻辑以外，还需要考虑如何把服务发布到kubernetes集群或者集群外部，使这些服务能够被kubernetes应用，其他kubernetes集群的应用以及外部应用使用。

这是一个业界的通用需求，因此kubernetes提供了灵活的服务发布方式，用户可以通过ServiceType来指定如何来发布服务。

• ClusterIP: 此类型是默认的，这种类型的服务只能在集群内部访问。

• NodePort: 此类型同时会分配clusterIP，并进一步在集群所有节点的同一端口上曝露服务，用户可以通过任意的 <NodeIP>:NodePort 访问服务。

• LoadBalancer: 此类型同时会分配clusterIP，分配NodePort，并且通过cloud provider来实现LB设备的配制，并且在LB设备中配置中，将<NodeIP>:NodePort作为pool member，LB设备依据转发规则将流量转到节点的NodePort。

内部服务

ClusterIP

如果你的service只服务于cluster 内部，那么service type定义为ClusterIP就足够了。

Kube-proxy是运行在kubernetes 集群所有节点的组件，它的主要职责是实现服务的虚拟IP。

针对只面向集群内部的服务，我们建议用户使用ClusterIP作为服务类型，该类型比nodePort少占用节点端口，并比LoadBalancer类型减少对LB设备的访问，我们应该尽可能的避免不必要的LB设备的访问，因为任何外部依赖都有失败的可能性。

外部服务

NodePort

针对类型是”NodePort”的服务，kubernetes master会从与定义的端口范围内请求一个端口号（默认范围：30000-32767），每个节点会把该端口的流量转发到对应的服务，端口号会先是在服务的spec.ports[*].nodePort

如果你希望指定端口，你可以通过nodePort来定义端口号，系统会检查该端口是否可用，如果可用就则分配该指定端口。指定端口时需要考虑端口冲突，并且端口需要在预定义的范围内。

这为开发者提供了自由度，他们可以配制自己的LB设备，配制未被kubernetes完全支持的云环境，直接开放一个或者多个节点的IP供用户访问服务。

eBay的kubernetes 集群架设在openstack 环境之上，采用openstack vm作为kubernetes node，这些node在隔离的VPC，无法直接访问，因此对外不采用nodePort方式发布服务。

LoadBalancer

针对支持外部LB设备的cloud provider的情况，将type字段设置为LoadBalancer会为服务通过异步调用生成负载均衡配制，负载均衡配制会体现在服务的status.loadBalancer 字段。

实际上，当此类型的服务进行load balancer配置时，nodeip：nodeport 作为LB Pool的member，最终的traffic还是转到某node的nodeport上的。

因为eBay有openstack作为IaaS层架构，每个openstack AZ有专属的负载均衡设备，负载均衡设备与虚拟机（即kubernetes node）的连通性在openstack AZ创建的时候就已经设置好，并且openstack的LBaaS已经把针对LB设备的操作做了抽象，这让kubernetes和LB设备的通信变得非常简单。eBay直接采用社区版本的openstack provider作为cloud provider，该provider会调用openstack LBaaS api来进行LB设备的配制，无需订制即可实现与LB设备的集成。

Service Controller：服务是如何被发布到集群外部的

Kubernetes controller manager的主要作用是watch kube-apiserver的相关对象，在有新对象事件如创建，更新和删除发生时，进行相应的配制，如servicecontroller的主要作用是为service配制负载均衡，replicaset controller主要作用是管理replicaset中定义的pod，保证pod与replicas一致。如果你对kubernetes代码比较熟悉，你会发现servicecontroller是其中职责相对清晰，代码相对简单的一个控制器。

通过解读servicecontroller的源码，我们可以了解到servicecontroller 同时监控service和node两种对象的变化，针对任何新创建或者更新的服务，servicecontroller调用loadbalancer provider的接口来实现loadbalancer的配制。因为loadbalancer的member是cluster中所有的ready node，所以当有任何node的变化时，我们需要重新配制所有的Loadbalancer Pool以体现这种变化，这也就是servicecontroller要同时监控node对象的原因。

下图展示的是当servicecontroller调用openstack LB provider时所做的操作的时序图。

所以最终的配置结果是针对每个service的port，在LB设备上会创建一个loadbalancer pool，VIP可以接受外部请求，Pool Member是节点IP加nodePort。LB设备和Node（即openstack VM）处于同一个aviailablity zone和VPC，其连通性在aviailablity zone创建时即得到保证。物理上，LB设备和虚拟机所在的物理机通过路由连接，路由规则保证LB设备对特定IP段的VM可见。

这样的配制结果保证VIP接受到的所有traffic，能够根据LB设备的规则，跳转到kubernetes node的nodePort。

为什么用NodeIP：nodePort作为LB member，如果一个cluster规模较大，如几千个Node，LB pool会不会很大，为什么不用pod IP作为LB？

1. LB和VM之间的路由规则配制只包含VM IP段，在AZ部署的时候创建。pod ip在通常情况下是不同的range，与LB之间无法直接相通。采用node IP作为Pool member使得底层架构openstack的配制和kubernetes的配制分离开来，不用考虑pod的IP范围划定。

2. node的变化相对pod而言较少，这样可以减少对LB 设备的访问，LB可能会出错。

3. LB service type是基于node port type的，service 同时提供两种访问方式。

4. 集群中每个节点被轮询到的机会均等，这使得每个节点需要解析iptables的机会一致，进而使iptables解析在每台机器的资源需求一致，避免某些节点因为iptable rules解析导致压力过大的可能性。（与Tim Hockin面对面讨论过此事）

kube-proxy: 接好最后一棒，从Node到Pod

我们知道，kubernetes服务只是把应用对外提供服务的方式做了抽象，真正的应用跑在Pod的成员container里，我们通过LB设备已经把提交至VIP的请求转到kubernetes nodes对应的nodePort上，那么nodePort上的请求是如何进一步转到提供后台服务的Pod的呢？Kube-proxy is the secret sauce，我们来看看kube-proxy都做了什么。

目前kube-proxy支持两种模式，userspace和iptables，iptables模式因为不需要userspace和kernel space的切换，在数据转发上有更高的效率。所以从1.2版本开始，iptables是默认模式，只有当kernel版本不支持iptables时，userspace模式才需要被启用。

kubernetes只操作了filter和nat表。

Filter

在该表中，一个基本原则是只过滤数据包而不修改他们。filter table的优势是小而快，可以hook到input，output和forward。这意味着针对任何给定的数据包，只有可能有一个地方可以过滤它。

NAT

此表的主要作用是在PREROUTING和POSTROUNTING的钩子中，修改目标地址和原地址。与filter表稍有不同的是，该表中只有新连接的第一个包会被修改，修改的结果会自动apply到同一连接的后续包中。

下面是基于iptables chain的数据包流向图

基于iptables的kube-proxy的实现代码在pkg/proxy/iptables/proxier.go，其主要职责包括两大块，一块是侦听service更新事件，并更新service相关的iptables规则，一块是侦听endpoint更新事件，更新endpoint相关的iptables规则，将包请求转入endpoint对应的Pod，如果某个service尚没有Pod创建，那么针对此service的请求将会被drop掉。

kube-proxy对iptables的链进行了扩充，自定义了KUBE-SERVICES，KUBE-NODEPORTS，KUBE-POSTROUTING，KUBE-MARK-MASQ和KUBE-MARK-DROP五个链，并主要通过为 KUBE-SERVICES chain增加rule来配制traffic routing 规则。

我们可以通过对照源码和iptables 规则表，来分析针对下面的service信息，kubernetes做了怎么样的iptables 配制。

1. 在iptables表中，通过iptables-save可以看到在nat表中创建好的这些链。

2. 为默认的prerouting，output和postrouting chain 增加规则，跳转至kubernetes自定义的新chain。

3. 对于KUBE-MARK-MASQ链中所有规则设置了kubernetes独有MARK标记，在KUBE-POSTROUTING链中对NODE节点上匹配kubernetes独有MARK标记的数据包，进行SNAT处理。

4. Kube-proxy接着对每个服务创建“KUBE-SVC-”链，并在nat表中将KUBE-SERVICES链中每个目标地址是service的数据包导入这个“KUBE-SVC-”链，如果endpoint尚未创建，KUBE-SVC-链中没有规则，任何incomming packets在规则匹配失败后会被KUBE-MARK-DROP。

5. 调用openLocalPort侦听service nodePort，增加KUBE-NODEPORTS chain，并添加跳转规则将此端口收到的packets转到KUBE-SVC-LAS23QA33HXV7KBL链

6. Endpoint Chain，当接收到的 serviceInfo中包含endpoint信息时，为endpoint创建跳转规则。

7. 如果service类型为nodePort，（从LB转发至node的数据包均属此类）那么将KUBE-NODEPORTS链中每个目的地址是NODE节点端口的数据包导入这个“KUBE-SVC-”链；

8. 如果一个service对应的pod有多个replicas，在iptables中会有多条记录，并通过 -m statistic --mode random --probability 来控制比率。

Iptables chain支持嵌套并因为依据不同的匹配条件可支持多种分支，比较难用标准的流程图来体现调用关系，为进一步归纳iptables的跳转流程，上面的PREROUTING chain的最终跳转规则，抽象为下图，仅供参考。

针对通过cluster LB转发进来的外部请求，因为LB设备的memeber是nodeIP: node Port，所以针对这类请求，在iptables 层走的是KUBE-NODEPORTS分支。

最后

以上就是欣慰糖豆为你收集整理的细数Kubernetes Service那些事－kubernetes 服务发布以及在eBay的实践总揽服务发布kube-proxy: 接好最后一棒，从Node到PodIngress：更优雅的发布服务集群联邦：投入生产环境吧服务发现小结的全部内容，希望文章能够帮你解决细数Kubernetes Service那些事－kubernetes 服务发布以及在eBay的实践总揽服务发布kube-proxy: 接好最后一棒，从Node到PodIngress：更优雅的发布服务集群联邦：投入生产环境吧服务发现小结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。