Criteri di supporto per servizio Azure Kubernetes

Questo articolo descrive i criteri di supporto tecnico e le limitazioni per Servizio Azure Kubernetes (AKS). Illustra anche la gestione dei nodi dell'agente, i componenti del piano di controllo gestito, i componenti non Microsoft open source e la sicurezza o la gestione delle patch.

Versioni e aggiornamenti del servizio

• Per informazioni sulle versioni, vedere AKS release notes (Note sulle versioni del servizio Azure Kubernetes).
• Per informazioni sulle funzionalità di anteprima, vedere la roadmap AKS.

Funzionalità gestite nel servizio Azure Kubernetes

AKS è una combinazione di Infrastruttura come Servizio (IaaS) e Platform as a Service (PaaS). I componenti cloud IaaS di base, ad esempio componenti di calcolo o di rete, forniscono l'accesso a controlli di basso livello e opzioni di personalizzazione. Al contrario, AKS fornisce una distribuzione Kubernetes chiavi in mano che offre un insieme comune di configurazioni e funzionalità necessarie per il cluster. Come utente di AKS, hai opzioni di personalizzazione e distribuzione limitate e non gestisci direttamente i cluster Kubernetes.

Con il servizio Azure Kubernetes si ottiene un piano di controllo completamente gestito. Il piano di controllo contiene tutti i componenti e i servizi necessari per operare e distribuire cluster Kubernetes agli utenti finali. Microsoft mantiene e gestisce tutti i componenti Kubernetes.

Microsoft gestisce e monitora i componenti seguenti tramite il piano di controllo:

• Il server API Kubernetes e kubelet.
• etcd o un archivio chiave-valore compatibile, che fornisce qualità del servizio (QoS), scalabilità e runtime.
• Servizi DNS come CoreDNS.
• kube-proxy e la rete del cluster, tranne quando si utilizza BYOCNI.
• Qualsiasi altro componente aggiuntivo o componente di sistema in esecuzione nello spazio dei nomi kube-system.

Alcuni componenti, come i nodi agente, hanno responsabilità condivisa, in cui è necessario contribuire alla manutenzione del cluster AKS. È necessario l'intervento dell'utente, ad esempio, per applicare una patch di sicurezza del sistema operativo al nodo agente.

I servizi sono gestiti nel senso che Microsoft e il team di AKS distribuiscono, operano e sono responsabili della disponibilità e delle funzionalità del servizio. Ai clienti non è consentito modificare questi componenti gestiti. Microsoft limita la personalizzazione per garantire un'esperienza utente coerente e scalabile.

Responsabilità condivisa

Quando si crea un cluster, si definiscono i nodi dell'agente Kubernetes creati dal servizio Azure Kubernetes. I carichi di lavoro sono eseguiti su questi nodi. Tenere presenti i vincoli dei nodi agente seguenti:

• supporto tecnico Microsoft ha accesso limitato. Poiché i nodi dell'agente eseguono codice privato e archiviano dati sensibili, il supporto tecnico Microsoft non può accedere, eseguire comandi su o visualizzare i log di questi nodi senza l'autorizzazione esplicita o l'assistenza dell'utente.
• Usare meccanismi nativi di Kubernetes per le modifiche. Qualsiasi modifica apportata direttamente ai nodi dell'agente tramite le API IaaS rende il cluster non supportabile. Applica le modifiche utilizzando meccanismi nativi di Kubernetes come DaemonSet.
• Non modificare i metadati creati dal sistema. È possibile aggiungere metadati come tag ed etichette, ma la modifica di qualsiasi metadato creato dal sistema rende il cluster non supportato.

Divisione di responsabilità

