Creazione di un cluster VPC nella console

Crea il tuo cluster Red Hat OpenShift VPC utilizzando la IBM Cloud console. Seguire le istruzioni della console per creare le seguenti configurazioni cluster. Per iniziare a creare il cluster, vai alla console e fai clic su Crea cluster.

VPC (Virtual Private Cloud)

Seleziona l'istanza VPC ( Virtual Private Cloud ) esistente in cui vuoi creare il tuo cluster. Se non disponi di una VPC, puoi crearne una.

Posizione

Esamina le zone di lavoro e le sottoreti per il tuo cluster. Le zone vengono filtrate in base al VPC che hai selezionato e includono le sottoreti VPC che hai creato in precedenza. A seconda del livello di disponibilità che desideri per il tuo cluster, seleziona una o più zone. Per impostazione predefinita, le tue risorse del cluster sono distribuite in tre zone per l'alta disponibilità. Puoi aggiungere zone al tuo cluster in un secondo momento.

Versione

Selezionare la versione del cluster. Per impostazione predefinita, i cluster sono creati con la versione Kubernetes predefinita, ma puoi specificare una versione supportata diversa.

Licenza

Applica una titolarità o acquista una licenza per il tuo cluster. Per ulteriori informazioni, vedi Assegnazione di licenze software al tuo account, Aggiunta di Cloud Pak, titolarità o licenze al tuo cluster e le FAQ diCloud Pak.

Pool di lavoro

Il pool di nodi di lavoro del cluster definisce numero e tipo di nodi di lavoro che eseguono il tuo carico di lavoro. Puoi modificare i dettagli del tuo pool di lavoro in qualsiasi momento.

• Nodi di lavoro per zona: per l'alta disponibilità, sono consigliati almeno 3 nodi di lavoro per zona.

• Flavor: il flavor definisce l'architettura, la quantità di CPU virtuale, la memoria, la GPU e lo spazio su disco configurati in ciascun nodo di lavoro e messi a disposizione dei container. I tipi di macchine bare metal e virtuali disponibili variano in base alla zona in cui distribuisci il cluster. Per un elenco delle caratteristiche disponibili, vedi Caratteristiche VPC.
• Quando scegli un flavor nella console, puoi filtrare i flavor disponibili per Tipo di macchina, Architettura e Sistema operativo. I tipi di macchina disponibili sono shared o dedicated. Tieni presente che l'opzione dedicated è disponibile solo se hai già un pool di host dedicato nel tuo account. Per un elenco dei sistemi operativi e delle architetture disponibili per versione cluster, consultare versioni disponibili.

• Codifica disco locale: per impostazione predefinita, i nodi di lavoro utilizzano la codifica disco AES a 256 bit. È possibile scegliere di disattivare la codifica del disco quando si crea il cluster. Se abiliti la crittografia, ogni nodo di lavoro nel pool di nodi di lavoro viene crittografato utilizzando le credenziali del provider KMS che gestisci. Solo i nodi del pool di nodi di lavoro default sono codificati. Dopo aver creato il cluster, se si creano più pool di nodi di lavoro, è necessario abilitare la crittografia in ogni pool separatamente. Ogni pool di nodi di lavoro nel cluster può utilizzare la stessa istanza KMS e la stessa chiave root, la stessa istanza KMS con chiavi root differenti o istanze differenti.

• Archiviazione secondaria: puoi eseguire il provisioning di un disco secondario ai tuoi nodi di lavoro, come ad esempio un disco di archiviazione blocchi 900gb.5iops-tier. Quando si aggiunge un disco secondario, tale disco viene utilizzato per il runtime contenitore, mentre il disco primario viene utilizzato per il sistema operativo. I dischi secondari sono utili in scenari in cui è necessaria più archiviazione del contenitore, come i pod in esecuzione con immagini di grandi dimensioni. Si noti che quando si utilizza lo storage secondario, i pod potrebbero non essere in grado di utilizzare tutte le capacità IOPS/larghezza di banda dei volumi a causa dei file system sovrapposti. Il provisioning dei dischi secondari viene eseguito nel tuo account e puoi visualizzarli nella console VPC. Gli addebiti per questi dischi sono separati dal costo di ciascun operatore e vengono visualizzati come un elemento riga differente nella tua fattura. Anche questi volumi secondari vengono conteggiati ai fini del raggiungimento della quota del tuo account. Se intendi utilizzare l'archiviazione secondaria sui nodi a cui possono essere collegati i volumi persistenti, ti consigliamo vivamente di utilizzare i livelli 10 - iops o superiori. Ciò è dovuto al fatto che l'assegnazione della larghezza di banda di memoria per i nodi è condivisa tra i volumi di memoria secondari e le PVC collegate. Quando si utilizza 5 - iops, i livelli possono portare a prestazioni ridotte per il pull delle immagini o per la scrittura dei pod nell'archivio. Per ulteriori informazioni sull'allocazione della larghezza di banda, vedere Allocazione della larghezza di banda nelle istanze del server virtuale.

