Criteri di supporto per servizio Azure Kubernetes

Questo articolo descrive i criteri di supporto tecnico e le limitazioni per Servizio Azure Kubernetes (AKS). L'articolo descrive anche la gestione dei nodi di lavoro, i componenti di un piano di controllo gestito, i componenti open source di terze parti e la gestione della sicurezza o delle patch.

Versioni e aggiornamenti del servizio

• Per informazioni sulla versione, vedere Note sulla versione di AKS.
• 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, consentono di accedere 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. Gli utenti del servizio Azure Kubernetes hanno opzioni di personalizzazione e distribuzione limitate. In cambio, non è necessario preoccuparsi o gestire 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:

• Server API di Kubelet o di Kubernetes.
• etcd o un archivio chiave-valore compatibile, che fornisce qualità del servizio (QoS), scalabilità e runtime.
• Servizi DNS come kube-dns o CoreDNS.
• Proxy o rete Kubernetes, tranne quando viene usato 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 del servizio AKS distribuiscono, gestiscono ed è responsabile 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 viene creato un cluster, si definiscono i nodi dell'agente Kubernetes creati dal servizio Azure Kubernetes. Su questi nodi vengono eseguiti i carichi di lavoro.

Poiché i nodi dell'agente eseguono codice privato e archiviano dati sensibili, supporto tecnico Microsoft possono accedervi solo in modo limitato. Il supporto Microsoft non può accedere, eseguire comandi sui, o visualizzare i log per questi nodi senza la tua espressa autorizzazione o assistenza.

Qualsiasi modifica apportata direttamente ai nodi dell'agente usando una delle API IaaS rende il cluster non supportabile. Qualsiasi modifica applicata ai nodi dell'agente deve essere eseguita usando meccanismi nativi di Kubernetes come DaemonSet.

Analogamente, anche se è possibile aggiungere qualsiasi metadato al cluster e ai nodi, come tag ed etichette, la modifica di uno qualsiasi dei metadati creati dal sistema rende il cluster non supportato.

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:

• Connettività a tutti i componenti Kubernetes forniti dal servizio Kubernetes e supportati, ad esempio il server API.
• Gestione, tempo di attività, QoS e operazioni dei servizi del piano di controllo di Kubernetes, come piano di controllo di Kubernetes, server API, etcd e coreDNS.
• etcd archivio di dati. Il supporto include backup automatizzati e trasparenti di tutti i etcd dati ogni 30 minuti per la pianificazione di emergenza e il ripristino dello stato del cluster. Questi backup non sono direttamente disponibili per l'utente o per altri utenti. garantiscono tuttavia l'affidabilità e la coerenza dei dati. Il ripristino o il rollback su richiesta non sono supportati come funzionalità.
• Qualsiasi punto di integrazione nel driver del provider di servizi cloud Azure per Kubernetes. Queste includono integrazioni in altri servizi di Azure, ad esempio servizi di bilanciamento del carico, volumi permanenti o reti (Kubernetes e CNI Azure, tranne quando è in uso BYOCNI).
• Domande o problemi relativi alla personalizzazione dei componenti del piano di controllo, ad esempio il server API Kubernetes, etcde coreDNS.
• Problemi relativi alla rete, ad esempio Azure CNI, kubenet o altri problemi di accesso e funzionalità di rete, tranne quando è in uso BYOCNI. I problemi possono includere, ad esempio, la risoluzione DNS, la perdita di pacchetti, il routing e così via. Microsoft supporta diversi scenari di rete:
  • Kubenet e Azure CNI utilizzando VNET gestite o con subnet personalizzate (porta la tua).
  • Connettività ad altri servizi e applicazioni Azure.
  • Controller di ingresso gestiti da Microsoft o configurazioni del bilanciamento del carico.
  • Prestazioni e latenza di rete.
  • Microsoft gestisce i componenti e le funzionalità delle politiche di rete.

Tutte le azioni del cluster eseguite da Microsoft/AKS vengono eseguite con il tuo consenso e utilizzando un ruolo Kubernetes integrato aks-service e l'associazione di ruoli integrata 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 né creare ruoli o associazioni di ruoli o 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:

• Domande su come usare Kubernetes. Ad esempio, 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 open source di terze parti.

  supporto tecnico Microsoft può consigliare su funzionalità, personalizzazione e ottimizzazione del cluster del servizio Microsoft Azure Kubernetes (ad esempio, problemi e procedure delle operazioni Kubernetes).