La matrice seguente riepiloga le responsabilità di supporto all’interno di un cluster AKS e mette a confronto AKS con Kubernetes autogestito eseguito on-premises. In AKS, Microsoft gestisce il piano di controllo e la piattaforma di base. È possibile gestire la configurazione del nodo, i carichi di lavoro, la configurazione di rete e i dati. Le aree condivise sono le aree in cui Microsoft fornisce e gestisce una funzionalità e si abilita, configura o pianifica la funzionalità. Usate la matrice come guida di riferimento rapido, quindi consultate le sezioni dettagliate che seguono per i dettagli sul supporto.

Usare la chiave seguente per leggere la matrice:

Per le aree condivise riportate nella matrice seguente, la tabella mostra ciò che Microsoft fornisce e ciò di cui si è responsabili:

Copertura del supporto per il servizio Azure Kubernetes

Le sezioni seguenti descrivono gli scenari supportati e non supportati per il supporto tecnico del servizio Azure Kubernetes.

Scenari supportati

Microsoft fornisce supporto tecnico per gli esempi seguenti:

Qualsiasi azione del cluster eseguita da Microsoft o da AKS viene effettuata con il consenso dell'utente tramite un ruolo Kubernetes predefinito aks-service e un'associazione di ruolo predefinita aks-service-rolebinding, che associa il ruolo all'identità del servizio supporto tecnico Microsoft aks-support. Questo ruolo consente al servizio Azure Kubernetes di risolvere e diagnosticare i problemi del cluster, ma non può modificare le autorizzazioni o creare ruoli o associazioni di ruoli o eseguire altre azioni con privilegi elevati. L'accesso ai ruoli è abilitato solo nei ticket di supporto attivi con accesso JIT (Just-In-Time).

Scenari non supportati

Microsoft non fornisce supporto tecnico per gli scenari seguenti.

Alcuni di questi scenari hanno più sfumature su ciò che Microsoft può comunque essere utile. Per altre informazioni, vedere Dettagli sugli scenari non supportati.

Dettagli sugli scenari non supportati

Diversi scenari non supportati hanno aggiunto sfumature su ciò che Microsoft può comunque aiutare con:

