Kubernetes 服务发现与负载均衡

Kubernetes 在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了 Service 资源，并通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。随着 kubernetes 用户的激增，用户场景的不断丰富，又产生了一些新的负载均衡机制。目前，kubernetes 中的负载均衡大致可以分为以下几种机制，每种机制都有其特定的应用场景：

• Service

  直接用 Service 提供集群内部的负载均衡，并借助 cloud provider 提供的 LB 提供外部访问

• Ingress Controller

  还是用 Service 提供集群内部的负载均衡，但是通过自定义 LB 提供外部访问

• Service Load Balancer

  把 load balancer 直接跑在容器中，实现 Bare Metal 的 Service Load Balancer

• Custom Load Balancer

  自定义负载均衡，并替代 kube-proxy，一般在物理部署 Kubernetes 时使用，方便接入公司已有的外部服务

Service

Service 是对一组提供相同功能的 Pods 的抽象，并为它们提供一个统一的入口。借助 Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service 通过标签来选取服务后端，一般配合Replication Controller 或者 Deployment 来保证后端容器的正常运行。

三种类型：

• ClusterIP

  默认类型，自动分配一个仅 cluster 内部可以访问的虚拟 IP

• NodePort

  在 ClusterIP 基础上为Service在每台机器上绑定一个端口，这样就可以通过 <NodeIP>:NodePort 来访问该服务

• LoadBalancer

  在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到 <NodeIP>:NodePort

Ingress Controller

Service 虽然解决了服务发现和负载均衡的问题，但在使用上还是有一些限制，比如：

• 对外访问的时候，NodePort 类型需要在外部搭建额外的负载均衡，而 LoadBalancer 要求 kubernetes 必须跑在支持的 cloud provider 上面。

Ingress 就是为了解决这些限制而引入的新资源，主要用来将服务暴露到集群外面，并且可以自定义服务的访问策略。

Service Load Balancer

在 Ingress 出现以前，Service Load Balancer 是推荐的解决 Service 局限性的方式。Service Load Balancer 将 haproxy 跑在容器中，并监控 service 和 endpoint 的变化，通过容器 IP 对外提供4层和7层负载均衡服务。

Custom Load Balancer

虽然 Kubernetes 提供了丰富的负载均衡机制，但在实际使用的时候，还是会碰到一些复杂的场景是它不能支持的，比如：

• 接入已有的负载均衡设备
• 多租户网络情况下，容器网络和主机网络是隔离的，这样 kube-proxy 就不能正常工作

这个时候就可以自定义组件，并代替 kube-proxy 来做负载均衡。基本的思路是监控 kubernetes 中 service 和 endpoints 的变化，并根据这些变化来配置负载均衡器。比如 weave flux、nginx plus、kube2haproxy 等。