• GPU: Se si prevede di distribuire carichi di lavoro AI, visivi o grafici di alta qualità sul cluster, assicurarsi di selezionare un nodo worker GPU.

Tipi di sapori aggiuntivi, inclusi sapori con NVIDIA V100, A100, H100, e H200 GPU sono disponibili solo per gli account autorizzati. Per richiedere l'accesso ad altri flavor consentiti, richiedere l'accesso all'allowlist.

Crittografia del pool di lavoro

Gestisci la crittografia dei nodi di lavoro abilitando un provider di servizi di gestione delle chiavi (KMS) a livello di pool di nodi di lavoro. Selezionare l'istanza KMS e il CRN.

Plug-in di rete 4.20 o versione successiva

Selezionare l'interfaccia di rete del container (CNI) che si desidera utilizzare. Scegli tra " Calico " e "Open Virtual Network". Si noti che Open Virtual Network è disponibile solo per la versione 4.20 e successive del cluster " OpenShift " e per i nodi di lavoro RHCOS. Per ulteriori informazioni, consultare la sezione " Selezione di un'interfaccia di rete del container(CNI) ".

Impostazioni di rete

Gli endpoint di servizio forniscono la comunicazione al master. Puoi scegliere di configurare il tuo cluster con un endpoint del servizio pubblico o con un endpoint del servizio cloud pubblico e uno privato. Per ulteriori informazioni sulla configurazione richiesta per eseguire applicazioni con connessione Internet o per mantenere privato il tuo cluster, vedi Pianificazione della configurazione di rete del tuo cluster. Non è possibile modificare gli endpoint del servizio cloud dopo aver creato il cluster.

Registro interno

Seleziona la tua istanza COS. Viene eseguito automaticamente il backup delle immagini del contenitore memorizzate nel registro interno del tuo cluster Red Hat OpenShift on IBM Cloud in un bucket Object Storage. Tutti i dati archiviati nel bucket di archiviazione oggetti rimangono anche se elimini il cluster.

Protezione del traffico in uscita

Il comportamento predefinito per i cluster alla versione 4.15 e successive è quello di consentire solo il traffico di rete necessario per il funzionamento del cluster e disabilitare tutte le altre connessioni in uscita. Se disponi di app o servizi che richiedono la connessione a Internet pubblica, ad esempio GitHub repository, Docker Centro,quay.io, IL Red Hat Marketplace E OperatorHub, tieni presente che devi disattivare completamente la protezione del traffico in uscita (in modo che tutto il traffico in uscita sia consentito) oppure aggiungere regole del gruppo di sicurezza per consentire solo il traffico in uscita richiesto.

Crittografia cluster

Abilita la crittografia dei dati con un KMS (key management service) per crittografare i segreti e altre informazioni sensibili nel tuo cluster. Puoi anche abilitare KMS in un secondo momento.

Gestione dei segreti in entrata

IBM Cloud Secrets Manager gestisce centralmente i certificati del dominio secondario Ingress e altri segreti nel tuo cluster. Puoi scegliere di registrare un'istanza Secrets Manager nel tuo cluster durante il processo di creazione del cluster. È anche possibile specificare un gruppo di segreti che è possibile utilizzare per controllare l'accesso ai segreti nel cluster. Entrambe queste opzioni possono essere configurate o modificate dopo aver creato il cluster.

Gruppi di sicurezza VPC

Fornire fino a quattro gruppi di sicurezza personalizzati da applicare a tutti i nodi di lavoro del cluster VPC, oltre al gruppo di sicurezza " kube-<clusterID> ". Per ulteriori informazioni, vedere Comprendere la rete VPC del cluster Secure by Default.

Dettagli cluster

Puoi personalizzare il Nome cluster univoco e qualsiasi tag che vuoi utilizzare per organizzare e identificare le tue risorse IBM Cloud, come team o billing department.

Scegli il Gruppo di risorse in cui creare il tuo cluster. Un cluster può essere creato in un solo gruppo di risorse e, una volta che è stato creato, non puoi modificare il suo gruppo di risorse. Per creare i cluster in un gruppo di risorse diverso da quello predefinito, devi disporre almeno del ruolo di Visualizzatore per il gruppo di risorse.

Se si desidera aggiungere un profilo attendibile esistente al cluster, specificare l'ID del profilo attendibile. Se non si specifica un profilo attendibile, è possibile completare il processo di creazione del cluster con una chiave API. Per ulteriori informazioni, vedere Configurazione di un profilo di fiducia.

