Freigeben über


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

Das Open-Source-Tool Istio verwendet MeshConfig, um meshweite Einstellungen für das Istio Service-Mesh 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 dieser Anleitung 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:

    az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile'
    

    Ausgabe:

    {
      "istio": {
          "certificateAuthority": null,
          "components": {
          "egressGateways": null,
          "ingressGateways": null
          },
          "revisions": [
          "asm-1-18"
          ]
      },
      "mode": "Istio"
    }
    
  2. Erstellen Sie eine ConfigMap mit dem Namen istio-shared-configmap-<asm-revision> im Namespace aks-istio-system. Wenn Ihr Cluster beispielsweise die Revision asm-1-18 von mesh ausführt, muss die ConfigMap istio-shared-configmap-asm-1-18 genannt werden. Die Mesh-Konfiguration muss im Abschnitt Daten unter Mesh angegeben werden.

    Beispiel:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: istio-shared-configmap-asm-1-18
      namespace: aks-istio-system
    data:
      mesh: |-
        accessLogFile: /dev/stdout
        defaultConfig:
          holdApplicationUntilProxyStarts: true
    

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

Achtung

Eine Standard-ConfigMap (z. B. istio-asm-1-18 für die Revision asm-1-18) wird im Namespace aks-istio-system des Clusters erstellt, wenn das Istio-Add-On aktiviert ist. Diese Standard-ConfigMap wird jedoch von dem verwalteten Istio-Add-On abgeglichen. Daher sollten diese ConfigMap NICHT direkt bearbeitet werden. Stattdessen sollte eine revisionsspezifische gemeinsame Istio-ConfigMap (z. B. istio-shared-configmap-asm-1-18 für die Revision asm-1-18) im Namensraum aks-istio-system erstellt werden. Die Istio-Steuerungsebene wird diese dann mit der Standard-ConfigMap zusammenführen, wobei die Standardeinstellungen Vorrang haben.

Mesh-Konfiguration und -Upgrades

Wenn Sie ein Canary-Upgrade für Istio durchführen, müssen Sie eine separate ConfigMap für die neue Revision im Namespace aks-istio-system erstellen, bevor Sie das Canary-Upgrade einleiten. 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-18 auf asm-1-19 aktualisieren, müssen Sie die Änderungen von istio-shared-configmap-asm-1-18 kopieren, um eine neue ConfigMap mit dem Namen istio-shared-configmap-asm-1-19 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 Werte

Felder in MeshConfig werden in drei Kategorien unterteilt:

  • Blockiert: Nicht zugelassene Felder werden über Add-On-verwaltete Zulassungswebhooks blockiert. Der API-Server veröffentlicht sofort die Fehlermeldung, dass das Feld nicht zulässig ist.
  • Unterstützt: Unterstützte Felder (z. B. Felder, die sich auf die Zugriffsprotokollierung beziehen) werden vom Azure-Support unterstützt.
  • Zulässig: Diese Felder (wie z. B. proxyListenPort oder proxyInboundListenPort) sind zwar zulässig, werden aber nicht von Azure unterstützt.

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 enthalten sind, jedoch nicht in der folgenden Tabelle, sind blockiert. configSources ist beispielsweise blockiert.

Feld Unterstützt/ Zulässig Hinweise
proxyListenPort Zulässig -
proxyInboundListenPort Zulässig -
proxyHttpPort Zulässig -
connectTimeout Zulässig Konfigurierbar in DestinationRule
tcpKeepAlive Zulässig Konfigurierbar in DestinationRule
defaultConfig Unterstützt Wird verwendet, um ProxyConfig zu konfigurieren
outboundTrafficPolicy Unterstützt Auch konfigurierbar in Sidecar CR
extensionProviders Zulässig -
defaultProviders Zulässig -
accessLogFile Unterstützt Dieses Feld betrifft die Erstellung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS
accessLogFormat Unterstützt Dieses Feld betrifft die Erstellung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS
accessLogEncoding Unterstützt Dieses Feld betrifft die Erstellung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS
enableTracing Zulässig
enableEnvoyAccessLogService Unterstützt Dieses Feld betrifft die Erstellung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS
disableEnvoyListenerLog Unterstützt Dieses Feld betrifft die Erstellung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS
trustDomain Zulässig -
trustDomainAliases Zulässig -
caCertificates Zulässig Konfigurierbar in DestinationRule
defaultServiceExportTo Zulässig Konfigurierbar in ServiceEntry
defaultVirtualServiceExportTo Zulässig Konfigurierbar in VirtualService
defaultDestinationRuleExportTo Zulässig Konfigurierbar in DestinationRule
localityLbSetting Zulässig Konfigurierbar in DestinationRule
dnsRefreshRate Zulässig -
h2UpgradePolicy Zulässig Konfigurierbar in DestinationRule
enablePrometheusMerge Zulässig -
discoverySelectors Unterstützt -
pathNormalization Zulässig -
defaultHttpRetryPolicy Zulässig Konfigurierbar in VirtualService
serviceSettings Zulässig -
meshMTLS Zulässig -
tlsDefaults Zulässig -

ProxyConfig (meshConfig.defaultConfig)

Felder, die in der Open-Source MeshConfig Referenzdokumentation enthalten sind, jedoch nicht in der folgenden Tabelle, sind blockiert.

Feld Unterstützt/ Zulässig
tracingServiceName Zulässig
drainDuration Unterstützt
statsUdpAddress Zulässig
proxyAdminPort Zulässig
tracing Zulässig
Nebenläufigkeit Unterstützt
envoyAccessLogService Zulässig
envoyMetricsService Zulässig
proxyMetadata Zulässig
statusPort Zulässig
extraStatTags Zulässig
proxyStatsMatcher Zulässig
terminationDrainDuration Unterstützt
meshId Zulässig
holdApplicationUntilProxyStarts Unterstützt
caCertificatesPem Zulässig
privateKeyProvider Zulässig

Achtung

Unterstützungsumfang von Konfigurationen: Die Mesh-Konfiguration ermöglicht es, Erweiterungsanbieter wie selbstverwaltete Instanzen von Zipkin oder Apache Skywalking mit dem Istio-Add-On zu konfigurieren. Diese Erweiterungsanbieter liegen jedoch außerhalb des Unterstützungsumfangs des Istio-Add-Ons. Alle Probleme im Zusammenhang mit Erweiterungs-Tools liegen außerhalb des Unterstützungsbereichs des Istio-Add-Ons.

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-18) bearbeiten und nicht versuchen, die Standard-ConfigMap (z. B. istio-asm-1-18) 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.
  • Wenn Sie Canary-Upgrades durchführen, überprüfen Sie 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.