根据应用程序网关指标 (Beta) 自动缩放 AKS PodAutoscale your AKS pods using Application Gateway Metrics (Beta)

当传入流量增加时,必须根据需求纵向扩展应用程序。As incoming traffic increases, it becomes crucial to scale up your applications based on the demand.

在以下教程中,我们说明了如何使用应用程序网关的 AvgRequestCountPerHealthyHost 指标来纵向扩展应用程序。In the following tutorial, we explain how you can use Application Gateway's AvgRequestCountPerHealthyHost metric to scale up your application. AvgRequestCountPerHealthyHost 度量发送到特定后端池和后端 HTTP 设置组合的平均请求数。AvgRequestCountPerHealthyHost measures average requests sent to a specific backend pool and backend HTTP setting combination.

我们将使用以下两个组件:We are going to use following two components:

  • Azure Kubernetes Metric Adapter - 我们将使用指标适配器通过指标服务器公开应用程序网关指标。Azure Kubernetes Metric Adapter - We will use the metric adapter to expose Application Gateway metrics through the metric server. Azure Kubernetes 指标适配器是 Azure 下的一个开源项目,类似于应用程序网关入口控制器。The Azure Kubernetes Metric Adapter is an open source project under Azure, similar to the Application Gateway Ingress Controller.
  • Horizontal Pod Autoscaler - 我们将通过 HPA 来使用应用程序网关指标,并以用于缩放的部署为目标。Horizontal Pod Autoscaler - We will use HPA to use Application Gateway metrics and target a deployment for scaling.

设置 Azure Kubernetes 指标适配器Setting up Azure Kubernetes Metric Adapter

  1. 我们将首先创建一个 Azure AAD 服务主体,并通过应用程序网关的资源组为它分配 Monitoring Reader 访问权限。We will first create an Azure AAD service principal and assign it Monitoring Reader access over Application Gateway's resource group.

        applicationGatewayGroupName="<application-gateway-group-id>"
        applicationGatewayGroupId=$(az group show -g $applicationGatewayGroupName -o tsv --query "id")
        az ad sp create-for-rbac -n "azure-k8s-metric-adapter-sp" --role "Monitoring Reader" --scopes applicationGatewayGroupId
    
  2. 现在,我们将使用上面创建的 AAD 服务主体来部署 Azure Kubernetes Metric AdapterNow, We will deploy the Azure Kubernetes Metric Adapter using the AAD service principal created above.

    kubectl create namespace custom-metrics
    # use values from service principal created above to create secret
    kubectl create secret generic azure-k8s-metrics-adapter -n custom-metrics \
        --from-literal=azure-tenant-id=<tenantid> \
        --from-literal=azure-client-id=<clientid> \
        --from-literal=azure-client-secret=<secret>
    kubectl apply -f kubectl apply -f https://raw.githubusercontent.com/Azure/azure-k8s-metrics-adapter/master/deploy/adapter.yaml -n custom-metrics
    
  3. 我们将创建名为 appgw-request-count-metricExternalMetric 资源。We will create an ExternalMetric resource with name appgw-request-count-metric. 此资源会指示指标适配器在 myResourceGroup 资源组中公开 myApplicationGateway 资源的 AvgRequestCountPerHealthyHost 指标。This resource will instruct the metric adapter to expose AvgRequestCountPerHealthyHost metric for myApplicationGateway resource in myResourceGroup resource group. 可以使用 filter 字段,以应用程序网关中的特定后端池和后端 HTTP 设置为目标。You can use the filter field to target a specific backend pool and backend HTTP setting in the Application Gateway.

    apiVersion: azure.com/v1alpha2
    kind: ExternalMetric
    metadata:
    name: appgw-request-count-metric
    spec:
        type: azuremonitor
        azure:
            resourceGroup: myResourceGroup # replace with your application gateway's resource group name
            resourceName: myApplicationGateway # replace with your application gateway's name
            resourceProviderNamespace: Microsoft.Network
            resourceType: applicationGateways
        metric:
            metricName: AvgRequestCountPerHealthyHost
            aggregation: Average
            filter: BackendSettingsPool eq '<backend-pool-name>~<backend-http-setting-name>' # optional
    

现在可以向指标服务器发出请求,看我们的新指标是否已公开:You can now make a request to the metric server to see if our new metric is getting exposed:

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/appgw-request-count-metric"
# Sample Output
# {
#   "kind": "ExternalMetricValueList",
#   "apiVersion": "external.metrics.k8s.io/v1beta1",
#   "metadata":
#     {
#       "selfLink": "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/appgw-request-count-metric",
#     },
#   "items":
#     [
#       {
#         "metricName": "appgw-request-count-metric",
#         "metricLabels": null,
#         "timestamp": "2019-11-05T00:18:51Z",
#         "value": "30",
#       },
#     ],
# }

使用新指标纵向扩展部署Using the new metric to scale up the deployment

能够通过指标服务器公开 appgw-request-count-metric 以后,即可使用 Horizontal Pod Autoscaler 纵向扩展目标部署。Once we are able to expose appgw-request-count-metric through the metric server, we are ready to use Horizontal Pod Autoscaler to scale up our target deployment.

在以下示例中,我们将以示例部署 aspnet 为目标。In following example, we will target a sample deployment aspnet. 当每个 Pod 的 appgw-request-count-metric > 200 时,我们会纵向扩展 Pod,Pod 数上限为 10We will scale up Pods when appgw-request-count-metric > 200 per Pod up to a max of 10 Pods.

请替换目标部署名称,并应用以下自动缩放配置:Replace your target deployment name and apply the following auto scale configuration:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: deployment-scaler
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: aspnet # replace with your deployment's name
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metricName: appgw-request-count-metric
      targetAverageValue: 200

使用负载测试工具(例如 apache bench)对设置进行测试:Test your setup by using a load test tool like apache bench:

ab -n10000 http://<applicaiton-gateway-ip-address>/

后续步骤Next steps