Integrazioni di osservabilità

È possibile abilitare integrazioni di osservabilità aggiuntive che si desidera includere nel cluster. Alcune integrazioni vengono abilitate automaticamente se si dispone di un'istanza della piattaforma esistente di tale integrazione. In questo caso, non è possibile disattivare l'integrazione. Se si desidera utilizzare un'integrazione e si dispone solo di un'istanza dell'applicazione esistente di tale integrazione, l'integrazione è disabilitata per impostazione predefinita e deve essere abilitata manualmente.

• Registrazione: È possibile utilizzare IBM Cloud Logs per gestire i registri del sistema operativo, delle applicazioni e della piattaforma. Se si desidera abilitare questa integrazione in un secondo momento, vedere IBM Cloud Logs.

• Monitoraggio e Protezione del carico di lavoro: l'integrazione del servizio di monitoraggio consente di ottenere visibilità operativa sulle prestazioni e sullo stato di salute di applicazioni, servizi e piattaforme. Se si disattiva questa integrazione e si desidera attivarla in seguito, vedere Monitoraggio della salute del cluster. L'integrazione Security and Compliance Center Workload Protection individua e dà priorità alle vulnerabilità del software, rileva e risponde alle minacce e gestisce configurazioni, autorizzazioni e conformità dall'origine all'esecuzione. Per ulteriori informazioni, consultare la pagina Workload Protection Iniziare.
• Specificare il Tipo di configurazione per utilizzare istanze nuove o esistenti di Monitoring e Workload Protection. Se si desidera utilizzare istanze esistenti sia di Monitoraggio che di Protezione carichi di lavoro, le istanze di ciascuna integrazione devono essere collegate. In questo caso, specificare l'istanza di Monitoring o di Workload Protection che si desidera utilizzare; non è possibile specificare entrambe le istanze, ma entrambe le istanze vengono utilizzate finché sono collegate. È possibile collegare le istanze esistenti dalla pagina dei dettagli dell'istanza Monitoraggio o Protezione del carico di lavoro.

Creazione di cluster VPC dalla CLI

• Assicurati di soddisfare i prerequisiti per configurare il tuo account e definire la configurazione del cluster.
• Installa la CLI IBM Cloud e il plugin Red Hat OpenShift on IBM Cloud.
• Installa il plugin della CLI VPC.

1. Nella riga di comando, accedi al tuo account IBM Cloud e seleziona la regione IBM Cloud e il gruppo di risorse in cui desideri creare il tuo cluster VPC. Per le regioni supportate, vedi Creazione di un VPC in una regione diversa. Immetti le tue credenziali IBM Cloud quando richiesto. Se disponi di un ID federato, utilizza l'opzione " --sso " per effettuare l'accesso.

   ibmcloud login -r REGION [-g <resource_group>] [--sso]
   

2. Crea un VPC nella stessa regione in cui vuoi creare il cluster. I cluster di nodi worker nella tua VPC devono inviare e ricevere informazioni da e verso IBM Cloud l'infrastruttura classica? Segui la procedura in Creazione di sottoreti VPC per accesso classico per creare sottoreti VPC e VPC abilitate per i classici senza i prefissi di indirizzo predefiniti automatici.

3. Crea una sottorete per il tuo VPC.

   • Se desideri creare un cluster multizona, ripeti questo passaggio per creare ulteriori sottoreti in tutte le zone che desideri includere nel tuo cluster.
   • Le sottoreti VPC forniscono indirizzi IP per i tuoi nodi di lavoro e servizi del programma di bilanciamento del carico nel cluster, per cui crea una sottorete VPC con un numero sufficiente di indirizzi IP, ad esempio 256. Non è possibile modificare in un secondo momento il numero di indirizzi IP di una sottorete VPC.
   • Non utilizzare i seguenti intervalli riservati: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16.
   • Se i nodi di lavoro devono accedere agli endpoint pubblici o se intendi abilitare entrambi gli endpoint del servizio cloud pubblico e privato, devi collegare un gateway pubblico a ogni sottorete per accedere ai componenti Red Hat OpenShift predefiniti come la console web o OperatorHub.
   • Importante: non eliminare le sottoreti che colleghi al tuo cluster durante la creazione del cluster o quando aggiungi nodi di lavoro in una zona. Se elimini una sottorete VPC utilizzata dal tuo cluster, qualsiasi programma di bilanciamento del carico che utilizza gli indirizzi IP dalla sottorete potrebbe presentare dei problemi e potresti non essere in grado di creare nuovi programmi di bilanciamento del carico.
   • Per ulteriori informazioni, vedi Panoramica della rete VPC in Red Hat OpenShift on IBM Cloud: Sottoreti.

