摘要：负载均衡器只能与和等特定的云服务提供商一起使用，且均衡器的功能根据提供者而定。因为它是作为一个基于的控制器在内部执行，因此对功能的访问相对不受限制不同于外部负载均衡器，它们中的一些可能无法在层面访问。
很多企业在部署容器的时候都会选择Kubernetes作为其容器编排系统。这是对Kubernetes的可靠性，灵活性和特性广泛的肯定。在这篇文章中，我们将对Kubernetes如何处理一个非常常见且必要的工作——负载均衡，进行深入的解读。在许多非容器环境（即服务器之间的均衡）中，负载均衡是一个相对简单的任务，但当涉及到容器时，就需要一些其他的、特殊的处理。
要理解Kubernetes的负载均衡，首先需要了解Kubernetes是如何组建容器的。
容器通常用来执行特定的服务或者一组服务，因此需要根据他们提供的服务来看待它们，而不是仅当作服务的单个实例（即单个容器）。实际上，这就是Kubernetes所做的。
在Kubernetes中，pod是一种基本功能单元。一个pod是一组容器以及它们共享的卷(volumes)。容器在功能和服务方面通常是密切相关联的。
将具有相同功能集的pods抽象成集合，就称为服务。这些服务接受基于Kubernetes搭建的应用程序客户端访问；这些独立的pod中的服务，反过来可以管理对构成它们的容器的访问，使得客户端与容器本身隔离。
现在我们来看看一些具体细节。
Pods通常由Kubernetes创建和销毁，而不是设计成持久化实体。每个pod都有自己的IP地址（基于本地地址）、UID和端口号；新创建的pod，无论它们是当前pod还是之前的pod的副本，都会分配新的UID和IP地址。
每个pod内部是可以进行容器之间的通信的，但是不能与不同pod中的容器直接通信。
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，它通过在专门的Kubernetes pod中的控制器进行操作。控制器包括一个Ingress资源——一组管理流量的规则和一个应用这些规则的守护进程。
控制器有自己内置的负载均衡特性，具备一些相当复杂的功能。你还可以让Ingress资源包含更复杂的负载均衡规则，来满足对具体系统或供应商的负载均衡功能和需求。
除了Ingress，你还可以使用负载均衡器类型的服务来替代它。该服务使用基于云服务的外部负载均衡器。负载均衡器只能与AWS、Azure、OpenStack、CloudStack和Google Compute Engine等特定的云服务提供商一起使用，且均衡器的功能根据提供者而定。除此之外其他的负载均衡方法可以从服务提供商以及第三方获得。
总的来说，还是推荐Ingress当前Ingress是首选的负载均衡方法。因为它是作为一个基于pod的控制器在Kubernetes内部执行，因此对Kubernetes功能的访问相对不受限制（不同于外部负载均衡器，它们中的一些可能无法在pod层面访问）。Ingress资源中包含的可配置规则支持非常详细和高度细化的负载均衡，可以根据应用程序的功能要求极其运行条件进行定制。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/33028.html
摘要：守护进程，充当和不同云提供商工具存储卷负载均衡器等之间的抽象层。除此之外，在上还有一个健康检查端点，以及一些其他状态端点。它就像是节点上运行着的的网络代理和负载均衡器一样，通过在使用实现东西负载均衡。 今晚20:30，Kubernetes Master Class在线培训第四期《企业如何构建CI/CD流水线》即将开播，点击链接：http://live.vhall.com/7294658...
摘要：部署只是一种规则，控制器组件会将这一规则应用于实际负载均衡器中。原因是功能仅允许将端口用于路由，负载均衡器和则可作为全局启动。负载均衡的限制提供了功能丰富的负载均衡器支持详细介绍在此。截至目前，我们暂时无法使用工具将负载均衡器配置从转换为。 如果您的应用程序是面向大量用户、会吸引大量流量，那么一个不变的目标一定是在高效满足用户需求的同时、不让用户感知到任何类似于服务器繁忙！的情况。这一...
摘要：年正在柏林盛大举行，来自等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。例如，你还需要诸如负载均衡器和的服务来运行应用程序。负载均衡器可以进行高级定制，以满足用户的各类需求。 想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。 2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubern...
摘要：年正在柏林盛大举行，来自等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。例如，你还需要诸如负载均衡器和的服务来运行应用程序。负载均衡器可以进行高级定制，以满足用户的各类需求。 想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。 2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubern...
阅读 1715·2021-09-26 09:46
阅读 2966·2021-09-22 15:55
阅读 2590·2019-08-30 14:17
阅读 3008·2019-08-26 11:59
阅读 1786·2019-08-26 11:35
阅读 3129·2019-08-26 10:45
阅读 3133·2019-08-23 18:28
阅读 1022·2019-08-23 18:21
