Condividi tramite

Criteri di supporto per il servizio Azure Kubernetes abilitato da Azure Arc

  • Articolo

Si applica a: AKS in Azure locale 22H2, AKS in Windows Server

Questo articolo fornisce informazioni dettagliate sui criteri di supporto tecnico e sulle limitazioni per il servizio Azure Kubernetes abilitato da Arc. L'articolo descrive anche la gestione dei nodi del cluster, i componenti del piano di controllo, i componenti open source di terze parti e la gestione delle patch o della sicurezza.

Versioni e aggiornamenti del servizio

  • Microsoft offre una finestra di supporto di 1 anno per ogni versione secondaria di Kubernetes, a partire dalla data di rilascio iniziale. Durante questo periodo, Il servizio Azure Kubernetes Arc rilascia le versioni secondarie o patch successive per garantire il supporto continuo.
  • Un cluster Kubernetes che opera su una versione secondaria deprecata deve essere aggiornato a una versione supportata per essere idoneo per il supporto.
  • Una volta deprecata una versione secondaria, tutti i cluster ancora in esecuzione in questa versione continueranno a funzionare. È comunque possibile eseguire operazioni come l'aumento o la riduzione delle prestazioni, ma Arc del servizio Azure Kubernetes visualizza un avviso durante le operazioni del cluster.
  • Una volta deprecata una versione secondaria, viene rimossa dai server Microsoft. A questo punto, i cluster Kubernetes che usano questa versione non sono in grado di aggiornare Kubernetes o versioni del sistema operativo e devono essere aggiornati alla versione più recente. In alcuni casi, questo aggiornamento può anche significare una ri-distribuzione completa se il sistema non è in uno stato integro.

Per informazioni sulla versione, vedere le note sulla versione di Arc del servizio Azure Kubernetes. Per informazioni sulle funzionalità in anteprima, vedere Funzionalità di anteprima di Azure Kubernetes Arc.

Funzionalità gestite in Azure Kubernetes Arc

Gli utenti di Arc del servizio Azure Kubernetes hanno opzioni di personalizzazione e distribuzione limitate. Non è tuttavia necessario preoccuparsi o gestire direttamente il piano di controllo e l'installazione del cluster Kubernetes. I componenti cloud IaaS (Infrastructure as a Service) di base, ad esempio componenti di calcolo o di rete, consentono di accedere a controlli di basso livello e opzioni di personalizzazione.

Al contrario, Arc del servizio Azure Kubernetes offre una distribuzione Kubernetes chiavi in mano che offre il set comune di configurazioni e funzionalità necessarie per il cluster. Con Il servizio Azure Kubernetes Arc si ottiene un piano di controllo parzialmente gestito. Il piano di controllo contiene tutti i componenti e i servizi necessari per operare e fornire cluster Kubernetes agli utenti finali. Microsoft gestisce tutti i componenti kubernetes.

Microsoft gestisce i componenti seguenti tramite il cluster di gestione e le immagini di base delle macchine virtuali associate:

  • kubelet o server API Kubernetes.
  • etcd o un archivio chiave-valore compatibile, fornendo qualità del servizio (QoS), scalabilità e runtime.
  • Servizi DNS (ad esempio, kube-dns o CoreDNS).
  • Proxy o rete Kubernetes.
  • Qualsiasi altro componente aggiuntivo o di sistema in esecuzione nello spazio dei kube-system nomi .

Azure Kubernetes Arc non è una soluzione PaaS (Platform-as-a-Service). Alcuni componenti, ad esempio cluster del carico di lavoro, piano di controllo e nodi di lavoro, hanno la responsabilità condivisa. Gli utenti devono aiutare a gestire il cluster Kubernetes. L'input dell'utente è necessario, ad esempio, per applicare una patch di sicurezza del sistema operativo o un aggiornamento a una versione più recente di Kubernetes.

I servizi vengono gestiti nel senso che Microsoft e il team del servizio Azure Kubernetes forniscono gli strumenti che distribuiscono il cluster di gestione, il piano di controllo e i nodi agente per i cluster del carico di lavoro. Non è possibile modificare questi componenti gestiti. Microsoft limita gli interventi di personalizzazione per garantire un'esperienza d'uso coerente e scalabile. Per una soluzione completamente personalizzabile nel cloud, vedere il motore del servizio Azure Kubernetes.

