Creazione di un cluster classico nella console

Per iniziare a creare il cluster, vai alla console e fai clic su Crea cluster.

Dettagli ubicazione

Quando crei un cluster, le sue risorse rimangono nell'ubicazione a cui distribuisci il cluster.

• Gruppo di risorse: un cluster può essere creato solo in un unico gruppo di risorse e, una volta creato, non è possibile modificarne il 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.

• Geografia: selezionare un'area in cui creare il cluster, ad esempio il Nord America. La geografia consente di filtrare i valori “Disponibilità” e “Metro” che è possibile selezionare nella console.

• Disponibilità: un cluster può essere creato con la configurazione Zona singola o Multizona. Un cluster multizona fornisce l'alta disponibilità, con il master Red Hat OpenShift distribuito in una zona con capacità multizona e tre repliche del master distribuite in zone differenti.
  • Per i cluster multizona, scegliere un'ubicazione Metro. Per prestazioni ottimali, seleziona la regione fisicamente più vicina a te. Le zone di lavoro si basano sulla regione scelta. Puoi selezionare quali zone di lavoro applicare e i tuoi nodi di lavoro sono distribuiti tra le tue zone per l'alta disponibilità. Ogni zona di lavoro dispone di una VLAN pubblica e privata. Se non hai delle VLAN in quella zona, vengono create per te.
  • Per i cluster a zona singola, scegli una singola zona di lavoro in cui ospitare il tuo cluster. Per ottenere le migliori prestazioni, seleziona una zona della città che sia fisicamente la più vicina a te. Ogni zona di lavoro dispone di una VLAN pubblica e privata. Se non disponi di VLAN in quella zona, verranno create automaticamente.

Versione Kubernetes

Per impostazione predefinita, i cluster vengono creati con la versione Kubernetes predefinita. È possibile specificare una versione supportata differente.

Pool di lavoratori

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.

• Flavor: il flavor definisce la quantità di CPU virtuale, memoria e spazio su disco configurata in ciascun nodo di lavoro e messa a disposizione dei container. I tipi di macchine bare metal e virtuali disponibili variano in base alla zona in cui distribuisci il cluster.

• Sistema operativo e Architettura: per un elenco dei sistemi operativi e delle architetture disponibili per versione cluster, vedi versioni disponibili.

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

• 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.

Endpoint servizio master

Gli endpoint di servizio forniscono la comunicazione al master. Puoi scegliere di configurare il tuo cluster solo con un endpoint del servizio cloud pubblico o sia con un endpoint del servizio cloud pubblico che con 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.

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.

Crittografia

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.

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.

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: l'integrazione del servizio di monitoraggio consente la visibilità operativa delle prestazioni e dell'integrità delle applicazioni, dei servizi e delle piattaforme. Se si disattiva questa integrazione e si desidera attivarla in un secondo momento, vedere Monitoraggio della salute del cluster.L'integrazione Security and Compliance Center per la protezione del carico di lavoro trova e dà priorità alle vulnerabilità del software, rileva e risponde alle minacce e gestisce le configurazioni, le autorizzazioni e la 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 un cluster classico nella CLI

Crea il tuo cluster Classic utilizzando la IBM Cloud CLI.

• Assicurati di soddisfare i prerequisiti per preparare il tuo account e definire la configurazione del cluster. Tieni presente che è necessario un cluster con almeno 2 nodi di lavoro del tipo “ 4x16 ” affinché i componenti predefiniti di Red Hat OpenShift possano essere distribuiti.
• Installa gli strumenti della CLI IBM Cloud.

1. Accedi alla CLI di IBM Cloud. Se si sta effettuando l'accesso con un ID federato, utilizzare ibmcloud login --sso.

   ibmcloud login [--sso]
   

2. Se disponi di più account IBM Cloud, seleziona l'account in cui desideri creare il cluster.

3. Per creare i cluster in un gruppo di risorse diverso da quello predefinito, specifica tale gruppo di risorse. 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. Devi avere almeno il ruolo Visualizzatore per il gruppo di risorse di destinazione.

   ibmcloud target -g RESOURCE_GROUP_NAME
   

4. Esamina le zone in cui puoi creare il tuo cluster. Nell'output del seguente comando, il Tipo di ubicazione delle zone è dc. Per estendere il tuo cluster tra le zone, devi crearlo in una una zona che supporta il multizona. Le zone multizona hanno una valore metropolitano nella colonna Metropolitana multizona. Se vuoi creare un cluster multizona, puoi utilizzare la console IBM Cloud o aggiungere più zone al tuo cluster dopo che è stato creato.

   ibmcloud oc locations
   

   Quando selezioni una zona che si trova fuori dal tuo paese, tieni presente che potresti aver bisogno dell'autorizzazione legale prima che i dati possano essere archiviati fisicamente in un paese straniero.

