V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
RancherLabs
V2EX  ›  云计算

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

  •  
  •   RancherLabs · 2018-02-26 10:34:09 +08:00 · 3096 次点击
    这是一个创建于 2222 天前的主题,其中的信息可能已经有所发展或是发生改变。

    很多企业在部署容器的时候都会选择 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 资源中包含的可配置规则支持非常详细和高度细化的负载均衡,可以根据应用程序的功能要求极其运行条件进行定制。

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1953 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 00:01 · PVG 08:01 · LAX 17:01 · JFK 20:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.