作者：Jesse Meng

eBay自2014年末开始kubernetes的落地工作，并在2015年扩大研发投入。目前kubernetes已经部署在eBay的生产环境，并将作为下一代云计算平台。本文结合社区kubernetes的设计和实现，并结合openstack云基础架构，深入分析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，并进一步在集群所有节点的同一端口上曝露服务，用户可以通过任意的 :NodePort 访问服务。

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

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

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

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

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

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

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

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

针对支持外部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设备的集成。

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