5. Esamina i profili di nodo di lavoro disponibili in tale zona. 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 nei cluster classici possono essere creati come macchine virtuali sull'infrastruttura condivisa o dedicata o come macchine bare metal dedicate a te. Dopo aver creato il tuo cluster, puoi aggiungere diversi profili aggiungendo un pool di nodi di lavoro.

   Assicurati di voler eseguire il provisioning di una macchina bare metal prima di crearne una. Le macchine bare metal vengono fatturate mensilmente. Se ordini una macchina bare metal per errore, ti viene addebitato l'importo per l'intero mese, anche se annulli la macchina immediatamente.
   

   ibmcloud oc flavors --zone ZONE
   

6. Controlla se disponi di VLAN esistenti nelle zone che vuoi includere nel tuo cluster e prendi nota dell'ID della VLAN. Se in una delle zone che desideri utilizzare nel tuo cluster non è presente una VLAN pubblica o privata, IBM Cloud Kubernetes Service crea automaticamente tali VLAN al momento della creazione del cluster.

   ibmcloud oc vlan ls --zone ZONE
   

   Output di esempio

   ID        Name   Number   Type      Router
   1519999   vlan   1355     private   bcr02a.dal10
   1519898   vlan   1357     private   bcr02a.dal10
   1518787   vlan   1252     public    fcr02a.dal10
   1518888   vlan   1254     public    fcr02a.dal10
   

   Se esiste già una VLAN pubblica e privata, annota i router corrispondenti. I router della VLAN privata iniziano sempre con bcr (router back-end) e i router della VLAN pubblica iniziano sempre con fcr (router front-end). Quando crei un cluster e specifichi le VLAN pubbliche e private, la combinazione di numeri e lettere dopo tali prefissi devono corrispondere. Nell'output di esempio, qualsiasi VLAN privata può essere utilizzata con qualsiasi VLAN pubblica perché i router includono tutti 02a.dal10.

