مشاركة عبر

دمج KEDA مع مجموعة خدمة Azure Kubernetes

  • مقالة

KEDA هو مقياس تلقائي يستند إلى الأحداث المستندة إلى Kubernetes. يتيح لك KEDA قيادة تحجيم أي حاوية في Kubernetes استنادا إلى الحمل الذي ستتم معالجته، عن طريق الاستعلام عن المقاييس من أنظمة مثل Prometheus. دمج KEDA مع مجموعة Azure Kubernetes Service (AKS) لتوسيع نطاق أحمال العمل الخاصة بك استنادا إلى مقاييس Prometheus من مساحة عمل Azure Monitor.

لدمج KEDA في خدمة Azure Kubernetes، يجب عليك نشر وتكوين هوية حمل العمل أو هوية الجراب على نظام المجموعة الخاص بك. تسمح الهوية ل KEDA بالمصادقة مع Azure واسترداد المقاييس للتحجيم من مساحة عمل Monitor.

ترشدك هذه المقالة خلال خطوات دمج KEDA في مجموعة AKS باستخدام هوية حمل العمل.

إشعار

نوصي باستخدام هوية حمل عمل Microsoft Entra. يحل أسلوب المصادقة هذا محل الهوية المدارة بواسطة pod (معاينة)، والتي تتكامل مع قدرات Kubernetes الأصلية للاتحاد مع أي موفري هوية خارجيين نيابة عن التطبيق.

تم إهمال مصدر مفتوح الهوية المدارة بواسطة Microsoft Entra (معاينة) في خدمة Azure Kubernetes اعتبارا من 10/24/2022، وسيتم أرشفة المشروع في سبتمبر 2023. لمزيد من المعلومات، راجع إشعار الإهمال. تبدأ الوظيفة الإضافية المدارة AKS في الإهمال في سبتمبر 2023.

يبدأ دعم Azure Managed Prometheus من KEDA v2.10. إذا كان لديك إصدار أقدم من KEDA مثبتا، فيجب عليك الترقية للعمل مع Azure Managed Prometheus.

المتطلبات الأساسية

إعداد هوية حمل العمل

  1. ابدأ بإعداد بعض متغيرات البيئة. قم بتغيير القيم لتتناسب مع نظام مجموعة AKS.

    export RESOURCE_GROUP="rg-keda-integration"
export LOCATION="eastus"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="keda-int-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="kedaFedIdentity" 
export SERVICE_ACCOUNT_NAMESPACE="keda"
export SERVICE_ACCOUNT_NAME="keda-operator"
export AKS_CLUSTER_NAME="aks-cluster-name"
    • SERVICE_ACCOUNT_NAME - يجب أن تستخدم KEDA حساب الخدمة الذي تم استخدامه لإنشاء بيانات اعتماد موحدة. يمكن أن يكون هذا أي اسم معرف من قبل المستخدم.
    • AKS_CLUSTER_NAME- اسم نظام مجموعة AKS حيث تريد نشر KEDA.
    • SERVICE_ACCOUNT_NAMESPACE يجب أن يكون كل من KEDA وحساب الخدمة في نفس مساحة الاسم.
    • USER_ASSIGNED_IDENTITY_NAME هو اسم هوية Microsoft Entra التي تم إنشاؤها ل KEDA.
    • FEDERATED_IDENTITY_CREDENTIAL_NAME هو اسم بيانات الاعتماد التي تم إنشاؤها ل KEDA لاستخدامها للمصادقة مع Azure.

  2. إذا لم يتم إنشاء نظام مجموعة AKS الخاص بك مع تمكين هوية حمل العمل أو مصدر oidc، فستحتاج إلى تمكينه. إذا لم تكن متأكدا، يمكنك تشغيل الأمر التالي للتحقق مما إذا كان ممكنا.

    az aks show --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query oidcIssuerProfile
az aks show --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query securityProfile.workloadIdentity

    لتمكين هوية حمل العمل ومصدر oidc، قم بتشغيل الأمر التالي.

    az aks update -g $RESOURCE_GROUP -n $AKS_CLUSTER_NAME --enable-workload-identity --enable-oidc-issuer

  3. قم بتخزين عنوان URL لمصدر OIDC في متغير بيئة لاستخدامه لاحقا.

    export AKS_OIDC_ISSUER="$(az aks show -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv)"

  4. إنشاء هوية معينة من قبل المستخدم ل KEDA. يتم استخدام هذه الهوية من قبل KEDA للمصادقة مع Azure Monitor.

     az identity create --name $USER_ASSIGNED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --location $LOCATION --subscription $SUBSCRIPTION

    تتشابه النتيجة مع التالي:

    {
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-keda-integration/providers/Microsoft.    ManagedIdentity/userAssignedIdentities/keda-int-identity",
  "location": "eastus",
  "name": "keda-int-identity",
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "resourceGroup": "rg-keda-integration",
  "systemData": null,
  "tags": {},
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

  5. clientId قم بتخزين و tenantId في متغيرات البيئة لاستخدامها لاحقا.

    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query 'clientId' -otsv)"