4. Crea il cluster nel tuo VPC. È possibile utilizzare il comando ibmcloud oc cluster create vpc-gen2 per creare un cluster a zona singola nella propria VPC con nodi di lavoro collegati a una sola sottorete VPC. Se vuoi creare un cluster multizona, puoi utilizzare la console IBM Cloud o aggiungere più zone al tuo cluster dopo che è stato creato. Il provisioning del cluster richiede pochi minuti.

   ibmcloud oc cluster create vpc-gen2 --name CLUSTER_NAME --zone VPC_ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR --version 4.21_openshift --cos-instance COS_CRN --workers NUMBER_WORKERS_PER_ZONE [--offering OFFERING] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id ID] [--pod-subnet] [--service-subnet] [--disable-public-service-endpoint] [[--kms-account-id KMS_ACCOUNT_ID] --kms-instance KMS_INSTANCE_ID --crk ROOT_KEY_ID] [--secondary-storage STORAGE] [--disable-outbound-traffic-protection] [--operating-system SYSTEM] [--cni CNI]
   

   --name <cluster_name>

   Specifica un nome per il cluster. Il nome deve iniziare con una lettera, può contenere lettere, numeri, punti (.) e trattini (-) e non può contenere più di 35 caratteri. Utilizza un nome che sia univoco tra le regioni. Il nome cluster e la regione in cui viene distribuito il cluster formano il nome dominio completo per il dominio secondario Ingress. Per garantire che il dominio secondario Ingress sia univoco all'interno di una regione, è possibile che il nome cluster venga troncato e vi venga aggiunto un valore casuale all'interno del nome dominio Ingress.

   --zone <zone>

   Specifica la zona IBM Cloud in cui vuoi creare il cluster. Assicurati di utilizzare una zona corrispondente all'ubicazione della città metropolitana che hai selezionato quando hai creato il tuo VPC e di avere una sottorete VPC esistente per quella zona. Ad esempio, se hai creato la tua VPC nell'area metropolitana di Dallas, la zona deve essere impostata su us-south-1, us-south-2 o us-south-3. Per visualizzare l'elenco delle zone disponibili per i cluster VPC, eseguire il comando ibmcloud oc zone ls --provider vpc-gen2``. Nota che se selezioni una zona al di fuori del tuo paese, potresti aver bisogno dell'autorizzazione legale prima che i dati possano essere archiviati fisicamente in un paese straniero.

   --vpc-id <vpc_ID>

   Immetti l'ID del VPC che hai creato in precedenza. Per recuperare l'ID della tua VPC, esegui il comando ibmcloud oc vpcs.

   --subnet-id <subnet_ID>

   Immetti l'ID della sottorete VPC che hai creato in precedenza. Quando crei un cluster VPC dalla CLI, inizialmente puoi creare il tuo cluster in una zona con una sola sottorete. Per creare un cluster multizona, aggiungi più zone con le sottoreti che hai creato in precedenza al tuo cluster dopo che è stato creato. Per visualizzare gli ID delle tue sottoreti in tutti i gruppi di risorse, esegui ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

   --flavor <worker_flavor>

   Immetti il profilo del nodo di lavoro che vuoi utilizzare. Il profilo determina la quantità di CPU virtuale, memoria e spazio su disco configurata in ogni nodo di lavoro e resa disponibile per le tue applicazioni. I nodi di lavoro VPC possono essere creati esclusivamente come macchine virtuali su un'infrastruttura condivisa. Le macchine bare metal o SDS (software-defined storage) non sono supportate. Per visualizzare i flavor disponibili, elenca innanzitutto le zone VPC disponibili con il comando ibmcloud oc zone ls --provider vpc-gen2, quindi utilizza la zona per elencare i flavor supportati eseguendo il comando ` `ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2. Dopo aver creato il tuo cluster, puoi aggiungere diversi profili aggiungendo un nodo di lavoro o un pool di nodi di lavoro al cluster.

   --version 4.21_openshift

   La versione di " Red Hat OpenShift " per il nodo master del cluster. Per visualizzare le versioni disponibili, esegui il comando ibmcloud oc versions``.

   --cos-instance <cos_CRN>

   Includi l'ID CRN di un'istanza IBM Cloud Object Storage standard per eseguire il backup del registro interno del tuo cluster. Per visualizzare l'elenco dei CRN delle istanze esistenti, esegui il comando ibmcloud resource service-instances --long e individua l'ID della tua istanza di object storage. Per creare un'istanza di object storage standard, eseguire il comando ibmcloud resource service-instance-create <name> cloud-object-storage standard global e prendere nota del relativo ID.

   --workers <number>

   Specifica il numero di nodi di lavoro da includere nel cluster. Se non si specifica questa opzione, viene creato un cluster con il valore minimo pari a 1.

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS

   Facoltativo. Il sistema operativo dei nodi di lavoro nel tuo cluster. Per un elenco dei sistemi operativi disponibili in base alla versione del cluster, vedere le informazioni sulla versione Red Hat OpenShift on IBM Cloud. Se non viene specificata alcuna opzione, viene utilizzato il sistema operativo predefinito che corrisponde alla versione del cluster.

   --offering <offering>

   Facoltativo. Specificare il tipo di offerta del cluster. I valori ammessi sono kubernetes, openshift e openshift-vs. Utilizza openshift-vs per creare un cluster del servizio di virtualizzazione Red Hat OpenShift con funzionalità di virtualizzazione preconfigurate. Per ulteriori informazioni, consultare la panoramica sul servizio di virtualizzazione di Red Hat OpenShift.

   --cluster-security-group <group_ID>

   Facoltativo. Specificare uno o più ID del gruppo di sicurezza da applicare a tutti i worker del cluster. Per OpenShift versione 4.15 e Kubernetes versione 1.30 e successive, questi gruppi di sicurezza vengono applicati in aggiunta al gruppo di sicurezza IBM kube-clusterID. Per le versioni cluster precedenti, specificare l'opzione --cluster-security-group cluster per applicare il gruppo di protezione kube-clusterID. Se non viene specificato alcun valore, viene applicata una serie predefinita di gruppi di sicurezza, incluso kube-clusterID. Per ulteriori informazioni, vedi Aggiunta di gruppi di sicurezza VPC ai cluster e ai pool di nodi di lavoro durante il tempo di creazione.

   I gruppi di protezione applicati a un cluster non possono essere modificati una volta creato il cluster. Puoi modificare le regole dei gruppi di sicurezza applicate al cluster, ma non puoi aggiungere o rimuovere i gruppi di sicurezza a livello di cluster. Se si applicano i gruppi di sicurezza non corretti al momento della creazione del cluster, è necessario eliminare il cluster e crearne uno nuovo. Consulta Aggiunta di gruppi di sicurezza VPC ai cluster e ai pool di nodi di lavoro durante il tempo di creazione per ulteriori dettagli prima di aggiungere i gruppi di protezione al tuo cluster.

   --sm-group GROUP

   Facoltativo. L'ID del gruppo segreto dell'istanza di Secrets Manager in cui sono memorizzati i tuoi segreti. Per ottenere un ID gruppo di segreti, consulta il Riferimento CLISecrets Manager. Utilizzare questa opzione per specificare un gruppo di segreti che controlla chi nel proprio team ha accesso ai segreti cluster.

   --sm-instance INSTANCE

   Facoltativo. Il CRN dell'istanza Secrets Manager. Per ottenere il CRN di un'istanza, eseguire ibmcloud oc ingress instance ls --cluster CLUSTER. Includi questa opzione se vuoi registrare un'istanza Secrets Manager nel cluster.

   --trusted-profile-id ID

   Specificare l'ID di un profilo attendibile esistente da associare al cluster. Con i profili di fiducia, è possibile concedere l'accesso alle risorse del proprio account senza dover gestire credenziali IAM separate. Per ulteriori informazioni, vedere Configurazione di un profilo di fiducia.

   --pod-subnet

   Nel primo cluster creato in una VPC, la sottorete predefinita dei pod è 172.17.0.0/18.

   Nel secondo cluster creato in quella VPC, la sottorete predefinita dei pod è 172.17.64.0/18. In ogni cluster successivo, l'intervallo della sottorete di pod è la successiva sottorete /18 senza sovrapposizioni disponibile. Se prevedi di connettere il tuo cluster alle reti in loco tramite IBM Cloud® Direct Link o un servizio VPN, puoi evitare conflitti di sottorete specificando un CIDR di sottorete personalizzato che fornisce gli indirizzi IP privati per i tuoi pod.

   È possibile specificare la dimensione della sottorete includendovi l'opzione --pod-subnet. Ad esempio: --pod-subnet 0.0.0.0/X dove X è la dimensione della sottorete del pod richiesta. Quindi la sottorete pod viene selezionata automaticamente. Quando si alloca automaticamente la sottorete pod, l'allocazione inizia da 172.17.0.0, la sottorete massima è limitata a 13, e la dimensione minima della sottorete è limitata a 23.

   Quando scegli una dimensione di sottorete, prendi in considerazione la dimensione del cluster che vuoi creare e il numero di nodi di lavoro che potresti aggiungere in futuro. La sottorete deve avere un CIDR di almeno /23, che garantisce un numero sufficiente di indirizzi IP per i pod per un massimo di quattro nodi di lavoro in un cluster. Per i cluster più grandi, utilizza /22 per avere sufficienti indirizzi IP pod per otto nodi di lavoro, /21 per avere sufficienti indirizzi IP pod per 16 nodi di lavoro e così via. Si noti che le sottoreti dei pod e dei servizi non possono sovrapporsi. Se utilizzi sottoreti con intervallo personalizzato per i tuoi nodi di lavoro, devi assicurarti che le sottoreti dei nodi di lavoro non si sovrappongano alla sottorete dei pod del tuo cluster. La sottorete scelta deve essere compresa in uno dei seguenti intervalli: 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255, 198.18.0.0 - 198.19.255.255.

   --service-subnet

   A tutti i servizi che vengono distribuiti al cluster viene assegnato un indirizzo IP privato nell'intervallo 172.21.0.0/16 per impostazione predefinita. Se prevedi di connettere il tuo cluster alle reti in loco tramite IBM Cloud Direct Link o un servizio VPN, puoi evitare conflitti di sottorete specificando un CIDR di sottorete personalizzato che fornisce gli indirizzi IP privati per i tuoi servizi. La sottorete deve essere specificata in formato CIDR con una dimensione di almeno /24, che consente un massimo di 255 servizi nel cluster, oppure di dimensioni maggiori. La sottorete scelta deve essere compresa in uno dei seguenti intervalli: 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255, 198.18.0.0 - 198.19.255.255. Nota che le sottoreti del servizio e del pod non possono sovrapporsi.

   --disable-public-service-endpoint

   Includi questa opzione nel comando per creare il tuo cluster VPC utilizzando esclusivamente un endpoint di servizio cloud privato. Se non si include questa opzione, il cluster verrà configurato con un endpoint di servizio cloud pubblico e uno privato. L'endpoint del servizio determina le modalità di comunicazione tra il master di Red Hat OpenShift e i nodi worker, le modalità con cui il cluster accede ad altri servizi IBM Cloud e alle applicazioni esterne al cluster, nonché le modalità con cui gli utenti si connettono al cluster. Per ulteriori informazioni, vedi Pianificazione della configurazione di rete del tuo cluster. Se si seleziona questa opzione, il cluster verrà creato con router e controller Ingress che, per impostazione predefinita, espongono le applicazioni solo sulla rete privata. Se in seguito vuoi esporre le tue applicazioni su una rete pubblica, devi creare manualmente dei router e controller Ingress pubblici.

   --kms-account-id <KMS_acount_ID>

   Facoltativo: deve essere incluso se vengono fornite le opzioni --kms-instance-id e --crk e l'istanza KMS si trova in un account diverso da quello del cluster, altrimenti può essere omesso. L'impostazione della crittografia utilizzando un KMS da un account differente è disponibile solo per gli account consentiti. Per essere aggiunto all'elenco dei dati consentiti, aprire un caso con il supporto.

   --kms-instance <KMS_instance_ID>

   Facoltativo: includi l'ID di un'istanza KMS (Key Management Service) da utilizzare per crittografare il disco locale sui nodi di lavoro nel pool di lavoro default. Per elencare le istanze KMS disponibili, esegui ibmcloud oc kms instance ls. Se si include questa opzione, è necessario includere anche l'opzione " --crk ". Prima di poter utilizzare la crittografia KMS, devi creare un'istanza KMS e configurare l'autorizzazione del servizio richiesta in IAM. Vedi Gestione della crittografia per i nodi di lavoro nel tuo cluster.

   --crk <root_key>

   Facoltativo: includi l'ID della chiave root nell'istanza KMS da utilizzare per crittografare il disco locale sui nodi di lavoro nel pool di lavoro default. Per visualizzare l'elenco delle chiavi root disponibili, eseguire il comando ibmcloud oc kms crk ls --instance-id``. Se si include questa opzione, è necessario includere anche l'opzione " --kms-instance ". Prima di poter utilizzare la crittografia KMS, devi creare un'istanza KMS e configurare l'autorizzazione del servizio richiesta in IAM. Vedi Gestione della crittografia per i nodi di lavoro nel tuo cluster.

   --secondary-storage STORAGE

   Facoltativo. L'opzione di conservazione per il gusto. Ad esempio, 900gb.5iops-tier. Quando si aggiunge un disco secondario, tale disco viene utilizzato per il runtime contenitore, mentre il disco primario viene utilizzato per il sistema operativo. Per visualizzare le opzioni di archiviazione per un flavor, eseguire il comando ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2. Per visualizzare un elenco di caratteristiche del nodo di lavoro VPC, vedi Caratteristiche VPC.

   --disable-outbound-traffic-protection

   Facoltativo. Disattivare la protezione del traffico in uscita.

   --cni CNI

   Impostare il plugin di rete per il cluster. Calico è impostato per impostazione predefinita. Valori accettati: Calico, OVNKubernetes.

   --offering OFFERING

   Facoltativo. Specificare il tipo di offerta del cluster. Utilizza openshift-vs per creare un cluster del servizio di virtualizzazione Red Hat OpenShift con funzionalità di virtualizzazione preconfigurate. Se non diversamente specificato, viene creato un cluster standard di tipo " OpenShift ". Per ulteriori informazioni, consultare la panoramica sul servizio di virtualizzazione di Red Hat OpenShift.

