实用干货: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资源中包含的可配置规则支持非常详细和高度细化的负载均衡,可以根据应用程序的功能要求极其运行条件进行定制。

原文地址:http://blog.51cto.com/12462495/2073021

时间: 2024-10-04 19:45:35

实用干货:Kubernetes中的负载均衡全解的相关文章

关于ASP.NET中的负载均衡

ASP.NET站点中做负载均衡: 基于HTTP协议我们可能发现我们要解决两点问题: 第一做到负载均衡,我们需要一个负载均衡器. 可以通过DNS轮询来做,在DNS服务器上配置为每次对我们做负载均衡的同一主机名的DNS查询得到不同的IP地址.这样的好处是配置简单投入较小,缺点是浏览器访问各个服务器的机会是均等的,不能根据服务器的负载程度自动把请求路由到负载较小的服务器. 可以通过专用的负载均衡设备,通过监测后台数台服务器的负载情况,自动把HTTP请求转发到负载较轻的服务器.另外必须监测后台服务器的I

大型网站架构系列:负载均衡详解

面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题.从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统.分布式和业务拆分解决了,从集中到分布的问题,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们可

大型网站架构系列:负载均衡详解(1)

面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题. 从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统.分布式和业务拆分解决了,从集中到分布的问题,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们

大型网站架构系列:负载均衡详解(4)

本文是负载均衡详解的第四篇,主要介绍了LVS的三种请求转发模式和八种负载均衡算法,以及Haproxy的特点和负载均衡算法.具体参考文章,详见最后的链接. 三.LVS负载均衡 LVS是一个开源的软件,由毕业于国防科技大学的章文嵩博士于1998年5月创立,用来实现Linux平台下的简单负载均衡.LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器. 基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/UDP请求均衡地转移到不同的 服务器,从而将一组

大型网站架构系列:负载均衡详解(3)

本次分享大纲 软件负载均衡概述 Ngnix负载均衡 Lvs负载均衡 Haproxy负载均衡 本次分享总结 一.软件负载均衡概述 硬件负载均衡性能优越,功能全面,但是价格昂贵,一般适合初期或者土豪级公司长期使用.因此软件负载均衡在互联网领域大量使用.常用的软件负载均衡软件有Nginx,Lvs,HaProxy等.本文参考大量文档,部分为直接拷贝,参考出处见负载均衡详解(4). 二.Ngnix负载均衡 Ngnix是一款轻量级的Web服务器/反向代理服务器,工作在七层Http协议的负载均衡系统.具有高性

(转)大型网站架构系列:负载均衡详解(1)

面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题. 从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统.分布式和业务拆分解决了,从集中到分布的问题,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们

Nginx代理功能与负载均衡详解

Nginx的代理功能与负载均衡功能是最常被用到的,关于nginx的基本语法常识与配置已在上篇文章中有说明,这篇就开门见山,先描述一些关于代理功能的配置,再说明负载均衡详细. Nginx代理服务的配置说明 1.上一篇中我们在http模块中有下面的配置,当代理遇到状态码为404时,我们把404页面导向百度. error_page 404 https://www.baidu.com; #错误页 然而这个配置,细心的朋友可以发现他并没有起作用. 如果我们想让他起作用,我们必须配合着下面的配置一起使用 p

负载均衡详解

@(Linux服务)[负载均衡详解] 负载均衡详解 ---- [TOC] 负载均衡简介 ?负载均衡 建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽.增加吞吐量.加强网络数据处理能力.提高网络的灵活性和可用性.我们比较常用的例如:HAPoryx.LVS.nginx这三种. 负载均衡分类 ?我们最常见的负载均衡通常是四层和七层负载均衡.下面介绍四种: 二层负载均衡 ?负载均衡服务器对外依然提供一个VIP(虚拟IP),在集群中不同的机器采用相同IP地址,但是机器的MA

Nginx 反向代理与负载均衡详解

序言 Nginx的代理功能与负载均衡功能是最常被用到的,关于nginx的基本语法常识与配置已在Nginx 配置详解中有说明,这篇就开门见山,先描述一些关于代理功能的配置,再说明负载均衡详细. Nginx 代理服务的配置说明 1.设置 404 页面导向地址 error_page 404 https://www.runnob.com; #错误页 proxy_intercept_errors on; #如果被代理服务器返回的状态码为400或者大于400,设置的error_page配置起作用.默认为of