export TENANT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query 'tenantId' -otsv)"

  6. تعيين دور قارئ بيانات المراقبة إلى هوية مساحة عمل Azure Monitor. يسمح هذا الدور للهوية بقراءة المقاييس من مساحة العمل الخاصة بك. استبدل مجموعة موارد مساحة عمل Azure Monitor واسم مساحة عمل Azure Monitor بمجموعة الموارد واسم مساحة عمل Azure Monitor التي تم تكوينها لجمع المقاييس من نظام مجموعة AKS.

    az role assignment create \
--assignee $USER_ASSIGNED_CLIENT_ID \
--role "Monitoring Data Reader" \
--scope /subscriptions/$SUBSCRIPTION/resourceGroups/<Azure Monitor Workspace resource group>/providers/microsoft.monitor/accounts/<Azure monitor workspace name>

  7. إنشاء مساحة اسم KEDA، ثم إنشاء حساب خدمة Kubernetes. يستخدم KEDA حساب الخدمة هذا للمصادقة مع Azure.

    
az aks get-credentials -n $AKS_CLUSTER_NAME -g $RESOURCE_GROUP

kubectl create namespace keda

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $USER_ASSIGNED_CLIENT_ID
  name: $SERVICE_ACCOUNT_NAME
  namespace: $SERVICE_ACCOUNT_NAMESPACE
EOF

  8. تحقق من حساب الخدمة الخاص بك عن طريق تشغيل

    kubectl describe serviceaccount $SERVICE_ACCOUNT_NAME -n keda

  9. إنشاء بيانات اعتماد موحدة بين حساب الخدمة والهوية المعينة للمستخدم. تسمح بيانات الاعتماد الموحدة لحساب الخدمة باستخدام الهوية المعينة من قبل المستخدم للمصادقة مع Azure.

    az identity federated-credential create --name $FEDERATED_IDENTITY_CREDENTIAL_NAME --identity-name $USER_ASSIGNED_IDENTITY_NAME --resource-group $RESOURCE_GROUP --issuer $AKS_OIDC_ISSUER --subject     system:serviceaccount:$SERVICE_ACCOUNT_NAMESPACE:$SERVICE_ACCOUNT_NAME --audience api://AzureADTokenExchange

    إشعار

    يستغرق نشر بيانات اعتماد الهوية الموحدة بعد إضافتها في البداية بضع ثوان. إذا تم إجراء طلب رمز مميز مباشرة بعد إضافة بيانات اعتماد الهوية الموحدة، فقد يؤدي ذلك إلى فشل لبضع دقائق حيث يتم ملء ذاكرة التخزين المؤقت في الدليل بالبيانات القديمة. لتجنب هذه المشكلة، يمكنك إضافة تأخير طفيف بعد إضافة بيانات اعتماد الهوية الموحدة.

توزيع KEDA

يمكن نشر KEDA باستخدام بيانات YAML أو مخططات Helm أو مركز المشغل. تستخدم هذه المقالة مخططات Helm. لمزيد من المعلومات حول نشر KEDA، راجع نشر KEDA

إضافة مستودع helm:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

انشر KEDA باستخدام الأمر التالي:

helm install keda kedacore/keda --namespace keda \
--set serviceAccount.create=false \
--set serviceAccount.name=keda-operator \
--set podIdentity.azureWorkload.enabled=true \
--set podIdentity.azureWorkload.clientId=$USER_ASSIGNED_CLIENT_ID \
--set podIdentity.azureWorkload.tenantId=$TENANT_ID

تحقق من التوزيع الخاص بك عن طريق تشغيل الأمر التالي.

kubectl get pods -n keda

تتشابه النتيجة مع التالي:

NAME                                               READY   STATUS    RESTARTS       AGE
keda-admission-webhooks-ffcb8f688-kqlxp            1/1     Running   0              4m
keda-operator-5d9f7d975-mgv7r                      1/1     Running   1 (4m ago)     4m
keda-operator-metrics-apiserver-7dc6f59678-745nz   1/1     Running   0              4m

أدوات تغيير الحجم