5. Verifica che la creazione del cluster sia stata richiesta. Possono essere necessari alcuni minuti per l'ordinazione delle macchine del nodo di lavoro e per la configurazione e il provisioning del cluster nel tuo account.

   ibmcloud oc cluster ls
   

   Una volta completata la configurazione del master di Red Hat OpenShift, lo stato del cluster torna alla normalità. Una volta che il master di Red Hat OpenShift è pronto, i nodi di lavoro saranno configurati.

   NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    aaf97a8843a29941b49a598f516da72101   normal   20170201162433   3          Dallas     4.21.27_1544_openshift      Default               vpc-gen2
   

6. Controlla lo stato dei nodi di lavoro.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Quando i nodi di lavoro sono pronti, lo stato (State ) del nodo di lavoro passa a “ normal ” e lo stato (Status) passa a “ Ready ”. Quando lo stato (Status) del nodo diventa Ready, puoi accedere al cluster. Nota che anche se il cluster è pronto, alcune parti del cluster utilizzate da altri servizi come i segreti Ingress o i segreti di pull dell'immagine di registro potrebbero essere ancora in elaborazione.

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   b3c.4x16.encrypted  normal   Ready    dal10   4.21.27_1544_openshift
   

   A ogni nodo di lavoro viene assegnato un ID e nome dominio univoco che non deve essere modificato manualmente dopo la creazione del cluster. Se si modifica l'ID o il nome di dominio, il Red Hat OpenShift master non sarà in grado di gestire il cluster.