7. Crea il tuo cluster standard.

   ibmcloud oc cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> [--operating-system (REDHAT_8_64)] --name <cluster_name> --version <major.minor.patch>_openshift --public-service-endpoint [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id]
   

   --zone <zone>

   Specifica l'ID zona IBM Cloud che hai scelto in precedenza e che vuoi utilizzare per creare il tuo cluster.

   --flavor <flavor>

   Specifica il profilo per il tuo nodo di lavoro che hai scelto in precedenza.

   --hardware <shared_or_dedicated>

   Specifica il livello di isolamento hardware per il tuo nodo di lavoro. Utilizza dedicated per disporre di risorse fisiche dedicate esclusivamente a te, oppure shared per consentire la condivisione delle risorse fisiche con altri clienti di IBM. L'impostazione predefinita è shared. Questo valore è facoltativo per i cluster standard VM. Per i profili bare metal, specifica dedicated.

   --public-vlan <public_vlan_id>

   Se hai già una VLAN pubblica configurata nel tuo account dell'infrastruttura IBM Cloud per quella zona, immetti l'ID della VLAN pubblica che hai richiamato in precedenza. Se non hai una VLAN pubblica nel tuo account, non specificare questa opzione. IBM Cloud Kubernetes Service crea automaticamente una VLAN pubblica per te. I router della VLAN privata iniziano sempre con bcr (router back-end) e i router della VLAN pubblica iniziano sempre con fcr (router front-end). Quando crei un cluster e specifichi le VLAN pubbliche e private, la combinazione di numeri e lettere dopo tali prefissi devono corrispondere.

   --private-vlan <private_vlan_id>

   Se hai già una VLAN privata configurata nel tuo account dell'infrastruttura IBM Cloud per quella zona, immetti l'ID della VLAN privata che hai richiamato in precedenza. Se non hai una VLAN privata nel tuo account, non specificare questa opzione. IBM Cloud Kubernetes Service crea automaticamente una VLAN privata per te. I router della VLAN privata iniziano sempre con bcr (router back-end) e i router della VLAN pubblica iniziano sempre con fcr (router front-end). Quando crei un cluster e specifichi le VLAN pubbliche e private, la combinazione di numeri e lettere dopo tali prefissi devono corrispondere.

   --name <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.

   --workers <number>

   Specifica il numero di nodi di lavoro da includere nel cluster. Il valore predefinito è 1.

   --version <major.minor.patch>

   La versione di " Red Hat OpenShift " per il nodo master del cluster. Questo valore è obbligatorio. Quando la versione non viene specificata, il cluster viene creato con la versione Kubernetes supportata predefinita. Se non si specifica una versione supportata di Red Hat OpenShift, il cluster verrà creato come cluster " Kubernetes " della community. Per visualizzare le versioni disponibili, esegui il comando ibmcloud oc versions``.

   --public-service-endpoint

   Abilita l'endpoint del servizio cloud pubblico in modo che sia possibile accedere al master di Red Hat OpenShift tramite la rete pubblica, ad esempio per eseguire comandi oc dalla CLI, e affinché il master di Red Hat OpenShift e i nodi di lavoro possano comunicare tramite la VLAN pubblica. Devi abilitare l'endpoint del servizio cloud pubblico e non puoi disabilitarlo successivamente it.After aver creato il cluster, puoi ottenere l'endpoint eseguendo ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --private-service-endpoint

   In Compatibile con VRF e account con endpoint di servizio abilitati: abilitare l'endpoint del servizio cloud privato in modo che il master di Red Hat OpenShift e i nodi di lavoro possano comunicare tramite la VLAN privata. Se si specifica questa opzione, è necessario abilitare anche l'endpoint del servizio cloud pubblico utilizzando l'opzione --public-service-endpoint. Nota che non puoi modificare successivamente gli endpoint endpoints.After che hai creato il cluster, puoi ottenere l'endpoint eseguendo ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --pod-subnet

   A tutti i pod che vengono distribuiti in un nodo di lavoro viene assegnato un indirizzo IP privato nell'intervallo 172.30.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 pod. 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 fornisce abbastanza IP 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. Per impostazione predefinita, la sottorete del servizio è entro l'intervallo 172.21.0.0/16. La sottorete che scegli deve rientrare 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 che scegli deve rientrare 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

   Si noti che le sottoreti dei pod e dei servizi non possono sovrapporsi. Per impostazione predefinita, la sottorete del pod è entro l'intervallo 172.30.0.0/16.

   --disable-disk-encrypt

   I nodi di lavoro sono dotati di crittografia disco AES a 256 bit per impostazione predefinita. Se vuoi disabilitare la crittografia, includi questa opzione.

   --entitlement ocp_entitled

   Includere questa opzione solo per un cluster che dispone di un Red Hat OpenShift diritto. Quando si specificano il numero di worker (--workers) e il tipo (--flavor), assicurarsi di indicare solo il numero e la dimensione dei nodi worker che si è autorizzati a utilizzare in IBM Passport Advantage. Una volta creato il cluster, non ti verrà addebitato il costo della licenza “ Red Hat OpenShift ” per i nodi di lavoro aventi diritto nel pool di lavoro “ default ”. Non superare la tua titolarità. Tieni presente che le tue titolarità OpenShift Container Platform possono essere utilizzate con altri provider cloud o in altri ambienti. Per evitare problemi di fatturazione in un secondo momento, assicurati di utilizzare solo ciò per cui disponi di titolarità. Ad esempio, potresti avere una titolarità per le licenze OCP per due nodi di lavoro di 4 CPU e 16 GB di memoria e crei questo pool di nodi di lavoro con due nodi di lavoro di 4 CPU e 16 GB di memoria. Hai esaurito il tuo diritto e non puoi utilizzare lo stesso diritto per altri gruppi di lavoratori, fornitori di servizi cloud o ambienti.

   --sm-group GROUP

   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.

   --sm-instance INSTANCE

   Il CRN dell'istanza Secrets Manager. Per ottenere il CRN di un'istanza, eseguire ibmcloud oc ingress instance ls --cluster 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.

8. Verifica che la creazione del cluster sia stata richiesta. Per le macchine virtuali, possono essere necessari alcuni minuti per l'ordine delle macchine del nodo di lavoro e per la configurazione e il provisioning del cluster nel tuo account. Il provisioning delle macchine fisiche bare metal viene eseguito tramite l'interazione manuale con l'infrastruttura Cloud IBM e il completamento di questo processo può richiedere più di un giorno lavorativo.

   ibmcloud oc cluster ls
   

   Una volta completata la configurazione del master di Red Hat OpenShift, lo stato del cluster passa a “ normal ”. Una volta che il master di Red Hat OpenShift è pronto, viene avviata la configurazione dei nodi di lavoro.

   NAME         ID                         State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    blrs3b1d0p0p2f7haq0g       normal   20170201162433   3          dal10     4.21.27_1544_openshift      Default             classic
   

   Il tuo cluster non è in uno stato normal? Controlla la guida Debug dei cluster per un aiuto. Ad esempio, se il provisioning del tuo cluster viene eseguito in un account che è protetto da un'applicazione gateway firewall, devi configurare le impostazioni del tuo firewall per consentire il traffico in uscita alle porte e agli indirizzi IP appropriati.