• Come usare Kubernetes. supporto tecnico Microsoft non fornisce consigli su come creare controller di ingresso personalizzati, usare carichi di lavoro dell'applicazione o applicare pacchetti o strumenti software non Microsoft o open source. supporto tecnico Microsoft può consigliare sulla funzionalità, personalizzazione e ottimizzazione del cluster AKS (Azure Kubernetes Service), ad esempio, su problemi e procedure delle operazioni di Kubernetes.
• Progetti open source non Microsoft. Questi progetti non vengono forniti come parte del control plane di Kubernetes né distribuiti con i cluster AKS e possono includere Istio, Helm, Envoy o altri. Microsoft può fornire un supporto ottimale per progetti come Helm. Quando lo strumento si integra con il provider cloud Azure per Kubernetes o in presenza di altri bug specifici di AKS, Microsoft fornisce supporto per gli esempi e le applicazioni presenti nella documentazione Microsoft.
• Personalizzazioni di rete. Per personalizzazioni diverse da quelle elencate nella documentazione di AKS, supporto tecnico Microsoft non può configurare dispositivi o appliance virtuali destinati a fornire traffico in uscita per il cluster, come VPN o firewall. In base al massimo sforzo, supporto tecnico Microsoft potrebbe consigliare la configurazione necessaria per Firewall di Azure, ma non per altri dispositivi non Microsoft.
• Controller di ingresso non Microsoft. Per controller come nginx, kong o traefik, questo include problemi di funzionalità che si verificano dopo operazioni specifiche di AKS, ad esempio un controller Ingress che smette di funzionare dopo un aggiornamento della versione di Kubernetes, il che potrebbe dipendere da incompatibilità tra la versione del controller Ingress e la nuova versione di Kubernetes. Per un'opzione completamente supportata, prendere in considerazione un'opzione controller di ingresso gestita da Microsoft.
• Script personalizzati di DaemonSet. Anche se l'uso DaemonSet di è l'approccio consigliato per ottimizzare, modificare o installare software non Microsoft nei nodi dell'agente quando i parametri del file di configurazione non sono sufficienti, supporto tecnico Microsoft non è in grado di risolvere i problemi derivanti dagli script personalizzati a causa della loro natura personalizzata.
• Assistenza in standby e proattiva. supporto tecnico Microsoft fornisce supporto reattivo per risolvere i problemi attivi. Il supporto di standby o proattivo per eliminare i rischi operativi, aumentare la disponibilità e ottimizzare le prestazioni non è coperto. I clienti idonei possono contattare il team responsabile dell'account per richiedere la candidatura al servizio Gestione eventi di Azure, un servizio a pagamento che include una valutazione proattiva dei rischi della soluzione e la copertura nel corso dell'evento.
• CVE vecchie di meno di 30 giorni. Se utilizzi il VHD aggiornato, non dovresti avere CVE nelle immagini del contenitore con una correzione del fornitore disponibile da oltre 30 giorni. È responsabilità dell’utente aggiornare il VHD, quindi filtrare il report CVE e fornire al Supporto tecnico Microsoft un elenco delle sole CVE per cui è disponibile una correzione del fornitore da oltre 30 giorni. Microsoft quindi funziona internamente per gestire i componenti con una correzione del fornitore rilasciata più di 30 giorni fa. Microsoft fornisce supporto relativo alle CVE solo per i componenti gestiti da Microsoft, come le immagini dei nodi AKS e le immagini di contenitori gestite distribuite durante la creazione del cluster o tramite un componente aggiuntivo gestito. Per altre informazioni, vedere Gestione delle vulnerabilità per Servizio Azure Kubernetes (AKS).
• Esempi di codice personalizzati. supporto tecnico Microsoft può fornire ed esaminare piccoli esempi di codice all'interno di un caso di supporto per illustrare come usare le funzionalità di un prodotto Microsoft, ma non può fornire esempi di codice personalizzati specifici per l'ambiente o l'applicazione.
• Logica di Criteri di Azure personalizzata. supporto tecnico Microsoft può fornire indicazioni generali su come vengono applicate e valutate definizioni di Criteri di Azure personalizzate nel servizio Azure Kubernetes. La risoluzione dettagliata dei problemi della logica dei criteri creata dai clienti (inclusi i criteri basati su Rego), ad esempio il motivo per cui un criterio specifico consente o nega un carico di lavoro, in genere non rientra nell'ambito del supporto.

Limiti di supporto CNI personalizzati

Quando si distribuisce un cluster con bring your own CNI (BYOCNI) usando --network-plugin none, supporto tecnico Microsoft non può essere utile per i problemi correlati a CNI. L'utente è responsabile del ciclo di vita del plug-in CNI ed è necessario richiedere supporto al fornitore del plug-in CNI. Microsoft fornisce ancora supporto per i problemi non correlati a CNI.

Per altre informazioni, vedere Bring Your Own CNI (BYOCNI).

Copertura del supporto del servizio Azure Kubernetes per i nodi dell'agente

Le sezioni seguenti descrivono le responsabilità di Microsoft e dei clienti per i nodi degli agenti AKS.

La tabella seguente riepiloga a colpo d'occhio le responsabilità del nodo dell'agente. Le sezioni che seguono forniscono i dettagli.

Responsabilità di Microsoft per i nodi agente di AKS

Microsoft e tu condividono la responsabilità per i nodi dell'agente Kubernetes.

• L'immagine del sistema operativo di base include aggiunte necessarie, ad esempio gli agenti di monitoraggio e di rete.
• I nodi agente ricevono automaticamente le patch del sistema operativo.
• Il sistema corregge automaticamente i problemi relativi ai componenti del piano di controllo Kubernetes eseguiti nei nodi dell'agente. Questi componenti includono gli elementi seguenti:
  • kube-proxy
  • Tunnel di rete che forniscono percorsi di comunicazione al piano di controllo Kubernetes
  • kubelet
  • containerd