Comandi di esempio per creare cluster VPC

I flavor con archiviazione dell'istanza sono disponibili per gli account consentiti. Per essere aggiunto all'elenco dei dati consentiti, aprire un caso con il supporto.

Comando di esempio per creare un cluster VPC con 3 nodi di lavoro in us-east-1.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN--flavor bx2.4x16 --workers 3

Comando di esempio per creare un cluster VPC con 3 nodi worker in 'us-east-1 con un intervallo e una dimensione di subnet pod personalizzati e protezione del traffico in uscita disabilitata.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN --flavor bx2.4x16 --workers 3 --pod-subnet 0.0.0.0/15 --disable-outbound-traffic-protection

Comando di esempio per un cluster VPC con nodi di lavoro che eseguono il sistema operativo Red Hat CoreOS (RHCOS).

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHCOS

Comando di esempio per un cluster VPC con nodi worker che eseguono il sistema operativo RHEL 9 e protezione del traffico in uscita disabilitata.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHEL_9_64 --disable-outbound-traffic-protection

Comando di esempio per creare un cluster con 3 nodi di lavoro in us-south-1 e abilitare la crittografia del disco del nodo di lavoro fornendo l'ID istanza del provider KMS, l'ID account e CRK.

ibmcloud oc cluster create vpc-gen2 --name <cluster_name> --zone us-south-1 --vpc-id VPC-ID --subnet-id SUBNET-ID --flavor b3c.4x16 --workers 3 --kms-account-id KMS-ACCOUNT-ID --kms-instance-id KMS-INSTANCE-ID --crk CRK