Criteri di versione supportati

Le versioni di Kubernetes in AKS Arc seguono i criteri di versione di Kubernetes.

Azure Kubernetes Arc non garantisce alcun runtime (o altro) per i cluster all'esterno dell'elenco delle versioni supportate. "Al di fuori del supporto" significa che:

  • Il cluster opera su una versione secondaria deprecata. La versione in esecuzione non rientra nell'elenco delle versioni supportate.
  • Quando si richiede supporto, viene richiesto di aggiornare il cluster a una versione supportata.

Per informazioni sulle versioni di Kubernetes supportate, vedere Versioni di Kubernetes supportate.

Il servizio Azure Kubernetes Arc segue gli intervalli di tempo di supporto della versione della piattaforma per tali prodotti. Ovvero, Arc del servizio Azure Kubernetes non è supportato nelle versioni non supportate di tali prodotti. Per altre informazioni, vedere i criteri di supporto:

Responsabilità condivisa

Quando viene creato un cluster, si definiscono i nodi dell'agente Kubernetes creati da Azure Kubernetes Arc. Su questi nodi vengono eseguiti i carichi di lavoro.

Poiché i nodi dell'agente eseguono codice privato e archiviano dati sensibili, supporto tecnico Microsoft ha accesso limitato. supporto tecnico Microsoft non è possibile accedere per eseguire i comandi oppure visualizzare i log per questi nodi senza l'autorizzazione o l'assistenza rapida. Qualsiasi modifica diretta dei nodi dell'agente tramite una delle API IaaS rende il cluster non supportabile. Tutte le modifiche apportate ai nodi dell'agente devono essere eseguite usando meccanismi nativi di Kubernetes, Daemon Setsad esempio .

Analogamente, anche se è possibile aggiungere metadati, ad esempio tag ed etichette, al cluster e ai nodi, modificando uno dei metadati creati dal sistema, il cluster non è supportato.

Copertura del supporto di Azure Kubernetes Arc

Microsoft offre supporto tecnico per le funzionalità e i componenti seguenti:

  • Connettività a tutti i componenti di Kubernetes forniti e supportati dal servizio Kubernetes, tra cui il server API.
  • Servizi del piano di controllo Kubernetes(ad esempio, piano di controllo Kubernetes, server API, etcd e coreDNS).
  • Archivio dati etcd.
  • Integrazione con Azure Arc e il servizio fatturazione di Azure.
  • Domande o problemi relativi alla personalizzazione dei componenti del piano di controllo, tra cui il server API Kubernetes, etcd e coreDNS.
  • Problemi relativi alla rete, all'accesso alla rete e alle funzionalità. I problemi possono includere risoluzione DNS, perdita di pacchetti e routing. Microsoft supporta vari scenari di rete:
    • Supporto di installazione di base per Flannel e Calico CNI. Queste CNI sono guidate dalla community e supportate. supporto tecnico Microsoft fornisce solo il supporto di installazione e configurazione di base.
    • Connettività ad altri servizi e applicazioni di Azure.
    • Controller in ingresso e configurazione del servizio di bilanciamento del carico o in ingresso.
    • Prestazioni e latenza di rete.

Nota

Tutte le azioni del cluster eseguite dai team di supporto di Microsoft AKS Arc vengono effettuate con il consenso e l'assistenza degli utenti. supporto tecnico Microsoft non accede al cluster a meno che non si configuri l'accesso per il tecnico del supporto.

