Configurare il componente aggiuntivo mesh di servizi basato su Istio per servizio Azure Kubernetes
Istio open source usa MeshConfig per definire le impostazioni di mesh per la mesh del servizio Istio. Il componente aggiuntivo mesh del servizio basato su Istio per il servizio Azure Kubernetes si basa su MeshConfig e classifica diverse proprietà come supportate, consentite e bloccate.
Questo articolo illustra come configurare il componente aggiuntivo mesh di servizi basato su Istio per il servizio Azure Kubernetes e i criteri di supporto applicabili per la configurazione.
Prerequisiti
Questa guida presuppone che sia stata seguita la documentazione per abilitare il componente aggiuntivo Istio in un cluster del servizio Azure Kubernetes.
Impostare la configurazione nel cluster
Individuare quale versione di Istio è implementata nel cluster:
az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile'Output:
{ "istio": { "certificateAuthority": null, "components": { "egressGateways": null, "ingressGateways": null }, "revisions": [ "asm-1-18" ] }, "mode": "Istio" }Creare un oggetto ConfigMap con il nome
istio-shared-configmap-<asm-revision>nello spazio dei nomiaks-istio-system. Ad esempio, se il cluster esegue la revisione di mesh asm-1-18, il ConfigMap deve essere denominato comeistio-shared-configmap-asm-1-18. La configurazione mesh deve essere fornita nella sezione dati della mesh.Esempio:
apiVersion: v1 kind: ConfigMap metadata: name: istio-shared-configmap-asm-1-18 namespace: aks-istio-system data: mesh: |- accessLogFile: /dev/stdout defaultConfig: holdApplicationUntilProxyStarts: trueI valori in
defaultConfigsono impostazioni di mesh applicate al proxy sidecar Envoy.
Attenzione
Quando il componente aggiuntivo Istio è abilitato, un oggetto ConfigMap predefinito (ad esempio, istio-asm-1-18 per la revisione asm-1-18) viene creato nello spazio dei nomi aks-istio-system del cluster. Tuttavia, le differenze di questo ConfigMap predefinito vengono risolte dal componente aggiuntivo gestito di Istio; pertanto, gli utenti devono astenersi dal modificare direttamente il ConfigMap. Gli utenti devono invece creare un ConfigMap condiviso di Istio specifico alla revisione (come istio-shared-configmap-asm-1-18 per la revisione asm-1-18) nello spazio dei nomi aks-istio-system. Il piano di controllo di Istio procederà quindi a combinarlo con il ConfigMap predefinito, dando la precedenza alle impostazioni predefinite.
Configurazione e aggiornamenti mesh
Quando si esegue l'aggiornamento canary per Istio, è necessario creare un ConfigMap separato per la nuova revisione nello spazio dei nomi prima di avviare l'aggiornamento aks-istio-systemcanary. In questo modo, la configurazione sarà disponibile quando il piano di controllo della nuova revisione viene implementato nel cluster. Ad esempio, per aggiornare la mesh da asm-1-18 a asm-1-19, è necessario copiare le modifiche da istio-shared-configmap-asm-1-18 per creare un nuovo ConfigMap denominato istio-shared-configmap-asm-1-19 nello spazio dei nomi aks-istio-system.
Dopo aver completato l’aggiornamento o averne eseguito il rollback, il ConfigMap della revisione rimossa dal cluster può essere eliminato.
Valori consentiti, supportati e bloccati
I campi in MeshConfig sono classificati in tre categorie:
- Bloccato: i campi non consentiti vengono bloccati tramite webhook di ammissione gestiti da componenti aggiunti. Il server API pubblica immediatamente un messaggio di errore, comunicando all’utente che il campo è stato rifiutato.
- Supportato: i campi supportati (ad esempio, i campi relativi alla registrazione di accesso) ricevono assistenza dal supporto tecnico di Azure.
- Consentito: questi campi (ad esempio proxyListenPort o proxyInboundListenPort) sono consentiti, ma non sono trattati dal supporto tecnico di Azure.
La configurazione mesh e l'elenco dei campi consentiti/supportati sono revisioni specifiche volte a tenere conto dei campi aggiunti/rimossi nelle revisioni. L'elenco completo dei campi consentiti e quelli supportati/non supportati all'interno dell'elenco consentito è disponibile nella seguente tabella. Quando una nuova revisione del mesh viene resa disponibile, tutte le modifiche apportate alla classificazione dei campi consentita e supportata sono indicate in questa tabella.
MeshConfig
| Campo | Supportata | Note |
|---|---|---|
| proxyListenPort | false | - |
| proxyInboundListenPort | false | - |
| proxyHttpPort | false | - |
| connectTimeout | false | Configurabile in DestinationRule |
| tcpKeepAlive | false | Configurabile in DestinationRule |
| defaultConfig | true | Usato per configurare ProxyConfig |
| outboundTrafficPolicy | true | Configurabile anche in Sidecar CR |
| extensionProviders | false | - |
| defaultProviders | false | - |
| accessLogFile | true | - |
| accessLogFormat | true | - |
| accessLogEncoding | true | - |
| enableTracing | true | - |
| enableEnvoyAccessLogService | true | - |
| disableEnvoyListenerLog | true | - |
| trustDomain | false | - |
| trustDomainAliases | false | - |
| caCertificates | false | Configurabile in DestinationRule |
| defaultServiceExportTo | false | Configurabile in ServiceEntry |
| defaultVirtualServiceExportTo | false | Configurabile in VirtualService |
| defaultDestinationRuleExportTo | false | Configurabile in DestinationRule |
| localityLbSetting | false | Configurabile in DestinationRule |
| dnsRefreshRate | false | - |
| h2UpgradePolicy | false | Configurabile in DestinationRule |
| enablePrometheusMerge | true | - |
| discoverySelectors | true | - |
| pathNormalization | false | - |
| defaultHttpRetryPolicy | false | Configurabile in VirtualService |
| serviceSettings | false | - |
| meshMTLS | false | - |
| tlsDefaults | false | - |
ProxyConfig (meshConfig.defaultConfig)
| Campo | Supportata |
|---|---|
| tracingServiceName | true |
| drainDuration | true |
| statsUdpAddress | false |
| proxyAdminPort | false |
| tracing | true |
| concurrency | true |
| envoyAccessLogService | true |
| envoyMetricsService | true |
| proxyMetadata | false |
| statusPort | false |
| extraStatTags | false |
| proxyStatsMatcher | false |
| terminationDrainDuration | true |
| meshId | false |
| holdApplicationUntilProxyStarts | true |
| caCertificatesPem | false |
| privateKeyProvider | false |
I campi presenti nella documentazione di riferimento dell’open source MeshConfig ma non nella tabella precedente sono bloccati. Ad esempio, configSources è bloccato.
Attenzione
Ambito di supporto delle configurazioni: la configurazione mesh consente ai provider di estensioni, come istanze autogestite di Zipkin o Apache Skycker, di essere configurati con il componente aggiuntivo Istio. Tuttavia, questi provider di estensioni non rientrano nell'ambito di supporto del componente aggiuntivo Istio. Eventuali problemi associati agli strumenti di estensione non rientrano nel limite del supporto del componente aggiuntivo Istio.
Errori frequenti e suggerimenti per la risoluzione dei problemi
- Assicurarsi che MeshConfig sia rientrato con spazi anziché tab.
- Assicurarsi di modificare solo il ConfigMap condiviso relativo alla revisione (come
istio-shared-configmap-asm-1-18) e non tentare di modificare il ConfigMap predefinito (comeistio-asm-1-18). - ConfigMap deve seguire il nome
istio-shared-configmap-<asm-revision>e trovarsi nello spazio dei nomiaks-istio-system. - Assicurarsi che tutti i campi MeshConfig siano digitati correttamente. Se non sono riconosciute o se non fanno parte dell'elenco autorizzato, il controllo di ammissione rifiuta le configurazioni.
- Quando si eseguono aggiornamenti canary, controllare i ConfigMap relativi alla revisione per assicurarsi che le configurazioni per le revisioni implementate nel cluster siano esistenti.
- Alcune opzioni
MeshConfig, come accessLogging, possono aumentare l'utilizzo delle risorse di Envoy. Disabilitare alcune di queste impostazioni può ridurre l'utilizzo delle risorse del piano dati Istio. È anche consigliabile usare il campodiscoverySelectorsin MeshConfig per ridurre il consumo di memoria per Istiod ed Envoy. - Se il campo
concurrencyin MeshConfig non è configurato correttamente ed è impostato su zero, Envoy utilizzerà tutti i core CPU. Se invece il campo non è impostato, il numero di thread di lavoro da eseguire verrà determinato automaticamente in base alle richieste/limiti della CPU. - Race condition di pod e sidecar in cui l'applicazione è avviata prima che Envoy possa essere mitigato usando il campo
holdApplicationUntilProxyStartsnel MeshConfig.