• Progetti open source di terze parti che non forniti nell'ambito del piano di controllo Kubernetes o distribuiti con cluster del servizio Azure Kubernetes. Questi progetti possono includere Istio, Helm, Envoy o altri.

  Microsoft può fornire supporto ottimale per progetti open source di terze parti come Helm. Se lo strumento open-source di terze parti si integra con il provider di servizi cloud Azure Kubernetes o presenta bug specifici di AKS, Microsoft supporta esempi e applicazioni provenienti dalla documentazione di Microsoft.

• Software di terze parti con codice sorgente chiuso. Questo software può includere strumenti di analisi della sicurezza e software o dispositivi di connessione in rete.

• Configurazione o risoluzione dei problemi relativi ai codici o comportamenti specifici di applicazioni o strumenti di terze parti in esecuzione nel cluster del servizio Azure Kubernetes. Sono inclusi i problemi di distribuzione delle applicazioni non correlati alla piattaforma del servizio Azure Kubernetes.

• Rilascio, rinnovo o gestione di certificati per le applicazioni in esecuzione nel servizio Azure Kubernetes.

• Personalizzazioni di rete diverse da quelle elencate nella documentazione AKS. Ad esempio, supporto tecnico Microsoft non è in grado di configurare dispositivi o appliance virtuali destinati a fornire traffico in uscita per il cluster del servizio Azure Kubernetes, ad esempio 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 di terze parti.

• Plug-in CNI personalizzati o di terze parti usati in modalità BYOCNI.

• Configurazione o risoluzione dei problemi relativi ai criteri di rete non gestiti da Microsoft. Anche se l'uso dei criteri di rete è supportato, supporto tecnico Microsoft non può analizzare i problemi derivanti dalle configurazioni dei criteri di rete personalizzate.

• Configurazione o risoluzione dei problemi relativi ai controller in ingresso non gestiti da Microsoft, ad esempio nginx, kong, traefik e così via. Ciò include la risoluzione dei problemi di funzionalità che si verificano dopo le operazioni specifiche di AKS, come un controller in ingresso che smette di funzionare dopo un aggiornamento della versione di Kubernetes. Questi problemi possono derivare da incompatibilità tra la versione del controller in ingresso e la nuova versione di Kubernetes. Per un'opzione completamente supportata, è consigliabile usare un'opzione di controller di ingresso gestita da Microsoft.

• Configurazione o risoluzione dei problemi DaemonSet (inclusi gli script) usati per personalizzare le configurazioni dei nodi. Anche se l'uso di DaemonSet è l'approccio consigliato per ottimizzare, modificare o installare software di terze parti nei nodi dell'agente del cluster quando parametri di file di configurazione non sono sufficienti, supporto tecnico Microsoft non è in grado di risolvere i problemi derivanti dagli script personalizzati usati in DaemonSet a causa della loro natura personalizzata.

• Scenari di supporto e proattivi. supporto tecnico Microsoft fornisce supporto reattivo per aiutare a risolvere i problemi attivi in modo tempestivo e professionale. Tuttavia, il supporto in standby o proattivo per eliminare i rischi operativi, aumentare la disponibilità e ottimizzare le prestazioni non è coperto. I clienti idonei possono contattare il team dell'account per essere nominati per il Servizio Gestione Eventi Azure. Si tratta di un servizio a pagamento fornito da Microsoft tecnici di supporto che includono una valutazione proattiva dei rischi della soluzione e una copertura durante l'evento.

• Vulnerabilità/CVE con una correzione del fornitore inferiore a 30 giorni. Finché è in esecuzione il disco rigido virtuale aggiornato, non eseguire vulnerabilità delle immagini dei contenitori/CVE con una correzione del fornitore risalente a più di 30 giorni prima. È responsabilità del cliente aggiornare il VHD e fornire elenchi filtrati al supporto Microsoft. Dopo aver aggiornato il disco rigido virtuale (VHD), è responsabilità del cliente filtrare il report sulle vulnerabilità/CVE e fornire un elenco solo con le vulnerabilità/CVE per le quali esiste una correzione del fornitore da oltre 30 giorni. In tal caso, il supporto Microsoft lavorerà internamente e risolverà i problemi con una patch del fornitore rilasciata più di 30 giorni fa. Inoltre, Microsoft fornisce supporto correlato a vulnerabilità/CVE solo per i componenti gestiti da Microsoft. Ad esempio, immagini del nodo del servizio Azure Kubernetes, immagini del contenitore gestite per applicazioni distribuite durante la creazione del cluster o tramite l'installazione di un componente aggiuntivo gestito. Per ulteriori dettagli sulla gestione delle vulnerabilità per Servizio Azure Kubernetes (AKS), visitare Vulnerability management for Servizio Azure Kubernetes (AKS).