Microsoft non fornisce supporto tecnico per le aree 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

    supporto tecnico Microsoft può consigliare funzionalità, personalizzazione e ottimizzazione del cluster in AKS Arc, ad esempio problemi e procedure delle operazioni kubernetes.

  • Progetti open source di terze parti non forniti come parte del piano di controllo Kubernetes o distribuiti quando i cluster vengono creati in AKS Arc. 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. Se lo strumento open source di terze parti si integra con Kubernetes o altri bug specifici del servizio Azure Kubernetes, 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 di Azure Kubernetes Arc.

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

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

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

  • L'immagine del sistema operativo di base richiede aggiunte, ad esempio il monitoraggio e gli agenti 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 dell'agente vengono corretti automaticamente durante il ciclo di aggiornamento o quando si ridistribuisce un nodo agente. Questi componenti includono:
    • kube-proxy
    • Tunnel di rete che forniscono percorsi di comunicazione ai componenti master Kubernetes:
      • kubelet
      • Moby oppure ContainerD

Nota

Se un nodo dell'agente non è operativo, Arc del servizio Azure Kubernetes potrebbe riavviare singoli componenti o l'intero nodo dell'agente. Queste operazioni di riavvio automatizzato forniscono correzione automatica per i problemi comuni.

Responsabilità dei clienti per i nodi dell'agente arc del servizio Azure Kubernetes

Microsoft fornisce patch e nuove immagini per i nodi immagine ogni mese, 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 pianificazione regolare dell'aggiornamento o automatizzare l'applicazione di patch.

Analogamente, AKS Arc 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 aggiornata la versione kubernetes del cluster in base ai criteri delle versioni supportate del servizio Azure Kubernetes.

Personalizzazione utente dei nodi dell'agente

Nota

I nodi dell'agente Arc del servizio Azure Kubernetes vengono visualizzati in Hyper-V come normali risorse di macchine virtuali. Queste macchine virtuali vengono distribuite con un'immagine del sistema operativo personalizzata e i componenti Kubernetes supportati e gestiti. Non è possibile modificare l'immagine del sistema operativo di base o apportare personalizzazioni dirette a questi nodi usando le API o le risorse Hyper-V. Le modifiche personalizzate non eseguite tramite l'API AKS-HCI non vengono mantenute tramite un aggiornamento, una scalabilità, un aggiornamento o un riavvio e possono eseguire il rendering del cluster non supportato. Evitare di eseguire modifiche ai nodi dell'agente, a meno che il supporto tecnico Microsoft non indirizzi l'utente a apportare modifiche.

Azure Kubernetes Arc gestisce il ciclo di vita e le operazioni delle immagini dei nodi dell'agente per conto dell'utente. La modifica delle risorse associate ai nodi dell'agente non è supportata. Ad esempio, la personalizzazione delle impostazioni di rete di una macchina virtuale modificando manualmente le configurazioni tramite l'API o gli strumenti Hyper-V non è supportata.

Per configurazioni o pacchetti specifici del carico di lavoro, è consigliabile usare i set di daemon Kubernetes.

Quando si usano contenitori con privilegi daemon sets e init kubernetes, è possibile ottimizzare/modificare o installare software di terze parti nei nodi dell'agente del cluster. Ad esempio, è possibile aggiungere impostazioni di aggiornamento o sysctl software di analisi della sicurezza personalizzate. Anche se questo percorso è consigliato se si applicano i requisiti precedenti, la progettazione e il supporto di Arc del servizio Azure Kubernetes non possono aiutare a risolvere i problemi o a 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 di AKS Arc, il team di Azure Kubernetes Arc applica patch a tutte le immagini del sistema operativo interessate per attenuare il problema e il team fornisce indicazioni per l'aggiornamento degli utenti.

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. In genere, i passaggi includono un aggiornamento dell'immagine del nodo o un aggiornamento della patch del cluster.

Accesso e gestione dei nodi

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

Porte di rete, pool IP e accesso

È possibile personalizzare solo le impostazioni di rete usando le subnet definite dall'arc del servizio Azure Kubernetes. Non è possibile personalizzare le impostazioni di rete a livello di scheda di interfaccia di rete dei nodi dell'agente. Azure Kubernetes Arc prevede requisiti in uscita per endpoint specifici, per controllare l'uscita e garantire la connettività necessaria. Per altre informazioni, vedere Requisiti di sistema di Azure Kubernetes Arc.

Cluster arrestati o disconnessi

