Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La funzionalità dei contenitori sidecar kubernetes mira a offrire un modo più affidabile e intuitivo per incorporare modelli sidecar nelle applicazioni Kubernetes, migliorando efficienza, affidabilità e semplicità.
Il sidecar nativo è adatto per Istio. Offre diversi vantaggi, tra cui gestione semplificata dei sidecar, maggiore affidabilità e coordinamento migliorato. In modalità sidecar nativa, il sidecar viene sempre avviato prima dell'applicazione principale. Si chiude correttamente anche dopo la chiusura dell'applicazione principale. Questo comportamento elimina la necessità di soluzioni alternative manuali per gestire i problemi relativi al ciclo di vita del contenitore o alla terminazione dei pod.
A partire dalla versione 1.29 di Kubernetes, la funzionalità dei contenitori sidecar è attivata per il servizio Azure Kubernetes. Grazie a questa modifica, la modalità sidecar nativo di Istio può essere usata con il componente aggiuntivo Istio per il servizio Azure Kubernetes. La modalità sidecar nativa è diventata l'impostazione predefinita per Istio a partire dalla versione 1.27. La mesh di servizi basata su Istio su AKS è allineata a questo comportamento con minimi disagi per i clienti attuali.
Comportamento predefinito
I cluster esistenti con l'add-on Istio che utilizzano il flag di funzionalità di anteprima IstioNativeSidecarModePreview mantengono il loro stato attuale di sidecar nativo, indipendentemente dalla versione del cluster o dalla revisione dell'add-on Istio.
A partire dal servizio Azure Kubernetes 1.33 e dal componente aggiuntivo Istio asm-1-29, il componente aggiuntivo mesh del servizio Azure Kubernetes usa per impostazione predefinita il sidecar nativo per il proxy Envoy in tutti i cluster. Prima di asm-1-29, questa impostazione si applica in base alla versione del cluster, alla revisione del componente aggiuntivo azure service mesh e al fatto che il componente aggiuntivo sia stato appena installato o aggiornato.
| Versione AKS | Revisione ASM | Comportamento di installazione del componente aggiuntivo | Comportamento di aggiornamento |
|---|---|---|---|
| < 1.33 | Qualsiasi | Disabled | Disabled |
| 1.33+ | < asm-1-27 |
Disabled | Disabled |
| 1.33+ | asm-1-27 |
Abilitata (versione di transizione) | Disabilitato (l'aggiornamento non viene abilitato automaticamente) |
| 1.33+ | asm-1-28 |
Abilitata (versione di transizione) | Disabilitato (l'aggiornamento non viene abilitato automaticamente) |
| 1.33+ | asm-1-29+ |
Enabled | Abilitata (tramite l'aggiornamento del mesh o del cluster alle versioni richieste) |
Nuovi cluster
Quando si crea un nuovo cluster del servizio Azure Kubernetes con il comando az aks create, scegliere una versione 1.33 o successiva, e Istio asm-1-27 o versione successiva. Il nuovo cluster ha la modalità sidecar nativo abilitata automaticamente.
az aks create \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER \
--enable-asm \
--kubernetes-version 1.33 \
--revision asm-1-27 \
--generate-ssh-keys
...
Per una nuova installazione di service mesh su un cluster >esistente con la versione AKS 1.33, selezionare asm-1-27 o successiva durante l'installazione.
Cluster esistenti
Questa sezione descrive come controllare lo stato della funzionalità sidecar nativa.
Controllare lo stato della funzionalità
Quando la modalità sidecar nativo è abilitata, la variabile di ambiente ENABLE_NATIVE_SIDECARS viene visualizzata con il valore true nel modello di pod del piano di controllo di Istio. Usare il comando seguente per controllare la distribuzione istiod.
kubectl get deployment -l app=istiod -n aks-istio-system -o json | jq '.items[].spec.template.spec.containers[].env[] | select(.name=="ENABLE_NATIVE_SIDECARS")'
Se la modalità sidecar nativa è abilitata correttamente, il istio-proxy contenitore viene visualizzato come contenitore di inizializzazione. Usare il comando seguente per controllare l'inserimento del sidecar:
kubectl get pods -o "custom-columns=NAME:.metadata.name,INIT:.spec.initContainers[*].name,CONTAINERS:.spec.containers[*].name"
Il istio-proxy contenitore deve essere visualizzato come init container.
NAME INIT CONTAINERS
sleep-7656cf8794-5b5j4 istio-init,istio-proxy sleep
Verificare i prerequisiti
Se il sidecar nativo non è abilitato, è probabile che uno dei prerequisiti della versione non sia stato soddisfatto.
Verificare che la versione del piano di controllo Kubernetes del cluster AKS sia 1.33 o successiva usando az aks show.
az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query "kubernetesVersion" -o tsvSe la versione del piano di controllo è troppo vecchia, è possibile aggiornare il piano di controllo Kubernetes.
Verificare che i pool di nodi eseguano la versione
1.33o successiva e che lo stato di alimentazione sia attivo.az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query "agentPoolProfiles[].{name:name,currentOrchestratorVersion:currentOrchestratorVersion,powerState:powerState.code}" -o tableAttenzione
Per impostazione predefinita, la modalità sidecar nativa richiede che sia il piano di controllo sia il piano dati di Kubernetes siano sulla versione 1.33 o successiva. Assicurarsi che tutti i nodi siano versione 1.33 o successiva prima di abilitare il componente aggiuntivo service mesh. In caso contrario, il sidecar nativo non verrà abilitato per impostazione predefinita.
Se una versione del pool di nodi è troppo vecchia, aggiornare l'immagine del nodo alla versione
1.33o successiva.Se il componente aggiuntivo service mesh è abilitato, controllare la revisione installata:
az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query "serviceMeshProfile.istio.revisions" -o tsvEsaminare la tabella sul comportamento predefinito per determinare se la revisione soddisfa i prerequisiti.