Esempio di comando per aggiungere nodi worker aggiungendo una zona a un cluster VPC multizona.

ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster <cluster_name_or_ID> --worker-pool WORKER-POOL --subnet-id SUBNET-ID

Creazione di un cluster VPC con Terraform

• Terraform su IBM Cloud consente un provisioning prevedibile e coerente dell'infrastruttura e delle risorse IBM Cloud della piattaforma, inclusi i cluster VPC.

• Per creare un cluster VPC con Terraform, crei prima un file di configurazione Terraform che dichiara il tipo di risorsa cluster che vuoi creare. Quindi, si applica il file di configurazione Terraform.

• Per ulteriori informazioni su Terraform, consultare Informazioni su Terraform su IBM Cloud.

• Il modulo Terraform IBM- cluster VPC Red Hat OpenShift su IBM Cloud include codice di infrastruttura pronto all'uso ed esempi pratici che possono accelerare la distribuzione. Se state cercando di eseguire il provisioning di un ambiente OpenShift di livello aziendale in modo rapido e coerente, questo modulo è un ottimo punto di partenza.

Prima di cominciare:

• Installa la CLI Terraform e il plug-in IBM Cloud Provider.
• Assicurarsi di disporre di una chiave API IBM Cloud.

1. Crea un file provider Terraform. Salvare il file nella directory Terraform. Per ulteriori informazioni, vedi la documentazione di Terraform IBM Cloud Provider.

   File provider Terraform di esempio.

   terraform {
       required_providers {
           ibm = {
               source = "IBM-Cloud/ibm"
               version = "1.53.0"
           }
       }
   }
   provider "ibm" {
       region = "us-south"
       ibmcloud_api_key = "<api-key>"
   }
   