Se un nodo dell'agente non è operativo, Azure Kubernetes Service potrebbe riavviare i singoli componenti o l'intero nodo dell'agente. Queste operazioni di riavvio sono automatizzate e forniscono correzione automatica per i problemi comuni. Per altre informazioni sui meccanismi di correzione automatica, vedere Correzione automatica dei nodi.

Responsabilità del cliente per i nodi agente del servizio Azure Kubernetes

Microsoft fornisce patch e nuove immagini per i nodi immagine ogni settimana. Per mantenere aggiornati i componenti del sistema operativo e del runtime del nodo agente, è necessario applicare regolarmente queste patch e gli aggiornamenti manualmente o automaticamente. Microsoft non supporta le immagini dei nodi precedenti a 90 giorni. Per altre informazioni, vedere:

• Aggiornare manualmente le immagini dei nodi AKS.
• Aggiornare automaticamente le immagini dei nodi AKS.

Analogamente, il servizio Azure Kubernetes rilascia regolarmente nuove patch Kubernetes e versioni secondarie. Questi aggiornamenti possono contenere miglioramenti della sicurezza o delle funzionalità per Kubernetes. L'utente è responsabile di mantenere la versione Kubernetes dei cluster aggiornata e conforme ai criteri delle versioni del supporto di Kubernetes del servizio Azure Kubernetes.

Personalizzazione utente dei nodi dell'agente

Il servizio Azure Kubernetes gestisce il ciclo di vita e le operazioni dei nodi agente per conto dell'utente e la modifica delle risorse IaaS associate ai nodi dell'agente non è supportata. Un esempio di operazione non supportata è la personalizzazione di un set di scalabilità di macchine virtuali del pool di nodi modificando manualmente le configurazioni nel portale di Azure o dall'API.

Per pacchetti o configurazioni specifiche del carico di lavoro, il servizio Azure Kubernetes consiglia di usare un Kubernetes DaemonSet.

L'uso di contenitori Kubernetes con privilegi init e DaemonSet consente di ottimizzare/modificare o installare software non Microsoft nei nodi agente del cluster. Questo tipo di personalizzazione include, ad esempio, l'integrazione di strumenti di analisi della sicurezza personalizzati o l'aggiornamento delle impostazioni di sysctl.

Anche se questo percorso è consigliato se si applicano i requisiti precedenti, l'ingegneria e il supporto di AKS non possono aiutare a risolvere i problemi o diagnosticare le modifiche che rendono il nodo non disponibile a causa di una distribuzione personalizzata DaemonSet.

Problemi di sicurezza e applicazione di patch

Se viene individuata una falla di sicurezza in uno o più dei componenti gestiti di AKS, il team di AKS applica una patch a tutti i cluster interessati per ridurre il problema. In alternativa, il team del servizio Azure Kubernetes fornisce indicazioni sull'aggiornamento.

Per i nodi dell'agente interessati da un difetto di sicurezza, Microsoft notifica all'utente i dettagli sull'impatto e i passaggi per risolvere o attenuare il problema di sicurezza.

Accesso e gestione dei nodi

Anche se è possibile accedere ai nodi dell'agente e modificarli, non eseguire questa operazione. Le modifiche possono rendere un cluster non supportabile.

Porte di rete, accesso e gruppi di sicurezza di rete

È possibile personalizzare i gruppi di sicurezza di rete (NSG) solo nelle subnet personalizzate. La tabella seguente illustra dove è possibile personalizzare i gruppi di sicurezza di rete:

AKS ha requisiti di uscita verso endpoint specifici. Per controllare l'uscita e garantire la connettività necessaria, vedere Limitare il traffico in uscita. Per l'ingresso, i requisiti si basano sulle applicazioni distribuite nel cluster.

Nodi arrestati, deallocati e non pronti

La tabella seguente riassume cosa accade a un cluster AKS in ogni stato del ciclo di vita e la tempistica associata:

