Kubernetes 在早期设计网络的时候就已经考虑了容器的服务发现和负载均衡。Kubernetes 为 pods 的逻辑集合抽象出了 Service资源，配合 Iptables 和 Cloud Provider 来为用户提供访问的入口，但是 Kubernetes 日益增长的用户规模和越来越复杂化的业务场景对负载均衡逐渐提出了新的挑战。

才云科技在通过不断地实践探索及从社区获取的经验积累后，自主研发了 Kubernetes 的负载均衡器，来支持 Bare Metal 和 Public Cloud 环境。下面就让我们一起来看看才云的这次研究有什么新的发现与启迪。

大纲

介绍 Service
介绍 Ingress
介绍 Caicloud Loadbalancer

Kubernetes 如何对外暴露服务

在云环境中，如 AWS、GCE, 可以使用Type=LoadBalancer 的 Service 使用 Type=NodePort 的 Service
将 Pod 的 Port 映射到 Host 的 Port
使用社区的 Service LoadBalancer 项目
使用 Ingress

何为 Service

在 K8S 中，Service 是 Pods 的逻辑集合，它对外提供了访问这群 pod 的一种方式。

目前 K8S 的 Sevice 都是通过 iptables来实现的。kube-proxy 将 service 的规则刷到 node 的 iptables 中，Client 通过 serviceIP+port 访问 service 时，经过 node 的 iptables 规则转发到真正的 endpoint pods。如下图:

社区的 Service LoadBalancer

这里简单提一下这个项目（https://github.com/kubernetes/contrib/tree/master/service-loadbalancer）。它旨在为 Bare Metal 环境提供类似于 Cloud Load Balancer 的功能, 而需要使用 Node Port 来在每个 Node 上都暴露一个端口来进行转发.

这个 Controller 会在每个 Role=Loadbalancer Label 的 Node 上自动创建一个 Service-Loadbalancer Pod, 每个Service-Loadbalancer 包含以下功能:

启动一个 Controller: Watch K8s Services and Endpoints
启动一个 Load Balancer Manifest: 它会启动一个Load Balancer，这个 LB 是可插拔的, 很容易从HAproxy 的实现切换到类似于 F5 或者 Pound 的负载均衡器上
一个配置模板, 因为不同的 Load Balancer Manifest 有不同的配置格式

Ingress

Ingress Ingress 介绍

一般来说，Service 和 Pod 的 IP 地址只能在集群的网络中被路由，所有到达 Edge Router 的流量都会被丢弃或者转发到其他地方, 看起来像下面这样:

Ingress 是一个规则的集合，它允许集群外的流量通过一定的规则到达集群内的 Service 。看起来像这样:

Ingress Controller

Ingress 只是一些规则，要达到上面的需求，还需要在集群内部部署一个 Ingress Controller 而 Ingress Controller 本质上是一个 Nginx/Haproxy 。

要使用 Ingress 需要经过下面几步:

1.在集群中部署 Ingress Controller，假设 Ingress Controller 的 IP 是 178.91.123.132
2.添加 Ingress 规则，如将 foo.bar.com 这个域名下的流量导到 serviceA:8080 ，将 bar.foo.com 的流量导到 serviceB:8080
3.在请求方需要有域名解析服务将 foo.bar.com 和 bar.foo.com 解析到178.91.123.132

Ingress 存在的问题

Ingress 和 Ingress Controller 是 K8S 提供的非常棒的功能，但是使用下来有以下的问题:

1.如何提供 Ingress Controller 本身的高可用。
2.多个 Ingress Controller 如何同时对外提供服务。
3.IngressController自动化运维,扩容缩容监控等。

Caicloud LoadBalancer

LoadBalancer Controller

针对 Ingress 的问题，才云科技设计了自己的 LoadBalancer。
在整个架构中，我们通过一个 LoadBalancer Admin 对外提供 RESTful api 来方便操作 LoadBalancer Third Party Resource (简称 LoadBalancer TPR)。

由 LoadBalancer Controller list/watch LoadBalancer TPR, 然后根据 TPR 的 specification 去创建 Provider 和 Proxy(Ingress Controller)并对 Node 进行相应的操作。

在这里引入了一个新的组件，LoadBalancer Provider，它是用来保证 Ingress Controller 入又的高可用。

如在 Bare Metal 环境下，我们会在每个运行 Ingress Controller 的节点上，使用 LVS/DR Provider 来将流量分发到同一组的 Ingress Controller，同时这个 Provider 还需要保证 VIP 的高可用而在云环境中，则可以使用云产商各自的 L4 负载来将流量分发到同一组 Ingress Controller，用 Provider 做一次适配就 OK 了。

LoadBalancer Controller 中包含了三种 Kubernetes Controller，分别为 Provider，Proxy，Node Controller，分别管理各自关心的资源，互不影响。

架构图如下:

Bare Metal LoadBalancer

在 Bare Metal 的环境下，我们选择了 LVS/DR 模式做 Provider，所有的流量通过 VIP, 经过 LVS 到达 Ingress Controller，由 Ingress Controller 来控制这些流量代理到对应的 Endpoint。

在这个模式下有下面这些要点:

Ingress Controller 运行在 Host 网络模式下
DR 模式需要修改机器的 arp_ignore=1, arp_announce=2
在 Node 上的回路设备（lo）上添加VIP，将 Ingress Controller 作为 LVS 的 Real Server，DR 模式下需要 Real Server 机器持有 VIP
在这种方案下，LVS 的 Director（Ipvs Provider）话则会导致流量死循环的问题。所以我们采用 Fwmark 来区分流量，对于从 Peer 节点转发来的流量不应该再经过 Ipvs 规则。当然这个是我们使用了 Keepalived 引起的问题。

公有云

在公有云下就比较简单了，由 Provider 去适配公有云的 L4 层负载，由公有云的负载来负责将流量导流到 Ingress Controller。

总结

目前才云的 LoadBalancer 还处于 alpha 阶段，但是已经在我们内部的集群里面替换了原来的 Keepalived+HAproxy, 来为集群的多 Master 提供 HA 的支持，替换的过程中遇到了很多坑，但总算让它正确运行起来。

后续 LoadBalancer 还需要添加更多的 Provider 来适配公有云，添加监控信息，增加弹性伸缩等功能。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/1XFgQVPojpzfPGEuja3kNA

创作场景

才云自研 Kubernetes 负载均衡器