实用干货：Kubernetes中的负载均衡全解

不少企业在部署容器的时候都会选择Kubernetes做为其容器编排系统。这是对Kubernetes的可靠性，灵活性和特性普遍的确定。在这篇文章中，咱们将对Kubernetes如何处理一个很是常见且必要的工做——负载均衡，进行深刻的解读。在许多非容器环境（即服务器之间的均衡）中，负载均衡是一个相对简单的任务，但当涉及到容器时，就须要一些其余的、特殊的处理。

管理容器

要理解Kubernetes的负载均衡，首先须要了解Kubernetes是如何组建容器的。 容器一般用来执行特定的服务或者一组服务，所以须要根据他们提供的服务来看待它们，而不是仅看成服务的单个实例（即单个容器）。实际上，这就是Kubernetes所作的。

把它们放置在Pods中

在Kubernetes中，pod是一种基本功能单元。一个pod是一组容器以及它们共享的卷(volumes)。容器在功能和服务方面一般是密切相关联的。 将具备相同功能集的pods抽象成集合，就称为服务。这些服务接受基于Kubernetes搭建的应用程序客户端访问；这些独立的pod中的服务，反过来能够管理对构成它们的容器的访问，使得客户端与容器自己隔离。

管理Pods

如今咱们来看看一些具体细节。 Pods一般由Kubernetes建立和销毁，而不是设计成持久化实体。每一个pod都有本身的IP地址（基于本地地址）、UID和端口号；新建立的pod，不管它们是当前pod仍是以前的pod的副本，都会分配新的UID和IP地址。 每一个pod内部是能够进行容器之间的通讯的，可是不能与不一样pod中的容器直接通讯。

让Kubernetes处理事务

Kubernetes使用本身的内置工具来管理和单个pod以前的通讯。这说明通常状况下，依靠Kubernetes内部监控pods就足够了，没必要担忧pods的建立、删除或者复制。不过，有时也须要Kubernetes管理的应用程序中至少某些内部元素对底层网络可见。发生这种状况时，方案必须考虑到缺乏永久IP地址该怎么处理。

Pods和节点(Nodes)

在许多方面上，Kubernetes均可看做是一个pod管理系统，就像容器管理系统同样。大部分基础设施都是在pod层面处理容器，而不是在容器层面。 从Kubernetes内部管理来看，pod上面的组织级别至关于节点，是一个虚拟机，包含了管理和通讯的资源而且是部署pod的环境。节点自己也能够在内部建立、销毁和替换/从新部署。不管是节点层面仍是pod层面，它们的建立、销毁、从新部署、使用和扩展等功能都由被称为控制器(Controller)的内部进程处理。

充当调度者的“服务”

服务（service）是Kubernetes在管理层面处理容器和pods的方式。不过正如咱们上面提到的，它还将功能相关或相同的pods抽象成服务，而且在外部客户端和应用程序中其余元素与pod交互时，Kubernetes处在服务层面。 服务有相对稳定的IP地址（由Kubernetes内部使用）。当一个程序须要使用由服务中的功能时，它会向服务、而非向单个pod提出请求。接着该服务会做为调度员，分配一个pod来处理请求。

调度和负载分配

看到这里你可能会想，负载均衡会不会是在调度层面进行的？事实确实如此。Kubernetes的服务有点像一个巨大的设备池，根据须要将功能相同的机器送入指定区域。做为调度过程的一部分，它须要充分考虑管理可用性，避免遇到资源瓶颈。

让kube-proxy来执行负载均衡

Kubernetes中最基本的负载均衡类型其实是负载分配(load distribution)，这在调度层面是容易实现的。Kubernetes使用了两种负载分配的方法，都经过kube-proxy这一功能执行，该功能负责管理服务所使用的虚拟IPs。 Kube-proxy的默认模式是iptables，它支持至关复杂的基于规则的IP管理。iptables模式下，负载分配的本地方法是随机选择——由一个传入的请求去随机选择一个服务中的pod。早先版本（以及原来的默认模式）的kube-proxy模式是userspace，它使用循环的负载分配，在IP列表上来分配下一个可使用的pod，而后更换（或置换）该列表。

真正的负载均衡：Ingress

咱们以前提到了两种负载均衡的方法，然而，这些并非真正的负载均衡。为了实现真正的负载均衡，当前最流行、最灵活、应用于不少领域的方法是Ingress，它经过在专门的Kubernetes pod中的控制器进行操做。控制器包括一个Ingress资源——一组管理流量的规则和一个应用这些规则的守护进程。 控制器有本身内置的负载均衡特性，具有一些至关复杂的功能。你还可让Ingress资源包含更复杂的负载均衡规则，来知足对具体系统或供应商的负载均衡功能和需求。

使用负载均衡器做为替代品

除了Ingress，你还可使用负载均衡器类型的服务来替代它。该服务使用基于云服务的外部负载均衡器。负载均衡器只能与AWS、Azure、OpenStack、CloudStack和Google Compute Engine等特定的云服务提供商一块儿使用，且均衡器的功能根据提供者而定。除此以外其余的负载均衡方法能够从服务提供商以及第三方得到。

总的来讲，仍是推荐Ingress

当前Ingress是首选的负载均衡方法。由于它是做为一个基于pod的控制器在Kubernetes内部执行，所以对Kubernetes功能的访问相对不受限制（不一样于外部负载均衡器，它们中的一些可能没法在pod层面访问）。Ingress资源中包含的可配置规则支持很是详细和高度细化的负载均衡，能够根据应用程序的功能要求极其运行条件进行定制。