使用Linode引擎实现Kubernetes自动缩放的优秀实践

译文 精选
运维 自动化 云原生
本文通过实际例子讨论了水平自动化缩放、垂直自动化缩放、以及集群自动化缩放的相关概念、用例和注意事项。以LKE为代表的托管式Kubernetes服务,能够通过内置的自动化调整工具,为您减少各种手动管理的工作量。

众所周知,云服务架构可以随着应用的需求实时扩展,而无需人工进行配置的更改或逐行增加代码。其中,自动化缩放(Autoscaling)就保证了在无需人工干预的情况下,自动增加或减少应用负载的能力。显然,如果调整得当,自动化缩放可以降低我们维护应用的成本、以及项目实施的难度。

对于Kubernetes而言,其自动化缩放的过程通常是:首先确定一组何时需要为Kubernetes扩展应用容量的指标。接着,设定一组被用来判定应用是该扩展、还是缩容的规则。最后,使用各种kubernetes API,对应用程序的可用资源进行扩缩容,以满足程序执行和服务所需。

自动化缩放虽然是一个看似复杂的过程,但是它能够比其他技术更好地服务于特殊类别的应用。例如,如果某个应用程序在容量需求上不会经常发生更改的话,那么我们最好为其调配至最大的流量资源。类似地,如果您能够可靠地预测到某个应用的负载,则可以通过手动、而非自动的方式来调整容量。

除了应对应用程序的负载变化,自动调整功能还能够有效地进行成本和容量管理。例如,集群的自动调整功能允许您通过调整集群中的节点数量,来节省在公共云上的租金。此外,如果您有一个静态的架构,那么自动化调整将使您能够动态地管理分配给流量负载的容量,以便您能够更好地利用自己的基础设施。

在实际应用中,自动化缩放主要分为如下两类:

1. 负载的自动调整:动态地管理单个负载的容量,并进行自动分配。

2. 群集的自动缩放:动态地管理群集的容量。

让我们首先了解一下在Kubernetes中扩展负载的细节。目前,在Kubernetes上可被用于自动调整工作负载的标准化工具包括:水平Pod自动化缩放(Horizontal Pod Autoscaler,HPA)、垂直Pod自动化缩放(Vertical Pod Autoscaler,VPA)、以及集群比例自动化缩放(Cluster Proportional Autoscaler,CPA)。下面,让我们通过一个群集和简单的测试应用程序,来模拟Kubernetes的自动化缩放功能。

创建Linode-Kubernetes引擎集群

由​​Linode​​提供的名为Linode kubernetes引擎(LKE)的托管式Kubernetes产品,非常容易入门。您可以注册一个免费的Linode帐户,然后按照​​​LKE入门指南​​创建一个集群。

如下图所示,我创建了一个由两个节点(称为Linodes)组成的集群,每个节点都有2个CPU内核和4 GB内存:

LKE集群

为了使用该集群,您需要从集群的概述部分下载kubeconfig文件。虽然有好几种​​策略​​可供我们合并kubeconfig文件,但是我更喜欢通过更新带有指向kubeconfig文件路径的KUBECONDIG环境变量的方式来实现。

下面,让我们来构建一个简单的应用程序,以用来测试各种自动化缩放。

Pressure API

Pressure API应用运行在两个端点上。它属于.NET REST API,允许您通过如下两种途径,将CPU和内存的压力施加到pod上:

1. /memory/{numMegaBytes}/duration/{durationSec}:此端点将向内存添加指定数量的兆字节,并在指定的持续时间内保持压力。

2. /cpu/{threads}/duration/{durationSec}:此端点将在CPU上运行指定数量的线程,并在指定的持续时间内保持压力。

以下是该应用的完整源代码:

C#
using System.Xml;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}

app.MapPost("/memory/{numMegaBytes}/duration/{durationSec}", (long numMegaBytes, int durationSec) =>
{
// ReSharper disable once CollectionNeverQueried.Local
List<XmlNode> memList = new();

try
{
while (GC.GetTotalMemory(false) <= numMegaBytes * 1000 * 1000)
{
XmlDocument doc = new();
for (var i = 0; i < 1000000; i++)
{
memList.Add(doc.CreateNode(XmlNodeType.Element, "node", string.Empty));
}
}
}
// Don't fail if memory is not available
catch (OutOfMemoryException ex)
{
Console.WriteLine(ex);
}

Thread.Sleep(TimeSpan.FromSeconds(durationSec));
memList.Clear();
GC.Collect();
GC.WaitForPendingFinalizers();
return Results.Ok();
})
.WithName("LoadMemory");

