Pianifica una distribuzione di Container Apps su Kubernetes abilitato per Azure Arc

Usa questo articolo prima di installare l'estensione Container Apps su un cluster di produzione. Le Container Apps su Azure Arc utilizzano servizi di capacità e piattaforma forniti dal tuo cluster Kubernetes. Le decisioni su nodi, bilanciamento del carico, DNS, connettività in uscita, storage, identità, logging e aggiornamenti influenzano la disponibilità delle applicazioni.

Utilizza le sezioni di questo articolo per identificare i requisiti di implementazione e validare i prerequisiti prima dell'installazione.

Ambito di pianificazione

Container Apps su Azure Arc copre le risorse di Azure, un cluster Kubernetes esistente e le applicazioni distribuite. Pianifica le seguenti aree:

Topologia supportata e matrice di versione

Usa l'ultima versione della patch Kubernetes supportata dai fornitori che supporta anche Kubernetes abilitato per Azure Arc. La documentazione di Container Apps non pubblica una gamma di versioni Kubernetes separata per ogni distribuzione. Valida la distribuzione esatta e la versione Kubernetes con il supporto Microsoft prima di un'installazione o aggiornamento in produzione.

La matrice seguente riporta il supporto di distribuzione attualmente pubblicato. Convalidalo nuovamente con le estensioni disponibili per i cluster Kubernetes abilitati per Azure Arc e le limitazioni di App contenitore di Azure su Azure Arc prima di ogni installazione.

L'estensione non è supportata per nodi Windows o cluster Arm64. Il framework di estensione Arc richiede almeno un nodo adatto linux/amd64 , ma una distribuzione in produzione richiede abbastanza nodi adatti per l'estensione, i carichi di lavoro, gli aggiornamenti e i guasti.

Solo un'installazione KEDA supportata può essere eseguita sul cluster. Determina se KEDA sarà installato dall'estensione Container Apps o se esiste già nel cluster. Se KEDA esiste già, fermarsi e confermare la configurazione di coesistenza supportata prima di continuare. Non rimuovere l'installazione KEDA esistente né applicare impostazioni di estensione non documentate perché altri carichi di lavoro potrebbero dipendere da essa.

Requisiti di capacità

Capacità pianificata per:

• I componenti fissi e per nodo dell'estensione Container Apps elencati in Risorse create dall'estensione Container Apps.
• Il numero massimo previsto di repliche di ogni app contenitore.
• Esecuzioni di processo simultanee e bursting di ripetizione.
• Sidecar Dapr e sidecar applicativi.
• Carichi di lavoro di sistema Kubernetes e altri tenant del cluster.
• Aggiornamenti in sequenza dei nodi e delle estensioni.
• Guasto di almeno un nodo in una distribuzione ad alta disponibilità.

Impostare il numero massimo di repliche di un'applicazione non riserva la capacità del cluster.

Capacità minima di installazione

Non esiste un minimo universale di produzione perché posizionamento delle estensioni, componenti abilitati, numero dei nodi, carichi di lavoro dei daemon, installazione KEDA, Log Analytics, uso di DAPR e richieste di carico di lavoro variano. Usa le richieste di componenti di estensione pubblicate come base e misura le risorse allocabili, non totali, del nodo. La dimensione di un cluster di valutazione non è una raccomandazione di dimensionamento della produzione.

Prima dell'installazione, registra:

• CPU e memoria allocabili sui nodi idonei linux/amd64 .
• Numero di nodi e posizionamento nel dominio di errore.
• Capacità IP disponibile per pod e servizi.
• Sistema attuale e richieste e limiti degli inquilini.
• Capacità non disponibile a causa di contaminazioni, affinità, quote o budget di interruzione.

Stima della capacità di carico di lavoro

Per ogni applicazione, calcola:

peak capacity = maximum replicas x (application requests + sidecar requests)

Aggiungi la capacità massima di processi simultanei, la capacità di estensione, la riserva di sistema, il picco di aggiornamento e la riserva per guasti. Assicurati che etichette dei nodi, contaminazioni, regole di affinità e frammentazione delle risorse non rendano la capacità nominalmente libera non programmabile.

Valida il piano programmando i carichi di lavoro rappresentativi e simulando un drenaggio di nodo. Conferma che i pod di estensione e le repliche di carico di lavoro richieste siano pronti.