تحدد أدوات التحجيم كيف ومتى يجب على KEDA توسيع نطاق التوزيع. يدعم KEDA مجموعة متنوعة من أدوات تغيير الحجم. لمزيد من المعلومات حول أدوات تغيير الحجم، راجع أدوات تغيير الحجم. يستخدم Azure Managed Prometheus مقياس Prometheus الموجود بالفعل لاسترداد مقاييس Prometheus من مساحة عمل Azure Monitor. يعد ملف yaml التالي مثالا لاستخدام Azure Managed Prometheus.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-managed-prometheus-trigger-auth
spec:
  podIdentity:
      provider: azure-workload | azure # use "azure" for pod identity and "azure-workload" for workload identity
      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-managed-prometheus-scaler
spec:
  scaleTargetRef:
    name: deployment-name-to-be-scaled
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://test-azure-monitor-workspace-name-1234.eastus.prometheus.monitor.azure.com
      metricName: http_requests_total
      query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response
      threshold: '100.50'
      activationThreshold: '5.5'
    authenticationRef:
      name: azure-managed-prometheus-trigger-auth
  • serverAddress هي نقطة نهاية الاستعلام لمساحة عمل Azure Monitor. لمزيد من المعلومات، راجع الاستعلام عن مقاييس Prometheus باستخدام واجهة برمجة التطبيقات وPromQL
  • metricName هو اسم المقياس الذي تريد تغيير حجمه.
  • query هو الاستعلام المستخدم لاسترداد المقياس.
  • threshold هي القيمة التي يتم تحجيم التوزيع بها.
  • podIdentity.provider قم بتعيين وفقا لنوع الهوية التي تستخدمها.

استكشاف الأخطاء وإصلاحها

يوفر القسم التالي تلميحات استكشاف الأخطاء وإصلاحها للمشكلات الشائعة.

بيانات الاعتماد الموحدة

قد يستغرق نشر بيانات الاعتماد الموحدة ما يصل إلى 10 دقائق. إذا كنت تواجه مشكلات في مصادقة KEDA مع Azure، فجرب الخطوات التالية.

يظهر مقتطف السجل التالي خطأ مع بيانات الاعتماد الموحدة.

kubectl logs -n keda keda-operator-5d9f7d975-mgv7r

{
 \"error\": \"unauthorized_client\",\n  \"error_description\": \"AADSTS70021: No matching federated identity record found for presented assertion. 
Assertion Issuer: 'https://eastus.oic.prod-aks.azure.com/abcdef01-2345-6789-0abc-def012345678/12345678-abcd-abcd-abcd-1234567890ab/'.
Assertion Subject: 'system:serviceaccount:keda:keda-operator'. 
Assertion Audience: 'api://AzureADTokenExchange'. https://docs.microsoft.com/azure/active-directory/develop/workload-identity-federation
Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\\r\\nCorrelation ID: 1111bbbb-22cc-dddd-ee33-ffffff444444\\r\\nTimestamp: 2023-05-30 11:11:53Z\",
\"error_codes\": [\n    70021\n  ],\n  \"timestamp\": \"2023-05-30 11:11:53Z\",
\"trace_id\": \"2222cccc-33dd-eeee-ff44-aaaaaa555555\",
\"correlation_id\": \"aaaa0000-bb11-2222-33cc-444444dddddd\",
\"error_uri\": \"https://login.microsoftonline.com/error?code=70021\"\n}
\n--------------------------------------------------------------------------------\n"}

تحقق من القيم المستخدمة لإنشاء ServiceAccount وبيانات الاعتماد التي تم إنشاؤها باستخدام az identity federated-credential create وتأكد من subject تطابق القيمة مع system:serviceaccount القيمة.

أذونات مساحة عمل Azure Monitor

إذا كنت تواجه مشكلات في مصادقة KEDA مع Azure، فتحقق من أذونات مساحة عمل Azure Monitor. يوضح مقتطف السجل التالي أن الهوية ليس لديها أذونات قراءة لمساحة عمل Azure Monitor.

kubectl logs -n keda keda-operator-5d9f7d975-mgv7r

2023-05-30T11:15:45Z    ERROR   scale_handler   error getting metric for scaler 
{"scaledObject.Namespace": "default", "scaledObject.Name": "azure-managed-prometheus-scaler", "scaler": "prometheusScaler", 
"error": "prometheus query api returned error. status: 403 response: {\"status\":\"error\",
\"errorType\":\"Forbidden\",\"error\":\"User \\u0027abc123ab-1234-1234-abcd-abcdef123456
\\u0027 does not have access to perform any of the following actions 
\\u0027microsoft.monitor/accounts/data/metrics/read, microsoft.monitor/accounts/data/metrics/read
\\u0027 on resource \\u0027/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/rg-azmon-ws-01/providers/microsoft.monitor/accounts/azmon-ws-01\\u0027. RequestId: 123456c427f348258f3e5aeeefef834a\"}"}

تأكد من أن الهوية لها Monitoring Data Reader الدور على مساحة عمل Azure Monitor.