Criteri di supporto del servizio Azure Kubernetes

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

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 del servizio Azure Kubernetes.

Funzionalità gestite nel servizio Azure Kubernetes

I componenti cloud IaaS (Infrastruttura distribuita come servizio) di base, ad esempio componenti di calcolo o di rete, consentono di accedere a controlli di basso livello e opzioni di personalizzazione. Al contrario, il servizio Azure Kubernetes offre una distribuzione Kubernetes chiavi in mano che offre un set 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 gestisce e gestisce tutti i componenti kubernetes.

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

• Server API Kubernetes o Kubelet
• ETCD o un archivio chiave-valore compatibile, che fornisce Qualità del servizio (QoS), scalabilità e runtime
• Servizi DNS (ad esempio, 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.

Il servizio Azure Kubernetes non è una soluzione PaaS (Platform-as-a-Service). Alcuni componenti, ad esempio i nodi dell'agente, hanno la responsabilità condivisa, in cui è necessario gestire il cluster del servizio Azure Kubernetes. L'input dell'utente è necessario, ad esempio, per applicare una patch di sicurezza del sistema operativo del nodo agente.

I servizi vengono gestiti nel senso che Microsoft e il team del servizio Azure Kubernetes distribuiscono i servizi e ne sono responsabili in termini di funzionamento e disponibilità. Ai clienti non è consentito modificare questi componenti gestiti. Microsoft limita gli interventi di personalizzazione per garantire un'esperienza d'uso coerente e scalabile.

Responsabilità condivisa

Quando viene creato un cluster, si definiscono i nodi dell'agente Kubernetes creati dal servizio Azure Kubernetes. I carichi di lavoro vengono eseguiti in questi nodi.

Poiché i nodi dell'agente eseguono codice privato e archiviano dati sensibili, supporto tecnico Microsoft possono accedervi solo in modo limitato. supporto tecnico Microsoft non è possibile accedere, eseguire comandi in o visualizzare i log per questi nodi senza l'autorizzazione o l'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 kubernetes, Daemon Setsad esempio .

Analogamente, anche se è possibile aggiungere metadati al cluster e ai nodi, ad esempio tag ed etichette, la modifica di uno dei metadati creati dal sistema esegue il rendering del cluster non supportato.

Copertura del supporto per il servizio Azure Kubernetes

Microsoft fornisce supporto tecnico per gli esempi seguenti:

• Connettività a tutti i componenti di Kubernetes forniti e supportati dal servizio Kubernetes, tra cui il server API.
• Gestione, tempo di attività, QoS e operazioni dei servizi del piano di controllo Kubernetes (ad esempio, piano di controllo Kubernetes, server API, etcd e coreDNS).
• Archivio dati etcd. Il supporto include backup trasparenti e automatizzati di tutti i dati etcd 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 rollback o il ripristino su richiesta non è supportato come funzionalità.
• Eventuali punti di integrazione nel driver del provider di servizi cloud di Azure per Kubernetes. Queste includono integrazioni in altri servizi di Azure, ad esempio servizi di bilanciamento del carico, volumi permanenti o reti (Kubernetes e Azure CNI, tranne quando BYOCNI è in uso).
• Domande o problemi relativi alla personalizzazione dei componenti del piano di controllo, ad esempio il server API Kubernetes, etcd e coreDNS.
• Problemi relativi alla rete, ad esempio Azure CNI, kubenet o altri problemi di accesso e funzionalità di rete, tranne quando BYOCNI è in uso. 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 usando reti virtuali gestite o con subnet personalizzate (bring your own).
  • Connettività ad altri servizi e applicazioni di Azure
  • Controller di ingresso e configurazioni di ingresso o del bilanciamento del carico
  • Prestazioni e latenza di rete
  • Criteri di rete

Nota

Tutte le azioni del cluster eseguite da Microsoft/servizio Azure Kubernetes vengono eseguite con il consenso con un ruolo aks-service Kubernetes predefinito e un'associazione aks-service-rolebindingdi ruoli predefinita. 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).

Microsoft non fornisce supporto tecnico per gli scenari seguenti:

• Domande su come usare Kubernetes. Il personale del supporto tecnico Microsoft, ad esempio, non fornisce consigli su come creare controller di ingresso personalizzati, usare i carichi di lavoro delle applicazioni o applicare strumenti o pacchetti software open source o di terze parti.

  Nota

  Il supporto tecnico Microsoft può fornire consigli sul funzionamento, sulla personalizzazione e sull'ottimizzazione del cluster del servizio Azure Kubernetes (ad esempio, su procedure e problemi relativi al funzionamento di 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.

  Nota

  Microsoft può fornire supporto ottimale per progetti open source di terze parti, ad esempio Helm. Quando lo strumento open source di terze parti si integra con il provider di servizi cloud di Azure Kubernetes o altri bug specifici del servizio Kubernetes di Azure, Microsoft supporta esempi e applicazioni della documentazione 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.

• Personalizzazioni di rete diverse da quelle elencate nella documentazione del servizio Azure Kubernetes.

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

• 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 di standby o proattivo per eliminare i rischi operativi, aumentare la disponibilità e ottimizzare le prestazioni non sono coperti. I clienti idonei possono contattare il team dell'account per ottenere la nomina per il servizio Gestione eventi di Azure. Si tratta di un servizio a pagamento offerto dai tecnici del supporto Tecnico Microsoft che include una valutazione proattiva dei rischi e una copertura dei rischi per la soluzione durante l'evento.

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

Responsabilità di Microsoft per i nodi dell'agente del servizio Azure Kubernetes

Microsoft e si condividono la responsabilità per i nodi dell'agente Kubernetes in cui:

• All'immagine di base del sistema operativo sono stati aggiunti elementi obbligatori (ad esempio, agenti di monitoraggio e di connessione di rete).
• I nodi dell'agente ricevono automaticamente le patch del sistema operativo.
• I problemi relativi ai componenti del piano di controllo Kubernetes eseguiti nei nodi dell'agente vengono corretti automaticamente. Questi componenti includono quanto segue:
  • Kube-proxy
  • Tunnel di rete che forniscono percorsi di comunicazione ai componenti master di Kubernetes
  • Kubelet
  • containerd

Nota

Se un nodo dell'agente non è operativo, il servizio Azure Kubernetes potrebbe riavviare 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à dei clienti per i nodi dell'agente del servizio Azure Kubernetes

Microsoft fornisce patch e nuove immagini per i nodi immagine ogni settimana, ma non li applica automaticamente per impostazione predefinita. Per mantenere il sistema operativo del nodo agente e i componenti di runtime con patch, è necessario mantenere una normale pianificazione dell'aggiornamento delle immagini del nodo o automatizzarla.

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. È responsabilità dell'utente mantenere aggiornata la versione kubernetes dei cluster e in base ai criteri di versione del supporto kubernetes del servizio Azure Kubernetes.

Personalizzazione utente dei nodi dell'agente

Nota

I nodi dell'agente del servizio Azure Kubernetes vengono visualizzati nella portale di Azure come risorse IaaS di Azure standard. Tuttavia, queste macchine virtuali vengono distribuite in un gruppo di risorse di Azure personalizzato (preceduto da MC_*). Non è possibile modificare l'immagine del sistema operativo di base o apportare personalizzazioni dirette a questi nodi usando le API O le risorse IaaS. Le modifiche personalizzate non eseguite dall'API del servizio Azure Kubernetes non verranno mantenute tramite un aggiornamento, una scalabilità, un aggiornamento o un riavvio. Inoltre, qualsiasi modifica apportata alle estensioni dei nodi come CustomScriptExtension può causare comportamenti imprevisti e deve essere vietata. Evitare di eseguire modifiche ai nodi dell'agente, a meno che non supporto tecnico Microsoft indirizza l'utente a apportare modifiche.

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 configurazioni o pacchetti specifici del carico di lavoro, il servizio Azure Kubernetes consiglia di usare Kubernetes daemon sets.

L'uso dei contenitori Con privilegi daemon sets e init kubernetes consente di ottimizzare/modificare o installare software di terze parti nei nodi dell'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, la progettazione e il supporto del servizio Azure Kubernetes non possono aiutare a risolvere i problemi o diagnosticare le modifiche che rendono il nodo non disponibile a causa di una distribuzione daemon setpersonalizzata.

Problemi di sicurezza e applicazione di patch

Se si rileva un difetto di sicurezza in uno o più componenti gestiti del servizio Azure Kubernetes, il team del servizio Azure Kubernetes applica patch a tutti i cluster interessati per attenuare 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 invia informazioni dettagliate sull'impatto e i passaggi per risolvere o attenuare il problema di sicurezza.

Accesso e gestione dei nodi

Anche se è possibile accedere e modificare i nodi dell'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 non sono necessari i carichi di lavoro del servizio Azure Kubernetes 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 az aks stop comando , 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.

Deallocazione manuale di tutti i nodi del cluster dalle API IaaS, dall'interfaccia della riga di comando di Azure o dall'portale di Azure non è supportata per arrestare un cluster o un pool di nodi del servizio Azure Kubernetes. 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 mantiene inoltre le copie di backup dei metadati etcd del cluster che consentono di riallocare immediatamente il cluster. Questa riallocazione viene avviata da qualsiasi operazione PUT che riporta il cluster al supporto, ad esempio un aggiornamento o una scalabilità ai nodi dell'agente attivo.

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, il servizio Azure Kubernetes 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 rientrano nel supporto ottimale , poiché queste funzionalità sono in anteprima e non sono destinate all'ambiente di produzione. I team di supporto tecnico del servizio Azure Kubernetes forniscono supporto solo durante l'orario di ufficio. Per altre informazioni, vedere Domande frequenti sul supporto tecnico di Azure.

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, i sistemi operativi node o agent e il kernel. Per i componenti di proprietà di Microsoft (ad esempio, il provider di servizi cloud di Azure), il personale di Azure e del servizio Azure Kubernetes si impegna a correggere i problemi upstream che si verificano nell'ambito della community.

Quando la causa radice di un problema di supporto tecnico è dovuta a uno o più bug upstream, il supporto del servizio Azure Kubernetes e i team di progettazione:

• 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 i collegamenti ai repository necessari per poter esaminare i problemi e scoprire in quale versione futura verrà resa disponibile una correzione.

• Fornire possibili soluzioni alternative o mitigazioni. Se il problema può essere risolto, viene archiviato un problema noto nel repository del servizio Azure Kubernetes. Nella segnalazione di un problema noto vengono spiegati gli elementi seguenti:

  • 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.