Konfigurieren des Istio-basierten Service Mesh-Add-on für Azure Kubernetes Service

Open-Source Istio verwendet MeshConfig , um gitterweite Einstellungen für das Istio-Dienstgitter zu definieren. Das Istio-basierte Service Mesh-Add-on für AKS baut auf MeshConfig auf und klassifiziert verschiedene Eigenschaften als unterstützt, erlaubt und blockiert.

In diesem Artikel erfahren Sie, wie Sie das Istio-basierte Service Mesh-Add-on für Azure Kubernetes Service konfigurieren und welche Support-Richtlinien für eine solche Konfiguration gelten.

Voraussetzungen

In diesem Handbuch wird davon ausgegangen, dass Sie die Dokumentation befolgt haben, um das Istio-Add-On auf einem AKS-Cluster zu aktivieren.

Einrichten der Konfiguration auf einem Cluster

1. Finden Sie heraus, welche Revision von Istio auf dem Cluster bereitgestellt wird:

   export RANDOM_SUFFIX=$(head -c 3 /dev/urandom | xxd -p)
   export CLUSTER="my-aks-cluster"
   export RESOURCE_GROUP="my-aks-rg$RANDOM_SUFFIX"
   az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile' --output json
   

   Ergebnisse:

   {
     "istio": {
       "certificateAuthority": null,
       "components": {
         "egressGateways": null,
         "ingressGateways": null
       },
       "revisions": [
         "asm-1-24"
       ]
     },
     "mode": "Istio"
   }
   

   Dieser Befehl zeigt das Istio-Dienstgitterprofil an, einschließlich der aktuell auf Ihrem AKS-Cluster bereitgestellten Überarbeitungen.

2. Erstellen Sie eine ConfigMap mit dem Namen istio-shared-configmap-<asm-revision> im Namespace aks-istio-system. Zum Beispiel, wenn Ihr Cluster die asm-1-24-Version des Mesh verwendet, muss die ConfigMap als istio-shared-configmap-asm-1-24 benannt werden. Die Mesh-Konfiguration muss im Abschnitt Daten unter Mesh angegeben werden.

   Beispiel:

   cat <<EOF > istio-shared-configmap-asm-1-24.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: istio-shared-configmap-asm-1-24
     namespace: aks-istio-system
   data:
     mesh: |-
       accessLogFile: /dev/stdout
       defaultConfig:
         holdApplicationUntilProxyStarts: true
   EOF
   kubectl apply -f istio-shared-configmap-asm-1-24.yaml
   

   Ergebnisse:

   configmap/istio-shared-configmap-asm-1-24 created
   

   Die Werte unter defaultConfig sind meshweite Einstellungen, die für den Envoy Sidecar-Proxy gelten.

Mesh-Konfiguration und -Upgrades

Wenn Sie das Canary-Upgrade für Istio durchführen, müssen Sie eine separate ConfigMap für die neue Revision im aks-istio-system Namespace erstellen, bevor Sie das Canary-Upgrade initiieren. So steht die Konfiguration zur Verfügung, wenn die Steuerungsebene der neuen Revision auf dem Cluster bereitgestellt wird. Wenn Sie beispielsweise das Mesh von asm-1-24 auf asm-1-25 aktualisieren, müssen Sie Änderungen von istio-shared-configmap-asm-1-24 kopieren, um eine neue ConfigMap namens istio-shared-configmap-asm-1-25 im Namespace aks-istio-system zu erstellen.

Nachdem das Upgrade abgeschlossen oder zurückgesetzt wurde, können Sie die ConfigMap der Revision, die aus dem Cluster entfernt wurde, löschen.

Zulässige, unterstützte und blockierte MeshConfig-Werte

Felder in MeshConfig werden als allowed, supported oder blocked klassifiziert. Weitere Informationen zu diesen Kategorien finden Sie in der Supportrichtlinie für Istio-Add-On-Features und Konfigurationsoptionen.

Die Mesh-Konfiguration und die Liste der zulässigen/unterstützten Felder sind revisionsspezifisch, um die Möglichkeit einzubeziehen, dass Felder in verschiedenen Revisionen hinzugefügt/entfernt werden können. Die vollständige Liste der zulässigen Felder und der unterstützten/nicht unterstützten Felder innerhalb der Liste der zulässigen Felder finden Sie in der folgenden Tabelle. Wenn eine neue Mesh-Revision zur Verfügung gestellt wird, werden alle Änderungen an der Klassifizierung der erlaubten und unterstützten Felder in dieser Tabelle vermerkt.

MeshConfig

Felder, die in der Open Source MeshConfig-Referenzdokumentation vorhanden sind, die in der folgenden Tabelle nicht behandelt werden, werden blockiert. configSources ist beispielsweise blockiert.

ProxyConfig (meshConfig.defaultConfig)

Felder, die in der Open Source MeshConfig-Referenzdokumentation vorhanden sind, die in der folgenden Tabelle nicht behandelt werden, werden blockiert.

Häufig auftretende Fehler und Problembehandlungstipps

• Stellen Sie sicher, dass die MeshConfig mit Leerzeichen anstelle von Tabstopps eingerückt ist.
• Stellen Sie sicher, dass Sie nur die revisionsspezifische freigegebene ConfigMap (z. B. istio-shared-configmap-asm-1-24) bearbeiten und nicht versuchen, die Standard-ConfigMap (z. B. istio-asm-1-24) zu bearbeiten.
• Die ConfigMap muss dem Namen istio-shared-configmap-<asm-revision> entsprechen und sich im Namespace aks-istio-system befinden.
• Stellen Sie sicher, dass alle MeshConfig-Felder richtig geschrieben sind. Wenn sie nicht erkannt werden oder nicht in der zulässigen Liste enthalten sind, verweigert die Zugangskontrolle solche Konfigurationen.
• Überprüfen Sie beim Durchführen von Canary-Upgrades Ihre revisionsspezifischen ConfigMaps, um sicherzustellen, dass Konfigurationen für die auf Ihrem Cluster bereitgestellten Revisionen vorhanden sind.
• Bestimmte MeshConfig-Optionen wie accessLogging können den Ressourcenverbrauch von Envoy erhöhen, und die Deaktivierung einiger dieser Einstellungen kann die Ressourcenauslastung der Istio-Datenebene verringern. Es ist auch ratsam, das Feld discoverySelectors in der MeshConfig zu verwenden, um den Speicherverbrauch von Istiod und Envoy zu verringern.
• Wenn das Feld concurrency in der MeshConfig falsch konfiguriert und auf Null gesetzt ist, führt dies dazu, dass Envoy alle CPU-Kerne verwendet. Wenn dieses Feld nicht gesetzt ist, wird die Anzahl der zu startenden Worker-Threads automatisch auf der Grundlage der CPU-Anforderungen/Grenzwerte bestimmt.
• Pod- und Sidecar-Racebedingungen, bei denen die Anwendung vor Envoy startet, können mit dem Feld holdApplicationUntilProxyStarts in der MeshConfig entschärft werden.