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

  • Articolo

Si applica a: servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes 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 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.
  • Dopo aver deprecato 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.
  • Dopo aver deprecato 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 del servizio Azure Kubernetes Arc. Per informazioni sulle funzionalità in anteprima, vedere Funzionalità di anteprima di Azure Kubernetes Arc.

Funzionalità gestite in AKS Arc

L'utente di Arc del servizio Azure Kubernetes dispone di opzioni di personalizzazione e distribuzione limitate. Tuttavia, non è 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 AKS 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 della macchina virtuale 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 .

AKS Arc non è una soluzione PaaS (Platform-as-a-Service). Alcuni componenti, ad esempio i cluster del carico di lavoro, il piano di controllo e i 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.

Arc del servizio Azure Kubernetes 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.
  • Al momento della richiesta di supporto, viene richiesto di aggiornare il cluster a una versione supportata.

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

Arc del servizio Azure Kubernetes 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 Arc 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 ha accesso limitato. supporto tecnico Microsoft non è possibile accedere per eseguire comandi o visualizzare i log per questi nodi senza l'autorizzazione o l'assistenza. 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 Arc del servizio Azure Kubernetes

Microsoft fornisce 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, ad esempio il server API Kubernetes, etcd e coreDNS.
  • Problemi relativi alla rete, all'accesso alla rete e alle funzionalità. I problemi possono includere la risoluzione DNS, la perdita di pacchetti e il routing. Microsoft supporta vari scenari di rete:
    • Supporto di installazione di base per Flannel e Calico CNI. Queste CNI sono basate sulla 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 nelle 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 di Kubernetes.

  • Progetti open source di terze parti che non vengono 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ò fornire il supporto ottimale per progetti open source di terze parti, ad esempio 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 AKS 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 monitoraggio e agenti 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 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 o ContainerD

Nota

Se un nodo agente non è operativo, Arc del servizio Azure Kubernetes potrebbe riavviare singoli componenti o l'intero nodo dell'agente. Queste operazioni di riavvio automatizzato offrono 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 le applica automaticamente per impostazione predefinita. Per mantenere i componenti del sistema operativo e del runtime del nodo agente con patch, è necessario mantenere una pianificazione di aggiornamento regolare 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. È responsabilità dell'utente mantenere aggiornata la versione kubernetes dei cluster in base ai criteri delle versioni supportate dal servizio Azure Kubernetes.

Personalizzazione utente dei nodi agente

Nota

I nodi dell'agente Arc del servizio Azure Kubernetes vengono visualizzati in Hyper-V come normali risorse della macchina virtuale. 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 eseguire 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, scalabilità, aggiornamento o riavvio e possono eseguire il rendering del cluster non supportato. Evitare di eseguire modifiche ai nodi dell'agente, a meno che non supporto tecnico Microsoft indirizza l'utente a apportare modifiche.

AKS 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 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 sysctl o software di analisi della sicurezza personalizzate. Sebbene questo percorso sia consigliato se si applicano i requisiti precedenti, la progettazione e il supporto di Arc del servizio Azure Kubernetes non possono essere utili per la risoluzione dei problemi o la diagnosi delle 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 Arc del servizio Azure Kubernetes 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 una notifica con informazioni dettagliate sull'impatto e sui passaggi per risolvere o attenuare il problema di sicurezza. In genere, i passaggi includono l'aggiornamento di un'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 le impostazioni di rete solo usando le subnet definite dall'arco del servizio Azure Kubernetes. Non è possibile personalizzare le impostazioni di rete a livello di scheda di interfaccia di rete dei nodi dell'agente. Arc del servizio Azure Kubernetes ha 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 indicato in precedenza, la de-allocazione 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 giornaliere 2, ad esempio il ridimensionamento del pool di nodi e l'aggiornamento. 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 Azure Stack HCI 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 Azure Stack HCI Azure connectivity requirements (Requisiti di connettività di Azure Per Azure Stack HCI ). Dopo 30 giorni, Azure Stack HCI 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 AKS Arc e Azure Stack HCI. Arresto o de-allocazione manuale 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 il cluster.

Sottoscrizione eliminata o sospesa

Se la sottoscrizione di Azure viene sospesa o eliminata, i cluster del servizio Azure Kubernetes non sono supportati dopo 60 giorni, a meno che la sottoscrizione non venga ripristinata prima del raggiungimento del 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 Stack HCI e AKS Arc devono essere ridistribuiti per poter riconnettersi ad Azure.

Funzionalità di anteprima e versione beta di Kubernetes non supportate

Arc del servizio Azure Kubernetes 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 sforzo", perché queste funzionalità sono in anteprima e non sono destinate all'ambiente di produzione. Queste funzionalità sono supportate solo dai team di supporto tecnico di Arc del servizio Azure Kubernetes durante l'orario di ufficio. Per altre informazioni, vedere le domande frequenti sulla 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 di bug richiedono invece patch più grandi per i progetti upstream, ad esempio Kubernetes, nodi o sistemi operativi agente e kernel. Per i componenti di proprietà di Microsoft , ad esempio i provider di API del cluster per Azure Stack HCI, 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 e i team di progettazione del servizio Azure Kubernetes 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.
  • Fornire possibili soluzioni alternative o mitigazioni. Se il problema può essere risolto, un problema noto viene archiviato nel servizio Azure Kubernetes nel repository Azure Stack HCI e Windows Server. Nella segnalazione di un problema noto vengono spiegati gli elementi seguenti:
    • 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