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-18genannt 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: trueDie Werte unter
defaultConfigsind 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 MeshConfig-Werte
Felder in MeshConfig werden als allowed, supported oder klassifiziertblocked. Weitere Informationen zu diesen Kategorien finden Sie unter Unterstützungsrichtlinie 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 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 bezieht sich auf die Generierung der Zugriffsprotokolle. Für eine verwaltete Funktion zum Sammeln und Abfragen von Protokollen finden Sie unter Azure Monitor-Funktionen für die Kubernetes-Überwachung. Es wird empfohlen, die Zugriffsprotokollierung über die Telemetrie-API zu konfigurieren. |
| accessLogFormat | Unterstützt | Dieses Feld bezieht sich auf die Generierung 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 bezieht sich auf die Generierung der Zugriffsprotokolle. Für eine verwaltete Erfahrung bei der Sammlung und Abfrage von Protokollen, siehe Azure Monitor Container Insights auf AKS |
| enableTracing | Zulässig | Es wird empfohlen, die Ablaufverfolgung über die Telemetrie-API zu konfigurieren. |
| enableEnvoyAccessLogService | Unterstützt | Dieses Feld bezieht sich auf die Generierung 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 bezieht sich auf die Generierung 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 | - |
| ingressService | Zulässig | Name des Kubernetes-Diensts, der für den istio-Eingangsdatencontroller verwendet wird. |
| ingressSelector | Zulässig | Definiert, welche Gatewaybereitstellung als Eingangsdatencontroller verwendet werden soll. Dieses Feld entspricht dem Feld „Gateway.selector“ und wird auf „istio: INGRESS_SELECTOR“ festgelegt. |
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 | Hinweise |
|---|---|---|
| tracingServiceName | Zulässig | Es wird empfohlen, die Ablaufverfolgung über die Telemetrie-API zu konfigurieren. |
| drainDuration | Unterstützt | - |
| statsUdpAddress | Zulässig | - |
| proxyAdminPort | Zulässig | - |
| tracing | Zulässig | Es wird empfohlen, die Ablaufverfolgung über die Telemetrie-API zu konfigurieren. |
| Nebenläufigkeit | Unterstützt | - |
| envoyAccessLogService | Zulässig | Es wird empfohlen, die Ablaufverfolgung über die Telemetrie-API zu konfigurieren. |
| envoyMetricsService | Zulässig | Es wird empfohlen, die Metriksammlung über die Telemetrie-API zu konfigurieren. |
| 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-systembefinden. - 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 FelddiscoverySelectorsin der MeshConfig zu verwenden, um den Speicherverbrauch von Istiod und Envoy zu verringern. - Wenn das Feld
concurrencyin 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
holdApplicationUntilProxyStartsin der MeshConfig entschärft werden.
Azure Kubernetes Service