Considerazioni sull'organizzazione delle risorse per il servizio Azure Kubernetes (facoltativo)

La considerazione dell'organizzazione delle risorse è gestita principalmente dalla base della piattaforma, ma ecco alcuni dei modi in cui la base della piattaforma potrebbe influire sull'acceleratore di zona di destinazione del servizio Azure Kubernetes.

La progettazione complessiva delle sottoscrizioni e dei gruppi di risorse, determinata dalle raccomandazioni generiche della zona di destinazione su scala aziendale, avrà un ruolo fondamentale nella modalità di gestione dell'organizzazione delle risorse del servizio Azure Kubernetes. Come descritto in Organizzazione dei gruppi di gestione e delle sottoscrizioni, i gruppi di gestione e le sottoscrizioni vengono usati per assegnare criteri alle risorse sottostanti e le sottoscrizioni costituiscono il limite di gestione per la governance e l'isolamento delle risorse.

Ad esempio, se sono presenti applicazioni pubbliche e private, suddividerle in sottoscrizioni diverse denominate CorpOnline e assegnare criteri diversi a ogni sottoscrizione. Le sottoscrizioni Corp prevedono criteri che impediscono la creazione di IP pubblici. Le sottoscrizioni Online consentono la connettività Internet. Per altre informazioni sui criteri applicati ai diversi livelli in una progettazione della zona di destinazione su scala aziendale, inclusi i criteri specifici del servizio Azure Kubernetes, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione su scala aziendale.

Considerazioni relative alla progettazione

• Decidere chi gestirà gli host contenitore:

  • Se gli host vengono gestiti in modo centralizzato, è possibile ridurre il numero di istanze della zona di destinazione e richiedere agli sviluppatori di seguire processi definiti per la distribuzione degli host e l'uso di dashboard e avvisi condivisi per le operazioni a livello di carico di lavoro.

  • Se sono i team del carico di lavoro a gestire gli host, saranno necessarie più istanze della zona di destinazione per segmentare gli ambienti host e consentire ai team del carico di lavoro di controllare le distribuzioni.

  • In entrambi i casi, questa considerazione viene estesa alle risorse adiacenti e correlate, ad esempio web application firewall, insiemi di credenziali delle chiavi, agenti di compilazione della pipeline e potenzialmente jump box.

• Scegliere un modello di tenancy per i cluster:

  • Tenant singolo gestito dal carico di lavoro: un singolo host cluster che supporta un singolo carico di lavoro richiederà probabilmente una zona di destinazione dedicata per consentire la segmentazione e il controllo del team del carico di lavoro.

  • Host multi-tenant gestiti centralmente: quando gli host vengono gestiti centralmente, l'efficienza operativa deriva dal consolidamento di più host e più carichi di lavoro in ambienti condivisi delle zone di destinazione. Questo consolidamento consente di ridurre il numero di zone di destinazione e di host dedicati al supporto di un singolo cluster o carico di lavoro.

    Potrebbero essere necessarie altre zone di destinazione se è necessario separare la segmentazione in base ad area, business unit, ambiente, criticità o altri vincoli esterni.

  • Singolo tenant a gestione centralizzata: sono spesso previsti host dedicati per carichi di lavoro ostili o regolamentati che vengono comunque gestiti centralmente. Per migliorare l'efficienza operativa, è anche possibile consolidare le zone di destinazione di supporto.

• Scegliere una gerarchia del gruppo di gestione in base alla scalabilità generale e all'allineamento degli ambienti e degli host necessari per supportare i requisiti complessivi del portfolio:

  • Struttura semplice per supportare molti host dedicati in ambienti dedicati per le operazioni decentralizzate eseguite da ogni team del carico di lavoro.
  • Struttura segmentata per creare un gruppo di gestione per gli host gestiti centralmente e un gruppo di gestione separato per le operazioni decentralizzate.
  • Struttura gerarchica che segmenta ulteriormente gli ambienti in base ai requisiti di fatturazione, governance o operativi.

• Decidere quale topologia del registro contenitori usare per la distribuzione di artefatti OCI:

  • Un registro per ogni carico di lavoro.
  • Un registro per ogni cluster con più carichi di lavoro nel registro.
  • Un registro per tutti i cluster nella zona di destinazione con più carichi di lavoro e cluster nello stesso registro.
  • Un registro per tutti i cluster in più zone di destinazione con più carichi di lavoro e cluster nello stesso registro.

• Decidere l'ambito per i criteri del registro contenitori in Criteri di Azure:

  • Impostare un criterio a livello di sottoscrizione che richieda a tutti gli host nella zona di destinazione di usare il registro definito.
  • Impostare un criterio più granulare a livello di gruppo di risorse.
  • Impostare un criterio più ampio a livello di gruppo di gestione.

Suggerimenti per la progettazione

• Definire uno standard di denominazione e assegnazione di tag da applicare a tutte le risorse del contenitore distribuite in Azure. Come minimo, deve includere:
  • Nomi dei carichi di lavoro: identificare il carico o i carichi di lavoro supportati da ogni cluster.
    • Risorse del cluster: identificare l'elevazione dei privilegi dell'allineamento delle risorse cluster dalle considerazioni precedenti.
    • Operatore host: identificare il team responsabile delle operazioni dell'host.
• Implementare un criterio per richiedere un registro artefatti OCI specifico in base alla topologia del registro contenitori dell'organizzazione.