9. Controlla lo stato dei nodi di lavoro.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Quando i nodi di lavoro sono pronti, la loro condizione passa a normale e lo stato diventa Pronto. Quando lo stato del nodo è 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. Nota che se hai creato il tuo cluster solo con una VLAN privata, ai tuoi nodi di lavoro non viene assegnato nessun indirizzo IP pubblico.

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   u3c.2x4.encrypted   normal   Ready    dal10   1.35.7_1526
   

   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.

10. Opzionale: se il cluster è stato creato in una regione multizona, è possibile distribuire il pool di worker predefinito tra le diverse zone per aumentare la disponibilità del cluster.

11. Una volta che il tuo cluster è stato creato, puoi iniziare a utilizzarlo configurando la sessione della tua CLI.

Il tuo cluster è pronto per i tuoi carichi di lavoro! Potresti anche voler aggiungere una tag al tuo cluster, come il team o il reparto di fatturazione che utilizza il cluster, per facilitare la gestione delle risorse IBM Cloud.

Comandi di esempio per creare cluster classici

Comando di esempio per creare un cluster Classic sulla macchina virtuale condivisa.

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3

Comando di esempio per la creazione di un cluster Classic su bare metal.

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor mb2c.4x32 --hardware dedicated --workers 3 --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID>

Comando di esempio per creare un cluster Classic con un'autorizzazione " IBM Cloud Pak " per un pool di worker predefinito composto da 3 nodi worker con 4 core e 16 di memoria ciascuno.

ibmcloud oc cluster create classic --name cloud_pak_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware dedicated --workers 3 --entitlement ENTITLEMENT --public-vlan PUBLIC-VLAN-ID --private-vlan PRIVATE-VLAN-ID [--operating-system (REDHAT_8_64)]

Comando di esempio per la creazione di un cluster Classic con nodi worker RHEL 9.

ibmcloud oc cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --version 4.9.28_openshift --operating-system RHEL_9_64

Per un cluster multizona classico, dopo aver creato il cluster in un’area metropolitana multizona, aggiungere le zone. Comando di esempio per l'aggiunta di una zona a un cluster Classic.

ibmcloud oc zone add classic --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_VLAN_ID> --public-vlan <public_VLAN_ID>

Creazione di un cluster classico a zona singola con Terraform

Terraform su IBM Cloud abilita il provisioning prevedibile e congruente dell'infrastruttura e delle risorse della piattaforma IBM Cloud, compresi i cluster classici. Per creare un cluster classico con Terraform, si crea prima un file di configurazione Terraform che dichiara il tipo di risorsa cluster che si desidera creare. Quindi, si applica il file di configurazione Terraform. Per ulteriori informazioni su Terraform, vedi About Terraform on IBM Cloud.

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. Crea un file di configurazione Terraform per un cluster classico. Salvare il file nella directory Terraform. La seguente configurazione di esempio crea un cluster classico con tre nodi worker in una zona. Per ulteriori informazioni e opzioni di configurazione del cluster, vedi la documentazione di Terraform ibm_container_cluster.

   File di configurazione Terraform di esempio.

   resource "ibm_container_cluster" "testacc_cluster" {
   name            = "test-classic"
   datacenter      = "dal10"
   machine_type    = "b3c.4x16"
   hardware        = "shared"
   public_vlan_id  = "<vlan_id>"
   private_vlan_id = "<vlan_id"
   subnet_id       = ["<subnet_id>"]
   default_pool_size = 3
   }
   

   name

   Il nome del cluster.

   datacenter

   L'area in cui creare il cluster. Per visualizzare le zone disponibili, esegui il comando ibmcloud oc zones --provider classic.

   machine_type

   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.

   hardware

   Il livello di isolamento hardware dei nodi di lavoro. Utilizza dedicated per disporre di risorse fisiche dedicate esclusivamente a te, oppure shared per consentire la condivisione delle risorse fisiche con altri clienti di IBM. Questa opzione è disponibile solo per le caratteristiche dei nodi di lavoro della macchina virtuale.

   public_vlan_id e private_vlan_id

   Facoltativo. L'ID della VLAN pubblica o privata che vuoi utilizzare per i tuoi nodi di lavoro. Per trovare le VLAN e le sottoreti disponibili, eseguire ibmcloud oc vlans --zone <zone>.

   subnet_id

   Facoltativo. L'ID di una sottorete esistente che vuoi utilizzare per i tuoi nodi di lavoro. Per trovare le sottoreti esistenti, eseguire ibmcloud oc subnets --provider classic --zone <zone>.

   default_pool_size

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

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