Requisiti di rete

Le app container su Azure Arc richiedono diversi percorsi di rete distinti:

Usare i requisiti di rete Kubernetes abilitato per Azure Arc come elenco di endpoint canonici. Non copiare la lista degli endpoint in un set di regole firewall senza selezionare il cloud Azure corretto e le funzionalità Arc abilitate. Testa ogni nome di dominio completamente qualificato (FQDN) richiesto dalla rete del cluster. I requisiti Arc affermano che gli endpoint HTTPS utilizzano certificati ufficialmente firmati e verificabili. Verificare il comportamento del proxy e dell'ispezione TLS in un cluster di non produzione; l'intercettazione non supportata o un certificato sostitutivo non affidabile possono impedire agli agenti e ai componenti dell'estensione di connettersi.

L'implementazione selezionata LoadBalancer determina il pool di indirizzi, le sonde di salute, il routing e la capacità richiesta. Se un bilanciatore di carico personalizzato richiede un indirizzo riservato, prenota prima l'indirizzo e passalo attraverso l'impostazione dell'estensione loadBalancerIp durante l'installazione. Le porte delle probe di integrità e gli intervalli IP di origine sono specifici dell'implementazione; ottenerli dal servizio di bilanciamento del carico selezionato anziché presumere i valori predefiniti di Azure Load Balancer.

Il cluster Kubernetes abilitato per Arc sottostante controlla le restrizioni di rete per l'ambiente connesso. Se una dipendenza dell'applicazione utilizza un endpoint privato, verifica da un pod dell'applicazione che il cluster possa risolverne il nome DNS e instradare il traffico verso il relativo IP privato. Le applicazioni che necessitano di informazioni IP client dovrebbero validare le intestazioni di inoltro prodotte dal bilanciatore di carico e dalla catena proxy selezionate e definire quali proxy sono affidabili.

Convalidare la rete

1. Distribuisci un servizio di test Kubernetes LoadBalancer e conferma che riceva un indirizzo raggiungibile da ogni rete client prevista.
2. Da un nodo del cluster o da un pod diagnostico appropriato, risolvere e connettersi a tutti gli endpoint Azure Arc richiesti e a tutte le dipendenze del carico di lavoro richieste.
3. Conferma che il proxy consenta il traffico HTTPS e WebSocket richiesto e non sostituisce i certificati con un emittente non affidabile.
4. Verifica che il DNS del cluster, il traffico pod-to-pod, i servizi, i webhook di ammissione e le sonde di integrità del bilanciatore di carico funzionino con le politiche di rete previste.
5. Dopo l'installazione dell'estensione, confermare che il servizio di ingresso riceva l'IP previsto ed è raggiungibile prima di creare i record DNS di produzione.

Requisiti DNS

Dopo l'installazione dell'estensione, distribuire un'applicazione di test e recuperarne il nome di dominio completo (FQDN) generato. Verifica che la FQDN si risolva e raggiunga l'ingresso di estensione da ogni rete client prevista. Il nome ambiente connesso fa parte del dominio applicativo generato, quindi sceglilo deliberatamente.

Per le applicazioni interne, usa DNS a orizzonte diviso quando i client interni ed esterni richiedono risposte diverse. Identifica la zona DNS autorevole, registra il tempo di vita e i requisiti di recupero. Determina se le applicazioni utilizzano il dominio generato, domini personalizzati o entrambi, e pianifica l'emissione e il rinnovo dei certificati prima del deployment.

Valida DNS e ingresso da ciascuna rete client prevista:

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

Il FQDN dell'applicazione deve risolversi nell'IP di ingresso e restituire la risposta attesa dell'applicazione. Rimuovi le intestazioni di autorizzazione, i cookie e le stringhe di query sensibili prima di condividere output verbosi.

Identità, segreti e registri

Le identità gestite non sono supportate per le app container su Azure Arc. Anche l'estrazione di immagini da Registro Azure Container usando l'identità gestita non è supportata.

Per accedere alle risorse di Azure, usare una registrazione dell'applicazione dedicata e un'entità servizio dedicata solo quando il servizio di destinazione lo supporta. Concedi solo i ruoli del piano dati necessari nell'ambito più ristretto possibile. Tieni separati l'ID tenant e il client ID dalla credenziale, usa un certificato quando l'applicazione e il servizio target lo supportano, e pianifica la scadenza e la rotazione delle credenziali. Non riutilizzare l'identità del cluster connesso ad Arc o l'identità di amministratore del cluster per l'accesso delle applicazioni.