Come descritto in precedenza, la deallocazione manuale di tutti i nodi del cluster tramite le API Hyper-V, l'interfaccia della riga di comando o MMC esegue il rendering del cluster senza supporto.

I cluster arrestati per più di 90 giorni non possono più essere aggiornati. I piani di controllo per i cluster in questo stato non sono supportati dopo 30 giorni e non possono essere aggiornati alla versione più recente.

Il cluster di gestione in AKS Arc deve essere in grado di connettersi ad Azure tramite il traffico in uscita HTTPS verso endpoint di Azure noti almeno ogni 30 giorni per mantenere le operazioni del giorno 2, ad esempio l'aggiornamento e il ridimensionamento del pool di nodi. Se il cluster di gestione viene disconnesso entro il periodo di 30 giorni, i carichi di lavoro continuano a essere eseguiti e funzionano come previsto fino a quando il cluster di gestione e o azure locale si connettono e si sincronizzano con Azure. Dopo la riconnessa, tutte le operazioni del giorno 2 devono essere ripristinate e continuare come previsto. Per altre informazioni, vedere Requisiti di connettività di Azure locale di Azure. Dopo 30 giorni, Azure Local impedisce la creazione di nuove macchine virtuali.

Se il cluster è in esecuzione in Windows Server 2019 o Windows Server 2022, la piattaforma host sottostante non ha il requisito di connessione ricorrente di 30 giorni.

Nota

L'inizio/fine del periodo di 30 giorni potrebbe essere diverso dal periodo di validità in Servizio Azure Kubernetes Arc e locale di Azure. Arrestare o annullare manualmente l'allocazione di tutti i nodi del cluster tramite le API Hyper-V/INTERFACCIA della riga di comando/MMC per periodi prolungati superiori a 30 giorni e al di fuori delle normali procedure di manutenzione, il cluster non supporta più di 30 giorni.

Sottoscrizione eliminata o sospesa

Se la sottoscrizione di Azure è sospesa o eliminata, i cluster del servizio Azure Kubernetes non sono supportati dopo 60 giorni, a meno che la sottoscrizione non venga ripristinata prima che venga raggiunto il limite di 60 giorni. Si applicano anche tutte le altre limitazioni descritte in precedenza. Dopo l'eliminazione della sottoscrizione, la connessione cluster ad Azure non può essere ripristinata e Azure Local e AKS Arc devono essere ridistribuiti per poter riconnettersi ad Azure.

Funzionalità Di Kubernetes non supportate e di anteprima non supportate

Azure Kubernetes Arc supporta solo funzionalità stabili e beta nel progetto Kubernetes upstream. Se non diversamente documentato, Arc del servizio Azure Kubernetes non supporta alcuna funzionalità di anteprima 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à. Prendere in considerazione queste funzionalità non definitive o beta. 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 ricevono il supporto "migliore", perché queste funzionalità sono in anteprima e non sono destinate all'ambiente di produzione. Queste funzionalità sono supportate dai team di supporto tecnico del servizio Azure Kubernetes Arc solo durante l'orario di ufficio. Per altre informazioni, vedere le domande frequenti sulle supporto tecnico di Azure.

Bug e problemi upstream

Considerata la velocità di sviluppo nel progetto Kubernetes upstream, si verificano invariabilmente alcuni bug, Alcuni di questi bug non possono essere corretti o risolti all'interno del sistema Arc del servizio 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 i provider di API del cluster per Azure locale), il personale del servizio Azure Kubernetes Arc e azure si impegna a risolvere i problemi upstream nella community.

Quando un problema di supporto tecnico è causato da uno o più bug upstream, il supporto di Arc del servizio Azure Kubernetes e i team di progettazione eseguiranno le operazioni seguenti:

  • 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, viene archiviato un problema noto nel repository del servizio Azure Kubernetes nel repository locale di Azure e Windows Server. Il rilascio di problemi noti spiega:
    • Il problema, inclusi i collegamenti ai bug upstream.
    • Soluzione alternativa e dettagli su un aggiornamento o un'altra opzione per la soluzione.
    • Le tempistiche approssimative per l'inclusione del problema, in base alla frequenza delle versioni upstream.

Passaggi successivi