• Esempi di codice o script personalizzati. Anche se supporto tecnico Microsoft può fornire piccoli esempi di codice e revisioni di esempi di codice di piccole dimensioni all'interno di un caso di supporto per illustrare come usare le funzionalità di un prodotto Microsoft, supporto tecnico Microsoft non può fornire esempi di codice personalizzati specifici del tuo ambiente o applicazione.

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 dell'agente AKS.

Le responsabilità di Microsoft per i nodi agenti del servizio Azure Kubernetes (AKS)

Microsoft e voi condividete la responsabilità per i nodi dell'agente Kubernetes in cui:

• 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.
• I problemi relativi ai componenti del piano di controllo Kubernetes eseguiti nei nodi agente vengono corretti automaticamente. Questi componenti includono gli elementi seguenti:
  • Kube-proxy
  • Tunnel di rete che forniscono percorsi di comunicazione ai componenti master di 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. 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 dei contenitori Kubernetes privilegiati DaemonSet e init consente di modificare o installare software di terze parti nei nodi agenti 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

Sebbene sia possibile accedere e modificare i nodi agente, questa operazione è sconsigliata perché le modifiche possono rendere un cluster non supportabile.

Porte di rete, accesso e gruppi di sicurezza di rete

È possibile personalizzare solo i gruppi di sicurezza di rete nelle subnet personalizzate. Non è possibile personalizzare i gruppi di sicurezza di rete nelle subnet gestite o a livello di scheda di interfaccia di rete dei nodi dell'agente. Il servizio Azure Kubernetes ha requisiti in uscita per endpoint specifici, per controllare l'uscita e garantire la connettività necessaria, vedere Limitare il traffico in uscita. Per l'ingresso, i requisiti sono basati sulle applicazioni distribuite nel cluster.

Nodi arrestati, deallocati e non pronti

Se i carichi di lavoro del servizio Azure Kubernetes non sono necessari per l'esecuzione continua, è possibile arrestare il cluster del servizio Azure Kubernetes, che arresta tutti i pool di nodi e il piano di controllo. È possibile avviarlo di nuovo quando necessario. Quando si arresta un cluster usando il comando az aks stop, lo stato del cluster viene mantenuto per un massimo di 12 mesi. Dopo 12 mesi, lo stato del cluster e tutte le relative risorse vengono eliminati.

La deallocazione manuale di tutti i nodi del cluster dalle API IaaS, dalla interfaccia della riga di comando di Azure o dal portale Azure non è supportata per arrestare un cluster AKS o un pool di nodi. Il cluster verrà considerato non supportato e arrestato dal servizio Azure Kubernetes dopo 30 giorni. I cluster sono quindi soggetti agli stessi criteri di conservazione di 12 mesi di un cluster arrestato correttamente.

I cluster con zero nodi Pronti (o tutti non pronti) e zero macchine virtuali in esecuzione verranno arrestati dopo 30 giorni.

Il servizio Azure Kubernetes si riserva il diritto di archiviare i piani di controllo che non sono stati configurati nel rispetto delle linee guida del servizio di supporto per un periodo pari o superiore a 30 giorni. Il servizio Azure Kubernetes (AKS) mantiene i backup dei metadati del cluster etcd e può facilmente riallocare il cluster. Questa riallocazione viene avviata da qualsiasi operazione PUT che ripristini lo stato supportato del cluster, ad esempio l'aggiornamento o il ridimensionamento di nodi agente attivi.

Tutti i cluster in una sottoscrizione sospesa verranno arrestati immediatamente ed eliminati dopo 90 giorni. Tutti i cluster in una sottoscrizione eliminata verranno eliminati immediatamente.

Funzionalità alfa e beta di Kubernetes non supportate

Il servizio Azure Kubernetes supporta solo funzionalità stabili e beta all'interno del progetto Kubernetes upstream. Se non diversamente documentato, AKS non supporta alcuna funzionalità alfa disponibile nel progetto Kubernetes upstream.

Funzionalità in anteprima o flag di funzionalità

Per funzionalità e funzionalità che richiedono test estesi e feedback degli utenti, Microsoft rilascia nuove funzionalità o funzionalità di anteprima dietro 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 proprietari di Microsoft (ad esempio il provider di servizi cloud Azure), il personale di AKS e di Azure si impegna a risolvere i problemi nella comunità di origine.

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 risolto, viene archiviato 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.