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
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" }
Erstellen Sie eine ConfigMap mit dem Namen
istio-shared-configmap-<asm-revision>
im Namespaceaks-istio-system
. Wenn Ihr Cluster beispielsweise die Revision asm-1-18 von mesh ausführt, muss die ConfigMapistio-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 Namespaceaks-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 FelddiscoverySelectors
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.
Azure Kubernetes Service