2. a) Creare un file di configurazione Terraform per un cluster VPC. Salvare il file nella directory Terraform. Per ulteriori informazioni e opzioni di configurazione del cluster, vedi la documentazione di Terraform ibm_container_cluster.

   Esempio di file di configurazione Terraform:

   resource "ibm_container_vpc_cluster" "cluster" {
       name              = "tf-vpc"
       vpc_id            = "<vpc_id>"
       flavor            = "bx2.16x64"
       worker_count      = "3"
       operating_system  = "REDHAT_8_64"
       kube_version      = "1.28.2"
       resource_group_id = "<resource_group_id>"
       zones {
           subnet_id = "<subnet_id>"
           name      = "us-south-1"
       }
   }
   

   name

   Obbligatorio. Il nome del cluster.

   vpc_id

   Obbligatorio. L'ID del VPC che desideri utilizzare per il tuo cluster. Per visualizzare l'elenco delle VPC disponibili, eseguire il comando ibmcloud is vpcs``.

   flavor

   Obbligatorio. La caratteristica del nodo di lavoro. Il flavor determina la quantità di memoria, CPU e spazio su disco disponibile per i tuoi nodi di lavoro. Per un elenco delle caratteristiche del nodo di lavoro disponibili, esegui ibmcloud oc flavors --zone <zone> --provider classic o vedi Caratteristiche classiche.

   worker_count

   Il numero di nodi di lavoro che desideri aggiungere al pool di nodi di lavoro predefinito.

   operating_system

   Il sistema operativo dei nodi di lavoro nel pool di lavoro. Per un elenco di sistemi operativi supportati per versione cluster, vedi Red Hat OpenShift on IBM Cloud informazioni sulla versione.

   kube_version

   La versione “ Kubernetes ” del tuo cluster. Per impostazione predefinita, i cluster sono creati con la versione Kubernetes predefinita, ma puoi specificare una versione supportata diversa.

   resource_group_id

   L'ID del gruppo di risorse. Per visualizzare i gruppi di risorse disponibili, eseguire il comando ibmcloud resource groups``. Se non viene fornito alcun valore, viene utilizzato il gruppo di risorse predefinito.

   zones

   Un blocco nidificato che descrive le zone del pool del nodo di lavoro predefinito del cluster VPC.

   subnet_id: obbligatorio. L'ID della sottorete VPC che vuoi utilizzare per i tuoi nodi di lavoro. Per trovare le sottoreti esistenti, eseguire ibmcloud oc subnets --provider classic --zone <zone>.

   • name: Obbligatorio. Il nome della zona per il pool di lavoro predefinito. Per visualizzare le zone disponibili, esegui il comando ibmcloud oc zones --provider vpc-gen2.

   b) In alternativa, se si preferisce utilizzare Moduli Terraform IBM, si può fare riferimento all'esempio seguente per la disposizione Red Hat OpenShift Cluster su VPC Gen2

       locals {
           worker_pools = [
               {
                   subnet_prefix    = "default"
                   pool_name        = "default"
                   machine_type     = "bx2.4x16"
                   workers_per_zone = 2
                   operating_system = "RHCOS"
               }
           ]
           cluster_vpc_subnets = {
               default    = [
                   {
                       id         = "0717-afc29fbb-0dbe-493a-a5b9-f3c5899cb8b9"
                       cidr_block = "192.168.32.0/22"                        
                       zone       = "us-south-1"
                   }
               ]
           }
       }
       module "ocp_base" {
           source               = "terraform-ibm-modules/base-ocp-vpc/ibm"
           version              = "3.81.3"
           region               = "us-south"
           resource_group_id    = "resource-group-id"
           cluster_name         = "test-ocp-cluster"
           force_delete_storage = true
           vpc_id               = "vpc-id"
           vpc_subnets          = local.cluster_vpc_subnets
           worker_pools         = local.worker_pools
       }
   

3. Nella CLI, passa alla tua directory Terraform.

   cd <terraform_directory>
   

4. Esegui i comandi per avviare e pianificare le tue azioni Terraform. Esaminare l'output del piano per assicurarsi che vengano eseguite le azioni corrette.

   terraform init
   

   terraform plan
   

5. Applica i file Terraform per creare il cluster. Passa quindi alla console IBM Cloud per controllare che il cluster stia eseguendo il provisioning.

   terraform apply