Condividi tramite

Criteri di supporto del servizio Azure Kubernetes

  • Articolo

Questo articolo descrive le politiche del team supporto tecnico e le limitazioni per Azure Kubernetes Service (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

Funzionalità gestite nel servizio Azure Kubernetes

I componenti cloud IaaS (Infrastructure as a Service) di base, come i componenti di calcolo o di rete, consentono di accedere a controlli di basso livello e a 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 gestisce e gestisce tutti i componenti kubernetes.

Microsoft gestisce e monitorizza i componenti seguenti tramite il riquadro 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). Per alcuni componenti, come i nodi agente, è prevista la responsabilità condivisa, ovvero gli utenti devono contribuire alla gestione del cluster AKS. È necessario l'intervento dell'utente, ad esempio, per applicare una patch di sicurezza del sistema operativo al 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. Su questi nodi vengono eseguiti i carichi di lavoro.

Poiché i nodi agente eseguono codice privato e memorizzano dati sensibili, il supporto tecnico Microsoft può accedervi solo in modo limitato. Il supporto tecnico Microsoft non può accedere, eseguire comandi o visualizzare i registri di questi nodi senza l'esplicita autorizzazione o assistenza dell'utente.

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, ad esempio Daemon Sets.

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 team di supporto per gli elementi 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 di Kubernetes (ad esempio, piano di controllo di 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 Azure come bilanciamento del carico, volumi persistenti o networking (Kubernetes e Azure CNI, tranne quando è in uso BYOCNI).
  • Domande o problemi relativi alla personalizzazione dei componenti del piano di controllo, tra cui il server API Kubernetes, etcd e coreDNS.
  • Problemi di rete, come Azure CNI, kubenet o altri problemi di accesso alla rete e funzionalità, 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 vari 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 intraprese da Microsoft/AKS sono effettuate con il consenso dell'utente nell'ambito di un ruolo Kubernetes integrato aks-service e binding del ruolo predefinito aks-service-rolebinding. 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 team di supporto 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ò offrire il miglior supporto possibile per progetti open source di terze parti, quali 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 AKS.

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

  • Scenari di supporto e proattivi. Il 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.

  • Vulnerabilità/CVE con una correzione del fornitore inferiore a 30 giorni. Se si esegue il disco rigido virtuale aggiornato, non è consigliabile eseguire vulnerabilità/CVE dell'immagine del contenitore con una correzione del fornitore superiore a 30 giorni prima. È responsabilità del cliente aggiornare il disco rigido virtuale e fornire elenchi filtrati al supporto Tecnico Microsoft. Dopo aver aggiornato il disco rigido virtuale, è responsabilità del cliente filtrare le vulnerabilità/report CVEs e fornire un elenco solo con vulnerabilità/CVE con una correzione fornitore superiore a 30 giorni. In tal caso, il supporto Tecnico Microsoft assicurerà di lavorare internamente e risolvere i componenti con una correzione del fornitore rilasciata più di 30 giorni fa. Microsoft fornisce inoltre il supporto correlato a vulnerabilità/CVE solo per i componenti gestiti da Microsoft (ad esempio, immagini dei nodi del servizio Azure Kubernetes, immagini del contenitore gestito per le applicazioni che vengono distribuite durante la creazione del cluster o tramite l'installazione di un componente aggiuntivo gestito). Per altre informazioni sui gestione delle vulnerabilità per il servizio Azure Kubernetes, visitare questa pagina.

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

Responsabilità di Microsoft per i nodi agente di 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 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 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 vengono automatizzate e forniscono una 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, 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 nel portale di Azure come normali risorse IaaS di Azure. Si tratta tuttavia di macchine virtuali distribuite in un gruppo di risorse personalizzato di Azure (caratterizzato dal prefisso 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. Tutte le modifiche personalizzate non eseguite dall'API AKS non persisteranno in caso di aggiornamento, ridimensionamento, aggiornamento o 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 il supporto tecnico Microsoft non indirizzi 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 Kubernetesdaemon 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 personalizzata daemon set.

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 invia informazioni dettagliate 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 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 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, dall'interfaccia della riga di comando di Azure o dal 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 può essere avviata da qualsiasi operazione PUT che ripristina il servizio di supporto 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 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 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 per il supporto 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 dei bug richiedono invece patch più ampie ai progetti upstream (come Kubernetes, i sistemi operativi dei nodi o degli agenti 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 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 i collegamenti ai repository necessari per poter esaminare i problemi e scoprire in quale versione futura verrà resa disponibile una correzione.

  • Forniscono possibili soluzioni alternative o di mitigazione. Se il problema può essere risolto, verrà segnalato 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.