Se non sono necessari i carichi di lavoro del servizio Azure Kubernetes per l'esecuzione continua, arrestare il cluster del servizio Azure Kubernetes, che arresta tutti i pool di nodi e il piano di controllo e riavviarlo quando necessario. La deallocazione manuale dei nodi tramite le API IaaS, il interfaccia della riga di comando di Azure o il portale di Azure non è un modo supportato per arrestare un cluster.

AKS si riserva il diritto di archiviare i piani di controllo configurati in modo non conforme alle linee guida di supporto per 30 giorni o più. AKS mantiene backup dei metadati del cluster etcd e può riallocare il cluster in seguito a qualsiasi operazione PUT che lo riporti in uno stato supportato, ad esempio un aggiornamento o il ridimensionamento ai nodi agente attivi.

Funzionalità alfa e beta di Kubernetes non supportate

AKS supporta funzionalità stabili e beta nel progetto Kubernetes upstream, ma non funzionalità alfa, salvo diversa indicazione nella documentazione. La tabella seguente riepiloga il supporto in base al tipo di funzionalità:

Funzionalità in anteprima o flag di funzionalità

Per le funzionalità con esigenze maggiori in termini di test e feedback degli utenti, Microsoft rilascia le nuove funzionalità in anteprima o contrassegnate da un flag di funzionalità. Queste funzionalità devono essere quindi considerate funzionalità beta o preliminari.

Le funzionalità di anteprima o con flag di funzionalità non sono destinate alla produzione. Le modifiche in corso nelle API e le modifiche a livello di comportamento, correzioni di bug e di altro tipo possono determinare tempi di inattività e instabilità nei cluster.

Le funzionalità nell'anteprima pubblica ricadono nel massimo impegno di fornire assistenza poiché queste funzionalità sono disponibili in anteprima e non sono destinate all'ambiente di produzione. I team di supporto tecnico dell'AKS forniscono supporto solo durante l'orario di ufficio. Per altre informazioni, vedere Azure Domande frequenti sul supporto.

Bug e problemi upstream

Considerata la velocità di sviluppo nel progetto Kubernetes upstream, si verificano invariabilmente alcuni bug, alcuni dei quali non possono essere ovviati o corretti all'interno del sistema Azure Kubernetes. Le correzioni di bug richiedono invece patch di dimensioni maggiori per i progetti upstream, ad esempio Kubernetes, sistemi operativi node o agent e kernel. Per i componenti di proprietà di Microsoft (come il provider di servizi cloud Azure), il personale di AKS e Azure si impegna a risolvere i problemi a monte nella community.

Quando la causa radice di un problema del team di supporto è dovuta a uno o più bug upstream, i team di supporto e di progettazione di AKS si occuperanno di:

• Identificano e associano i bug upstream con eventuali dettagli di supporto per spiegare il motivo per cui il problema interessa il cluster o il carico di lavoro. I clienti ricevono collegamenti ai repository necessari in modo da poter controllare i problemi e vedere quando una nuova versione fornisce correzioni.
• Forniscono possibili soluzioni alternative o di mitigazione. Se il problema può essere mitigato, viene segnalato un problema noto nel repository di AKS. La segnalazione di un problema noto spiega:
  • Il problema, inclusi i collegamenti ai bug upstream.
  • La soluzione alternativa e informazioni dettagliate su un aggiornamento o un'altra persistenza della soluzione.
  • Le tempistiche approssimative per l'inclusione del problema, in base alla frequenza delle versioni upstream.

Contenuti correlati

• Livelli di prezzo di AKS
• Versioni di Kubernetes supportate nel servizio Azure Kubernetes
• Supporto a lungo termine per AKS
• Aggiornare automaticamente un cluster di AKS
• Aggiornare automaticamente le immagini del sistema operativo dei nodi AKS
• Gestione delle vulnerabilità per AKS
• Ripristino automatico del nodo AKS
• Porta il tuo CNI (BYOCNI)