Regioni classiche con più centri dati

Se si crea un cluster classico con più data center, le repliche del master altamente disponibile Kubernetes vengono automaticamente distribuite tra i data center. È possibile distribuire i nodi worker in zone classiche (data center) per proteggere le applicazioni da un guasto di zona. Per determinare se una regione classica ha più data center dalla CLI, è possibile eseguire ibmcloud ks locations e cercare il valore nella colonna Multizone Metro.

* lon05 sostituisce lon02. I nuovi cluster devono utilizzare lon05, che supporta i master altamente disponibili distribuiti tra le zone.

Regioni classiche con un centro dati

Se si crea un cluster classico in una regione con un solo data center, il master altamente disponibile include tre repliche su host separati, ma non è distribuito nelle zone classiche.

Le regioni classiche con un centro dati sono gestite dall'endpoint regionale situato nella regione più vicina che supporta i centri dati classici, ad esempio da mon01 a us-east o da sao01 a us-south.

Il data center di Milano (mil01) è in disuso e chiuderà il 31 ottobre 2025. Migrare l' IBM Cloud Kubernetes Service e su cluster IBM Cloud attualmente ospitati in mil01 verso un altro datacenter IBM Cloud entro il 31 ottobre 2025.

Regioni multizona VPC

Le risorse VPC vengono fornite in una regione, che è un gruppo separato di zone all'interno di una metropolitana. Le zone sono mappate su data center separati per garantire che le risorse siano distribuite uniformemente tra le zone in un'architettura multizona. Nell'API e nella CLI, le zone utilizzano il nome della zona regionale nell'API e nella riga di comando (us-south-1), ma nella console, le zone utilizzano l'ubicazione del data center (Dallas 1). Per il codice del data center a cui corrispondono l'ubicazione e la zona VPC, come us-south-1 e DAL10, vedi Regioni multizona.

† Queste regioni sono disponibili solo come regioni multizona per i cluster sull'infrastruttura VPC.

Risorse in cluster di zone singole

Le risorse del cluster rimangono nel data center in cui il cluster è distribuito, ma le operazioni di gestione potrebbero essere instradate attraverso un endpoint regionale.

Le risorse del tuo cluster, inclusi i nodi master e di lavoro, si trovano nella stessa zona in cui hai distribuito il cluster. Quando avvii azioni di orchestrazione del contenitore locale, come i comandi kubectl, le informazioni vengono scambiate tra i tuoi nodi master e di lavoro all'interno della stessa zona.

Se si configurano altre risorse del cluster, come lo storage, la rete, l'elaborazione o le applicazioni in esecuzione nei pod, le risorse e i relativi dati rimangono nel data center in cui è stato distribuito il cluster.

Quando si avviano azioni di gestione del cluster, come l'esecuzione di comandi, le informazioni di base sul cluster, come il nome, l'ID, l'utente ibmcloud ks informazioni di base sul cluster, come nome, ID, utente, il comando viene instradato attraverso un endpoint regionale e un endpoint globale.

Risorse in cluster multizona

Nei cluster multizona, le risorse del cluster sono distribuite su più sedi (zone per i VPC e data center per i Classic) per una maggiore disponibilità.

I nodi di lavoro sono distribuiti in più zone VPC o nei data center classici della regione per garantire una maggiore disponibilità del cluster. Anche le repliche master di Kubernetes sono distribuite in zone o centri dati classici. Quando si avviano azioni di orchestrazione locale dei container, come ad esempio i kubectl le informazioni vengono scambiate tra i nodi master e worker attraverso l'endpoint globale.

Altre risorse del cluster, come lo storage, la rete, l'elaborazione o le applicazioni in esecuzione nei pod, variano nella modalità di distribuzione alle zone del cluster. Per ulteriori informazioni, consulta questi argomenti:

• Impostazione di archiviazione di file e archiviazione di blocchi in cluster, oppure scelta di una soluzione di archiviazione persistente multizona.
• Consentire l'accesso pubblico o privato a un'applicazione utilizzando un servizio NLB(Network Load Balancer)in un cluster.
• Gestione del traffico di rete utilizzando Ingress.
• Aumento della disponibilità della tua applicazione.

Quando si avviano azioni di gestione del cluster, come l'esecuzione di comandi ibmcloud ks, le informazioni di base sul cluster, come il nome, l'ID, l'utente, il comando viene instradato attraverso l'endpoint globale.