app.MapPost("/cpu/{threads}/duration/{durationSec}", (int threads, int durationSec) =>
{
CancellationTokenSource cts = new();
for (var counter = 0; counter < threads; counter++)
{
ThreadPool.QueueUserWorkItem(tokenIn =>
{
#pragma warning disable CS8605 // Unboxing a possibly null value.
var token = (CancellationToken)tokenIn;
#pragma warning restore CS8605 // Unboxing a possibly null value.
while (!token.IsCancellationRequested)
{
}
}, cts.Token);
}

Thread.Sleep(TimeSpan.FromSeconds(durationSec));
cts.Cancel();
Thread.Sleep(TimeSpan.FromSeconds(2));
cts.Dispose();
return Results.Ok();
})
.WithName("LoadCPU");


app.Run();

您不必担心应用的细节。我已经在GitHub存储库(https://github.com/rahulrai-in/dotnet-pressure-api)上发布了可供下载的容器镜像、及其相关组件。您可以在K8s的各项规范中使用该镜像。同时,下文中使用到的Kubernetes各个规范,都被存放在代码存储库的spec文件夹中。在此,我们使用如下规范将应用部署到LKE集群中:

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: pressure-api-deployment
spec:
selector:
matchLabels:
app: pressure-api
replicas: 1
template:
metadata:
labels:
app: pressure-api
spec:
containers:
- name: pressure-api
image: ghcr.io/rahulrai-in/dotnet-pressure-api:latest
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
memory: 500Mi
---
apiVersion: v1
kind: Service
metadata:
name: pressure-api-service
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
    app: pressure-api

该应用目前虽然可以接受请求,但是只能在集群中被访问到。我稍后将使用一个临时的pod向API发送各种请求。不过,现在让我们先来讨论最常见的自动化缩放组件:水平Pod自动化缩放(HPA)。

水平Pod自动化缩放(HPA)

​水平Pod自动化缩放​​允许您根据当前的负载,动态调整集群中的pod数量。Kubernetes通过HorizontalPodAutoscaler资源和绑定到kube-controller-manager的控制器,来原生地支持其水平自动化缩放。而HPA主要依赖​​Kubernetes Metrics Server​​来提供PodMetrics。Metrics Server会从集群中的每个节点上收集CPU和内存的使用情况,并通过​​​Metrics API​​提供出去。下图展示了该过程中涉及的各个组件:

水平Pod自动化缩放

Metrics Server会去轮询kubelet端点上的​​Summary API​​,以收集在pods中运行的容器资源的使用指标。在默认情况下,HPA控制器将代理Metrics Server,每15秒轮询一次Kubernetes API服务器的Metrics API端点。此外,HPA控制器也会持续监视HorizontalPodAutoscaler资源,以维持自动化缩放的配置。接着,HPA控制器会根据各种配置(或其他已配置的资源)去更新部署中的pod数量,以匹配相应的需求。最后,部署控制器通过更新复制集(ReplicaSet)来响应更改,完成pod数量的调整。

作为HPA和VPA的先决条件,您可以根据官方指南中提到的​​相关说明​​,在自己的集群上安装Metrics Server。如果您在安装时遇到TLS问题,那么请在​​​代码库​​的spec目录下,按照如下方式使用metrics-server.yaml规范:

Shell
kubectl apply -f spec/metrics-server.yaml

现在,让我们根据如下yaml内容,通过配置HorizontalPodAutoscaler对象,将部署扩展到五个副本,并根据内存资源的平均利用率,将其缩小至一个副本:

YAML
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: pressure-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: pressure-api-deployment
minReplicas: 1
maxReplicas: 5
metrics:
- type: Resource
resource:
name: memory
target:
type: Utilization
          averageUtilization: 40

如果内存的平均利用率保持在40%以上,那么HPA将增加副本的数量,反之亦然。您也可以将该规则运用到CPU利用率上。在这种情况下,HPA控制器将根据规则的组合,来确定并使用副本的最大数量。

在开始之前,让我们通过如下命令,在两个不同的终端窗口中观察HPA及其部署,以实时查看到副本数量的变化。

Shell
kubectl get hpa pressure-api-hpa --watch

kubectl get deployment pressure-api-deployment --watch

为了触发HPA,我们将启动一个临时的pod,并让它向/memory/{numBytes}/duration/{durationSec}端点发送请求。下面的命令将触发HPA通过扩展pods来减少内存的压力。

Shell
kubectl run -i --tty mem-load-gen --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/memory/1000/duration/180; done"

您可以在终端窗口中观察到HPA更新部署的副本数量。下图展示了活动的利用率相对于目标的增长情况:

运行中的HPA

同时,您也可以从下图中看到复制副本的变化:

由HPA触发的副本数量的增加

在使用HPA时,请记住如下注意事项:

  • 应用程序应当能够在不同的实例之间共享负载。
  • 集群应该有足够的容量,来容纳扩展的pod数量。这可以通过提前配置所需的容量,并使用警报来提示平台操作员向集群添加更多的容量来实现。当然,您也可以使用群集自动化缩放来实现,我们将在下文中讨论。
  • CPU和内存可能并非应用程序做出缩放决策的正确指标。在这种情况下,您可以将HPA(或VPA)与自定义指标结合使用,并使用自定义的指标适配器而非Kubernetes Metrics Server,来实现自动化的缩放。其中,常用的自定义指标适配器有​​Prometheus适配器​​​和​​Kubernetes事件驱动自动缩放器​​(Kubernetes Event-Driven Autoscaler,KEDA)。

在继续讨论VPA之前,请删除掉刚才创建的HPA,并按照如下命令重置部署的副本数量:

Shell
kubectl delete hpa/pressure-api-hpa

kubectl scale --replicas=2 deployment/pressure-api-deployment

垂直Pod自动化缩放(VPA)

​垂直Pod自动化缩放​​允许您动态调整单个实例的资源容量。在pods的上下文环境中,这涉及到更改pod可以使用到的CPU和内存资源数量。与HPA不同,除了Metrics Server外,VPA还需要安装三个控制器组件。下图展示了Kubernetes组件、及其与VPA的交互:

垂直Pod自动化缩放

  • Recommender:根据pod资源的使用情况,确定最佳的CPU和内存值。
  • Admission plug-in:在根据Recommender的建议创建pod时,更改pod的资源请求和限制。
  • Updater:逐出pod,以便Admission plug-in拦截其重建请求。

请跟随VPA指南中的​​安装说明​​准备您的集群。安装完成后,您可以通过运行如下命令,验证VPA组件的运行状况:

Shell
kubectl get pods -l "app in (vpa-recommender,vpa-admission-controller,vpa-updater)" -n kube-system

VPA Pod的健康状况

下面,让我们了解一下VPA缩放操作的工作原理。首先,​​资源请求​​会通过pod规范中的声明,以确保Kubernetes保留了pod所需的最少资源。接着,当VPA检测到pod接近其资源消耗的限制时,它将自动计算出一组新的、更合适的数值。如果您定义了资源请求、以及在pod规范中的资源限制,那么VPA将在更新数值的时候,保持请求限制(request:limit)的比率。而且,每当VPA更新资源请求时,它都会改变资源的限制。

如下YAML所示,我们将定义一个VPA的策略,来自动化调整CPU和内存的请求,而无需向处理负载添加更多的pod:

YAML
apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
name: pressure-api-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: pressure-api-deployment
updatePolicy:
updateMode: Recreate
resourcePolicy:
containerPolicies:
- containerName: "*"
minAllowed:
cpu: 0m
memory: 0Mi
maxAllowed:
cpu: 1
memory: 2000Mi
controlledResources: ["cpu", "memory"]
        controlledValues: RequestsAndLimits

该规范将适用于部署中的所有容器,其最小和最大阈值将确保VPA在合理的范围内运行。其中,controlledResources字段指定了由VPA自动缩放的资源。

目前,VPA支持四种更新模式。其中,Recreate和Auto模式是激活自动化缩放的唯一方式。不过,它们的实际用例比较有限。Initial模式将在创建资源值时,对其实施许可控制,当然它也会阻止Updater逐出任何pod。而Off模式最为实用。在该模式下,VPA虽然不会缩放资源,但是会推荐资源值。因此,在应用程序进入生产环境之前,您可以使用该模式在应用的全面负载测试、以及分析期间,计算出最佳的资源值,以便将其应用于生产部署的规范中,以节省工程量。

对此,我们可以应用前面的规范,并通过执行如下命令,来监控自动化的缩放:

Shell
kubectl get vpa/pressure-api-vpa --watch

然后,我们使用如下命令给CPU施加压力,以激活VPA:

Shell
kubectl run -i --tty mem-load-gen --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/cpu/10/duration/180; done"

一段时间后,您可以执行如下命令,以查看VPA所生成的建议。

Shell
kubectl describe vpa/pressure-api-vpa

下图是上述命令的输出结果,其中显示了源于VPA的各项建议:

VPA的建议

可见,它建议使用Target值作为CPU和内存请求的基线。如果VPA规范中定义的上限和下限并非最优的话,它会使用Uncapped Target作为基线,以表示没有minAllowed和maxAllowed限制的目标估值。

此外,由于我们启用了垂直自动化缩放,因此新创建的pod将会由admission控制器执行VPA的各种注释。您可以通过如下命令查看pod的注释:

Shell
kubectl get pod  <pod name> -o jsonpath='{.metadata.annotations}'

下面便是上述命令的输出(来自K9s控制台,https://github.com/derailed/k9s):

Pod的注释

在讨论下一种自动化缩放之前,让我们使用如下命令删除并重置当前部署。

Shell
kubectl delete vpa/pressure-api-vpa
kubectl scale --replicas=1 deployment/pressure-api-deployment

集群比例自动化缩放(CPA)

​集群比例自动化缩放​​(CPA)属于一种水平pod自动化缩放。它会根据群集中的节点数量来缩放副本。与其他自动化缩放不同的是,它既不依赖于Metrics API,也不需要Metrics Server。此外,CPA并不使用Kubernetes资源来实现缩放,而是使用各种标志,来标识目标负载和用于扩展配置的ConfigMap。下图展示了CPA的各个组件:

集群比例自动化缩放

CPA的用例比较有限。例如,CPA通常被用于诸如集群DNS的横向扩展平台服务。它们往往需要随着部署在集群上的负载而自动进行扩展。CPA的另一个用例是,由于不需要使用Metrics Server或Prometheus适配器,因此可以通过简单的机制,来扩展出各种负载。

您可以使用CPA的Helm图表,在集群上安装CPA,并使用如下命令添加cluster-proportional-autoscaler的Helm存储库:

Shell
helm repo add cluster-proportional-autoscaler https://kubernetes-sigs.github.io/cluster-proportional-autoscaler
helm repo update

您可以在​​图表值文件​​中定义自动化缩放的规则,以便能够根据指定的配置,创建配置映射。据此,您可以进行后续的ConfigMap编辑,以更改自动化缩放的行为,而不必重新安装图表。

请创建一个名为cpa-values.yaml的文件,并添加如下内容:

YAML
config:
ladder:
nodesToReplicas:
- [1, 3]
- [2, 5]
options:
namespace: default
  target: "deployment/pressure-api-deployment"

我们可以指定CPA使用如下缩放方法中的一种:

  • Linear:按照与群集中节点或核心数量成正比的方式,缩放应用。
  • Ladder:使用步进函数(step function)确定nodes:replicas和/或cores:replicas的比率。

在上面的示例中,如果集群中有一个节点,那么CPA会将部署扩展为三个副本。您可以通过如下命令安装图表,并为其提供配置。

Shell
helm upgrade --install cluster-proportional-autoscaler \
    cluster-proportional-autoscaler/cluster-proportional-autoscaler --values cpa-values.yaml

一旦完成CPA的安装,您将会发现,由于我们的集群上有两个节点,因此它可以将pressure-api-deployment扩展到5个副本。

同样,在讨论集群自动化缩放之前,让我们使用如下命令来删除掉现有部署:

Shell
helm delete cluster-proportional-autoscaler

我们已经讨论了如何使用核心Kubernetes、以及由社区构建的附加组件,来自动调整负载。下面,我们将讨论如何扩展Kubernetes集群本身。

群集自动化缩放(CA)

手动增减Kubernetes集群的容量,会显著增加集群的管理成本和工程量,因此我们需要让CA与HPA配合使用。一旦HPA开始接近计算资源的极限,CA就可以计算出需要满足的节点数量,并向集群中添加新的节点。此外,当CA发现某些节点在较长的时间内未被充分利用时,它可以将pods重新调度到其他的节点处,进而将未充分利用的节点从集群中移除。

集群自动化缩放在具体实现上会因云服务提供商的不同而不尽相同。例如,Azure和AWS之类的云服务提供商,就能够支持​​Cluster API​​,并运用Kubernetes的operator去管理群集架构。群集自动化缩放也可以通过卸载的方式,为群集API的控制器调整节点的数量。在实施群集自动化调整之前,请认真考虑如下方面:

1. 确保能够掌握应用在负载下的行为,并消除那些阻碍应用进行水平扩展的瓶颈。

2. 了解云服务提供商可能强制实施的缩放上限。

3. 了解集群在按需扩展时的速度。

在LKE上启用​​群集自动化缩放​​,其实非常容易。首先,如下图所示,请导航到集群的概览页面,并单击Autoscale Pool按钮。

LKE集群的概览页面

然后,在下面的对话框中,输入LKE应维护的最小和最大节点数:

启用LKE的群集自动化缩放

LKE的集群自动化缩放既能够响应那些由于计算资源不足,而无法被调度的Pending pod,又可以通过监控未充分利用的节点,将其从集群中删除,以缩小集群的整体规模。

下面,我们来看一个被分配了2个CPU核和4 GB内存的双节点集群。为了触发群集的自动化缩放,我们可以通过如下命令,向应用添加更多的副本:

Shell
kubectl scale --replicas=15 deployment/pressure-api-deployment

在命令执行完毕后,您将会在下图中看到那些被部署的pod已进入了挂起状态:

等待调度的pod

如下图所示,LKE不久会将更多的节点添加到集群中,并在新的节点上调度它们:

LKE扩展集群

由于我们指定了让LKE扩展至多四个节点,因此您会发现一些pod仍然处于挂起状态。最后,让我们同样以如下命令来清理环境。

Shell
kubectl delete deployment/pressure-api-deployment

小结

综上所述,我们讨论了水平自动化缩放、垂直自动化缩放、以及集群自动化缩放的相关概念、用例和注意事项。以LKE为代表的托管式Kubernetes服务,能够通过内置的自动化调整工具,为您减少各种手动管理的工作量。总的说来:

  • 如果您的应用经常受到容量需求变化的影响,那么可以使用HPA来水平扩展它们。
  • VPA可以帮助您确定应用程序的最佳资源值。
  • CPA则可以帮助您满足需要随着集群中的负载进行扩展的应用需求。
  • 如果负载可能会扩展到超过集群本身的容量,那么就需要使用CA来自动调整集群本身。

译者介绍

陈峻 (Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式,分享前沿技术与新知;经常以线上、线下等方式,开展信息安全类培训与授课。

原文标题:Practical Introduction to Kubernetes Autoscaling Tools with Linode Kubernetes Engine,作者: Rahul Rai


责任编辑:华轩 来源: 51CTO
相关推荐

2022-09-01 08:50:22

kubernetes容器

2021-03-11 14:33:28

Kubernetes开源容器

2021-03-01 19:24:13

Kubernetes备份容器

2021-06-08 10:26:10

云计算云计算产业云应用

2023-08-31 08:21:42

KubernetesKADA驱动

2021-05-18 08:00:00

Kubernetes容器进程

2019-05-21 10:45:44

Docker架构容器

2022-12-26 07:52:33

DockerfileFROM命令

2018-07-18 09:45:09

云服务Kubernetes实践

2023-04-12 07:31:55

KyvernoKubernetes

2019-10-10 09:00:30

云端云迁移云计算

2022-04-20 12:08:17

容器安全漏洞网络安全

2018-07-13 09:05:13

KubernetesDevOps云计算

2022-11-30 15:28:55

2020-03-27 22:18:55

JavaScript编程语言代码

2020-03-16 08:48:18

Kubernetes容器云原生

2024-01-22 12:46:00

KubernetesAPI接口

2022-08-19 09:01:59

ReactTS类型

2022-09-12 16:02:32

测试企业工具

2023-05-25 16:20:03

Kubernetes集群
点赞
收藏

51CTO技术栈公众号