Per i registri privati, usa una credenziale con ambito di registro e accesso pull-only dove il registro la supporta. Evita le credenziali da amministratore ACR per i carichi di lavoro in produzione. Memorizza le credenziali del registro e delle applicazioni come segreti delle Container App e riferiscili per nome dalla configurazione dell'applicazione.

I segreti delle Container Apps sono a scopo applicativo, e cambiare un segreto non aggiorna automaticamente le revisioni esistenti. Considera sia l'accesso al piano di controllo Azure sia l'accesso Kubernetes privilegiato come confini di sicurezza. Limitare l'accesso agli spazi di estensione e applicazioni secondo i requisiti di sicurezza di Kubernetes per la distribuzione.

Usa questa sequenza di rotazione:

1. Crea una seconda credenzialità valida presso il fornitore di identità o il registro di registrazione.
2. Aggiorna il segreto delle Container Apps e distribuisci o riavvia la revisione interessata secondo necessità.
3. Verifica i pull delle immagini e l'autenticazione dell'applicazione con la nuova credenziale.
4. Revoca la vecchia credenzialità.
5. Conferma che nessuna revisione o lavoro attivo faccia ancora riferimento al vecchio valore.

Non inserire mai valori segreti nella cronologia comandi, nel controllo versione, nei pacchetti diagnostici, nelle descrizioni dei pod o nei log delle applicazioni. Limita chi può leggere le impostazioni protette da estensioni e i segreti Kubernetes.

Storage

Pianifica lo storage in base alla persistenza richiesta dal carico di lavoro:

Le limitazioni delle Container Apps su Arc attualmente descrivono File di Azure SMB e richiedono il driver SMB CSI. Non dare per scontato che un tipo di volume supportato da Container Apps ospitate su Azure sia supportato su Arc. Usa i comandi di installazione SMB collegati da App contenitore di Azure su Azure Arc invece di mantenere un'altra copia qui.

Tratta le credenziali dell'account di archiviazione usate per un punto di montaggio come informazioni riservate. Le identità gestite non sono supportate per le Container Apps su Arc. Testa le opzioni di montaggio selezionate, i permessi dei file, l'accesso concorrente, il comportamento dei guasti e la rotazione delle credenziali con le versioni esatte del driver CSI e del servizio di storage utilizzate in produzione.

Pianifica il backup persistente dei dati, il ripristino, il test di ripristino, la retention e il disaster recovery. Verificare come le revisioni e i processi segnalano gli errori di montaggio e includere gli eventi dei pod e i log del driver CSI nella procedura di diagnostica. Linux è l'unico sistema operativo node supportato per l'estensione.

Osservabilità del piano

L'integrazione di Log Analytics è opzionale. Se hai intenzione di usarla, configurala quando installi l'estensione perché non puoi aggiungerla a quell'istanza in seguito.

Quando configuri Log Analytics, puoi trovare i log delle applicazioni in ContainerAppConsoleLogs_CL. L'esercitazione Creare un'app contenitore su Azure Arc illustra TimeGenerated, ContainerAppName_s e Log_s; esamina la tabella in tempo reale prima di creare query o avvisi. Prevedi 10-15 minuti per la validazione dell'assunzione iniziale.

Pianifica il costo dell'accesso all'area di lavoro, della conservazione, degli avvisi, dell'esportazione e dell'ingestione. Esamina la registrazione delle applicazioni per credenziali, dati personali e URL sensibili prima di abilitare la raccolta.

Se non configuri Log Analytics, o durante un incidente di ingestione, usa i log Kubernetes:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

I componenti di sistema scrivono log nell'output standard. Di default, la telemetria dei componenti di sistema viene inviata a Microsoft mentre i log delle applicazioni non vengono inviati a meno che non si configuri Log Analytics. Impostare logProcessor.enabled=false disabilita l'elaborazione dei log e l'inoltraggio allo spazio di lavoro e può aumentare le evidenze diagnostiche che il supporto ti chiede di raccogliere manualmente.

Prima della produzione, testare un messaggio di log dell'applicazione univoco end-to-end, creare avvisi per l'integrità delle estensioni e gli errori dell'applicazione e confermare che sia la diagnostica di Azure che Kubernetes siano accessibili.

Aggiornamento, backup e recupero

Seleziona e documenta una linea di rilascio delle estensioni e una politica di aggiornamento. Il tutorial per la configurazione di Container Apps usa il canale di rilascio stable con aggiornamenti automatici alle versioni secondarie. Le estensioni del cluster Azure Arc possono seguire una serie di rilascio con aggiornamenti automatici oppure essere fissate e aggiornate manualmente. Consulta le note di rilascio delle estensioni Container Apps prima di cambiare versione, e fornisci capacità di riserva, versioni Kubernetes compatibili, finestre di manutenzione e validazione delle applicazioni.

Prima di un'estensione o di un aggiornamento Kubernetes:

1. Confermare che gli stati del cluster connesso e del provisioning delle estensioni siano impostati su Succeeded.
2. Verifica che la combinazione di Kubernetes e dell'estensione di destinazione sia supportata.
3. Rivedi le note di rilascio e la configurazione attuale, inclusi il training train, l'impostazione di aggiornamento automatico, l'installazione KEDA, i namespace, Log Analytics e loadBalancerIp.
4. Verifica la capacità disponibile per la sostituzione graduale e conferma che i budget di interruzione consentano di procedere.
5. Verifica la connettività del registro immagini e le politiche di ammissione per le immagini target.
6. Fai il backup della configurazione della sorgente dell'applicazione e di tutti i dati persistenti dell'applicazione.
7. Eseguire gli smoke test dell'applicazione, dell'ingresso, del ridimensionamento, dei processi, dell'archiviazione e del logging prima e dopo la modifica.

Non considerare il backup del namespace Kubernetes come un backup delle risorse Azure. Il cluster connesso, l'estensione, la posizione personalizzata, l'ambiente connesso, le app container e i job sono rappresentati in Azure Resource Manager e dipendono dalle risorse in-cluster. Fai un backup separato della configurazione dichiarativa dell'applicazione. Non ripristinare manualmente le implementazioni gestite dalle estensioni, le risorse personalizzate o i segreti su un'estensione appena installata a meno che il supporto Microsoft non fornisca tale procedura di recupero.

Il downgrade o il rollback di un'estensione non è un meccanismo di ripristino generale documentato per Container Apps in Arc. Non cambiare il canale di rilascio, non bloccare una versione precedente e non modificare i carichi di lavoro gestiti dall'estensione come risposta a un incidente senza prima confermare con il supporto tecnico Microsoft una procedura supportata.

Sviluppa e testa un runbook di recupero che tenga conto dell'infrastruttura Kubernetes, del networking, del DNS, del bilanciamento del carico, dello storage, degli agenti Azure Arc, dell'estensione Container Apps, della posizione personalizzata, dell'ambiente connesso, della configurazione delle applicazioni, delle credenziali e dei dati persistenti dell'applicazione. Verifica gli ingressi, le revisioni, il ridimensionamento, i processi, lo spazio di archiviazione e i log dopo il ripristino. Utilizzare procedure di recupero supportate dalla topologia Kubernetes e dai prodotti di backup nella distribuzione.

Pianifica la disconnessione di Azure. Gli agenti ad arco richiedono connettività per scoprire i cambiamenti di estensione e propagare lo stato desiderato. Le impostazioni protette per una risorsa di estensione appena creata vengono mantenute fino a 48 ore; se il cluster rimane disconnesso durante quel periodo, l'estensione può spostarsi da Pending a Failed. Testare il comportamento del carico di lavoro durante la perdita della connettività Azure invece di assumere una garanzia di continuità.

Contenuti correlati

• App contenitore di Azure su Azure Arc
• Configura un cluster Kubernetes abilitato per Azure Arc per eseguire App contenitore di Azure
• Creare un'app contenitore in Azure Arc
• Risolvere i problemi di App contenitore di Azure in Kubernetes abilitato per Azure Arc
• Requisiti di rete Kubernetes abilitati per Azure Arc
• Percorsi personalizzati su Kubernetes con abilitazione ad Azure Arc
• Estensioni cluster in Kubernetes abilitato per Azure Arc