Criação de um cluster clássico no console

Para começar a criar o cluster, navegue até o console e clique em Create cluster (Criar cluster ).

Detalhes do local

Ao criar um cluster, seus recursos permanecem no local no qual você implementa o cluster.

• Grupo de recursos: Um cluster só pode ser criado em um único grupo de recursos e, após a criação do cluster, não é possível alterar o grupo de recursos ao qual ele pertence. Para criar clusters em um grupo de recursos diferente do padrão, é necessário ter pelo menos a função Visualizador para o grupo de recursos.

• Geografia: Selecione uma região na qual criar o agrupamento, como a América do Norte. A localização geográfica ajuda a filtrar os valores de “Disponibilidade” e “Metro” que você pode selecionar no console.

• Disponibilidade: um cluster pode ser criado com uma configuração de Zona única ou de Multizona Um cluster multizona fornece alta disponibilidade, com o mestre Red Hat OpenShift implementado em uma zona com capacidade para multizona e três réplicas do mestre difundidas em diferentes zonas.
  • Para clusters de múltiplas zonas, escolha um local de Metro Para obter o melhor desempenho, selecione a região que está fisicamente mais próxima de você. Suas Zonas de trabalho são baseadas na região que você escolher. É possível selecionar quais zonas do trabalhador aplicar e seus nós do trabalhador serão distribuídos em suas zonas para alta disponibilidade. Cada zona do trabalhador tem uma VLANs pública e privada Se você não tiver VLANs nessa zona, elas serão criadas para você..
  • Para clusters de zona única, escolha uma única Zona do trabalhador para hospedar seu cluster. Para obter o melhor desempenho, selecione uma zona da cidade que esteja fisicamente mais próxima de você. Cada zona do trabalhador tem uma VLANs pública e privada Se você não tiver VLANs nessa zona, elas serão criadas para você.

Versão do Kubernetes

Por padrão, os clusters são criados com a versão padrão do Kubernetes É possível especificar uma versão suportada diferente.

Conjunto de trabalhadores

O conjunto de trabalhadores do cluster define o número e o tipo de nós do trabalhador que executam sua carga de trabalho. É possível mudar os detalhes do seu conjunto de trabalhadores a qualquer momento

• Flavor: O flavor define a quantidade de CPU virtual, memória e espaço em disco que é configurada em cada nó de trabalho e disponibilizada aos contêineres. Os tipos de bare metal e máquinas virtuais disponíveis variam de acordo com a zona na qual você implementa o cluster.

• Sistema operacional e Arquitetura: Para obter uma lista dos sistemas operacionais e arquiteturas disponíveis por versão do cluster, consulte as versões disponíveis..

• Nós do trabalhador por zona: para alta disponibilidade, pelo menos três nós do trabalhador por zona são recomendados.

• Criptografar disco local: por padrão, os nós do trabalhador apresentam criptografia de disco AES de 256 bits. É possível escolher desativar a criptografia de disco ao criar o cluster.

Terminal de serviço mestre

Os terminais de serviço fornecem comunicação para o principal É possível optar por configurar seu cluster com um terminal em serviço de nuvem pública ou pública e privada. Para obter mais informações sobre qual configuração é necessária para executar apps voltados à Internet ou para manter o cluster privado, consulte Planejando a configuração de rede do cluster. Não é possível alterar os pontos de extremidade do serviço de nuvem depois de criar o cluster.

Gerenciamento de segredos de ingresso

IBM Cloud Secrets Manager gerencia centralmente os certificados de subdomínio do Ingress e outros segredos em seu cluster. É possível escolher registrar uma instância do Secrets Manager no cluster durante o processo de criação do cluster. Também é possível especificar um grupo de segredos que pode ser usado para controlar o acesso aos segredos em seu cluster Ambas as opções podem ser configuradas ou alteradas após a criação do cluster.

Criptografia

Ative a criptografia de dados com um serviço de gerenciamento de chave (KMS) para criptografar segredos e outras informações confidenciais no cluster. Também é possível ativar KMS posteriormente.

Detalhes do cluster

É possível customizar o nome exclusivo do cluster e quaisquer tags que você deseja usar para organizar e identificar seus recursos do IBM Cloud, como team ou billing department.

Se quiser adicionar um perfil confiável existente ao seu cluster, especifique o ID do perfil confiável. Se você não especificar um perfil confiável, poderá concluir o processo de criação do cluster com uma chave de API. Consulte Configuração de um perfil confiável para obter mais informações.

Integrações de observabilidade

É possível ativar integrações de observabilidade adicionais que você deseja incluir em seu cluster. Algumas integrações serão ativadas automaticamente se você tiver uma instância de plataforma existente dessa integração.. Nesse caso, não é possível desativar a integração. Se você desejar usar uma integração e tiver apenas uma instância do aplicativo existente dessa integração, a integração será desativada por padrão e deverá ser ativada manualmente.

• Registro de logs: Você pode usar o site IBM Cloud Logs para gerenciar os logs do sistema operacional, os logs de aplicativos e os logs da plataforma. Se você quiser ativar essa integração posteriormente, consulte IBM Cloud Logs.

• Monitoramento: a integração de serviço de monitoramento permite visibilidade operacional no desempenho e funcionamento de seus aplicativos, serviços e plataformas. Se você desativar essa integração e quiser ativá-la mais tarde, consulte Monitoramento da integridade do cluster.A integração do Security and Compliance Center Workload Protection localiza e prioriza vulnerabilidades de software, detecta e responde a ameaças e gerencia configurações, permissões e conformidade da origem à execução. Para obter mais informações, consulte a página Proteção da carga de trabalho Começando.
• Especifique o Tipo de configuração para usar instâncias novas ou existentes do Monitoring and Workload Protection. Se você quiser usar as instâncias existentes da proteção de monitoramento e de carga de trabalho, as instâncias de cada integração deverão ser conectadas. Nesse caso, especifique a instância de monitoramento ou de proteção de carga de trabalho que deseja usar; não é possível especificar as duas instâncias, mas ambas serão usadas desde que estejam conectadas. Você pode conectar as instâncias existentes na página de detalhes da instância Monitoramento ou Proteção de carga de trabalho.

Criação de um cluster clássico na CLI

Crie seu cluster Classic usando a IBM Cloud CLI.

• Certifique-se de cumprir os pré-requisitos para preparar sua conta e definir a configuração do seu cluster. Tenha em mente que um cluster com um mínimo de 2 nós do trabalhador do tipo 4x16 é necessário para que os componentes padrão do Red Hat OpenShift possam ser implementados.
• Instale as IBM Cloud ferramentas da CLI.

1. Faça login na CLI do IBM Cloud. Se você estiver efetuando o login com um ID federado, use ibmcloud login --sso.

   ibmcloud login [--sso]
   

2. Se você tiver várias contas do IBM Cloud, selecione a conta na qual deseja criar seu cluster.

3. Para criar clusters em um grupo de recursos diferente do padrão, destine esse grupo de recursos. Um cluster pode ser criado em apenas um grupo de recursos e, após sua criação, não é possível mudar seu grupo de recursos. Você deve ter pelo menos a função Viewer para o grupo de recursos para destiná-lo.

   ibmcloud target -g RESOURCE_GROUP_NAME
   

4. Revise as zonas nas quais é possível criar seu cluster. Na saída do comando a seguir, as zonas têm um Tipo de Local de dc. Para abranger seu cluster entre zonas, deve-se criar o cluster em uma zona com capacidade para diversas zonas. As zonas com capacidade de multizona têm um valor de área metropolitana na coluna Área metropolitana multizona. Se desejar criar um cluster multizona, será possível usar o console do IBM Cloud ou incluir mais zonas em seu cluster depois da criação dele.

   ibmcloud oc locations
   

   Quando você seleciona uma zona que está localizada fora de seu país, tenha em mente que você pode requerer autorização legal antes que os dados possam ser armazenados fisicamente em um país estrangeiro.

5. Revise os tipos de nó do trabalhador que estão disponíveis nessa zona. O tipo determina a quantia de CPU virtual, memória e espaço em disco configurados em cada nó do trabalhador e disponibilizados para os apps. Os nós do trabalhador em clusters clássicos podem ser criados como máquinas virtuais em uma infraestrutura compartilhada ou dedicada ou como máquinas bare metal dedicadas a você. Depois de criar seu cluster, é possível incluir diferentes tipos incluindo um conjunto de trabalhadores.

   Antes de criar uma máquina bare metal, certifique-se de deseja provisionar uma. As máquinas bare metal são cobradas mensalmente. Se você pedir uma máquina bare metal por engano, você será cobrado pelo mês inteiro, mesmo se cancelar a máquina imediatamente.
   

   ibmcloud oc flavors --zone ZONE
   

6. Verifique se você tem VLANs existentes nas zonas que deseja incluir em seu cluster e anote o ID da VLAN. Se você não tiver uma VLAN pública ou privada em uma das zonas que deseja usar no cluster, o IBM Cloud Kubernetes Service criará automaticamente essas VLANs quando você criar o cluster.

   ibmcloud oc vlan ls --zone ZONE
   

   Exemplo de saída

   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 uma VLAN pública e privada já existe, observe os roteadores correspondentes. Os roteadores de VLAN privada sempre iniciam com bcr (roteador de backend) e roteadores de VLAN pública sempre iniciam com fcr (roteador de front-end). Ao criar um cluster e especificar as VLANs públicas e privadas, a combinação de número e letra após esses prefixos devem corresponder. Na saída de exemplo, qualquer VLAN privada pode ser usada com qualquer VLAN pública porque os roteadores todos incluem 02a.dal10.

7. Crie o cluster padrão.

   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>

   Especifique o IBM Cloud ID da zona que você escolheu anteriormente e que deseja usar para criar seu cluster.

   --flavor <flavor>

   Especifique o tipo para seu nó do trabalhador escolhido anteriormente.

   --hardware <shared_or_dedicated>

   Especifique com o nível de isolamento de hardware para seu nó do trabalhador. Use dedicated para que os recursos físicos disponíveis sejam dedicados apenas a você ou shared para permitir que eles sejam compartilhados com outros clientes IBM. O padrão é compartilhado. Esse valor é opcional para clusters padrão da VM. Para os tipos bare metal, especifique dedicated.

   --public-vlan <public_vlan_id>

   Se já tiver uma VLAN pública configurada em sua conta de infraestrutura da IBM Cloud para essa zona, insira o ID da VLAN pública recuperado anteriormente. Se você não tiver uma VLAN pública na conta, não especifique esta opção. O IBM Cloud Kubernetes Service cria automaticamente uma VLAN pública. Os roteadores de VLAN privada sempre iniciam com bcr (roteador de backend) e roteadores de VLAN pública sempre iniciam com fcr (roteador de front-end). Ao criar um cluster e especificar as VLANs públicas e privadas, a combinação de número e letra após esses prefixos devem corresponder.

   --private-vlan <private_vlan_id>

   Se já tiver uma VLAN privada configurada em sua conta de infraestrutura da IBM Cloud para essa zona, insira o ID da VLAN privada recuperado anteriormente. Se você não tiver uma VLAN privada na conta, não especifique esta opção. O IBM Cloud Kubernetes Service cria automaticamente uma VLAN privada. Os roteadores de VLAN privada sempre iniciam com bcr (roteador de backend) e roteadores de VLAN pública sempre iniciam com fcr (roteador de front-end). Ao criar um cluster e especificar as VLANs públicas e privadas, a combinação de número e letra após esses prefixos devem corresponder.

   --name <name>

   Especifique um nome para seu cluster. O nome deve começar com uma letra, pode conter letras, números, pontos (.) e hífens (-) e deve conter 35 caracteres ou menos. Use um nome que seja exclusivo entre as regiões. O nome do cluster e a região na qual o cluster está implementado formam o nome completo do domínio para o subdomínio do Ingress. Para assegurar que o subdomínio do Ingress seja exclusivo dentro de uma região, o nome do cluster pode ser truncado e anexado com um valor aleatório dentro do nome de domínio do Ingress.

   --workers <number>

   Especifique o número de nós do trabalhador a serem incluídos no cluster. O valor padrão é 1.

   --version <major.minor.patch>

   A versão do Red Hat OpenShift para o nó do cluster mestre. Este valor é necessário. Quando a versão não for especificada, o cluster será criado com a versão do Kubernetes suportada padrão. Se você não especificar uma versão suportada do Red Hat OpenShift, seu cluster será criado como um cluster Kubernetes da comunidade. Para ver as versões disponíveis, execute ibmcloud oc versions.

   --public-service-endpoint

   Ative o terminal em serviço de nuvem pública para que seu mestre do Red Hat OpenShift possa ser acessado por meio da rede pública, por exemplo, para executar comandos oc de sua CLI e para que seu mestre do Red Hat OpenShift e os nós do trabalhador possam se comunicar pela VLAN pública. Deve-se ativar o terminal em serviço de nuvem pública e não é possível desativá-lo posteriormente. Depois de criar o cluster, é possível obter o terminal executando ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --private-service-endpoint

   Em contas ativadas para VRF e ativadas para terminal em serviço: ative o terminal em serviço de nuvem privada para que o principal do Red Hat OpenShift e os nós do trabalhador possam se comunicar por meio da VLAN privada. Se você especificar essa opção, também deverá habilitar o endpoint do serviço em nuvem pública usando a opção --public-service-endpoint . Note que não é possível mudar posteriormente os terminais em serviço de nuvem. Depois de criar o cluster, é possível obter o terminal executando ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --pod-subnet

   Todos os pods implementados em um nó do trabalhador recebem um endereço IP privado no intervalo de 172.30.0.0/16 por padrão. Se você planeja conectar seu cluster a redes no local por meio do IBM Cloud® Direct Link ou um serviço VPN, é possível evitar conflitos de sub-rede especificando um CIDR de sub-rede customizado que forneça os endereços IP privados para os seus pods. Ao escolher um tamanho de sub-rede, considere o tamanho do cluster que planeja criar e o número de nós do trabalhador que podem ser incluídos no futuro. A sub-rede deve ter um CIDR de pelo menos /23, que fornece IPs de pod suficientes para um máximo de quatro nós do trabalhador em um cluster. Para clusters maiores, use /22 para ter endereços IP de pod suficientes para oito nós do trabalhador, /21 para ter endereços IP de pod suficientes para 16 nós do trabalhador e assim por diante. Observe que as sub-redes de pod e de serviço não podem se sobrepor. A sub-rede de serviço está no intervalo 172.21.0.0/16 por padrão. A sub-rede que você escolheu deve estar dentro de um dos intervalos a seguir:

   • 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

   Todos os serviços implementados no cluster recebem um endereço IP privado no intervalo de 172.21.0.0/16 por padrão. Se você planeja conectar seu cluster a redes no local por meio do IBM Cloud Direct Link ou um serviço de VPN, é possível evitar conflitos de sub-rede especificando um CIDR de sub-rede customizado que forneça os endereços IP privados para os seus serviços.

   A sub-rede deve ser especificada no formato CIDR com um tamanho de pelo menos /24, o que permite um máximo de 255 serviços no cluster ou mais. A sub-rede que você escolheu deve estar dentro de um dos intervalos a seguir: - 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

   Observe que as sub-redes de pod e de serviço não podem se sobrepor. A sub-rede de pod está no intervalo 172.30.0.0/16 por padrão.

   --disable-disk-encrypt

   Os nós do trabalhador apresentam a criptografia de disco do AES de 256 bits por padrão. Se desejar desativar a criptografia, inclua esta opção.

   --entitlement ocp_entitled

   Inclua esta opção apenas para um cluster que tenha uma Red Hat OpenShift autorização. Ao especificar o número de workers (--workers) e o tipo (--flavor), certifique-se de indicar apenas o número e o tamanho dos nós de trabalho que você tem permissão para usar em IBM Passport Advantage. Depois que seu cluster é criado, não é cobrada a taxa de licença do Red Hat OpenShift para os nós do trabalhador autorizados no conjunto de trabalhadores default. Não exceda a sua autorização. Lembre-se de que as suas autorizações do OpenShift Container Platform podem ser usadas com outros provedores em nuvem ou em outros ambientes. Para evitar problemas de cobrança posteriormente, certifique-se de usar apenas o que você tem direito a usar. Por exemplo, talvez você tenha uma autorização das licenças OCP para dois nós do trabalhador de quatro CPUs e 16 GB de memória e crie esse conjunto de trabalhadores com dois nós do trabalhador de quatro CPUs e 16 GB de memória. Você usou toda a sua titularidade e não pode usar a mesma titularidade para outros conjuntos de trabalhadores, provedores de nuvem ou ambientes.

   --sm-group GROUP

   O ID do grupo de segredos da instância do Secrets Manager onde seus segredos são armazenados. Para obter um ID de grupo secreto, consulte o Secrets Manager referência CLI.

   --sm-instance INSTANCE

   O CRN da instância do Secrets Manager. Para obter o CRN de uma instância, execute ibmcloud oc ingress instance ls --cluster CLUSTER.

   --trusted-profile-id ID

   Especifique a ID de um perfil confiável existente a ser associado ao cluster. Com os perfis confiáveis, você pode conceder acesso aos recursos da sua conta sem precisar gerenciar credenciais IAM separadas. Consulte Configuração de um perfil confiável para obter mais informações.

8. Verifique se a criação do cluster foi solicitada. Para máquinas virtuais, pode levar alguns minutos para que as máquinas do nó do trabalhador sejam ordenadas e para que o cluster seja configurado e provisionado em sua conta. As máquinas físicas bare metal são provisionadas por interação manual com a infraestrutura do IBM Cloud e podem levar mais de um dia útil para serem concluídas.

   ibmcloud oc cluster ls
   

   Quando o fornecimento do seu Red Hat OpenShift master é concluído, o Estado de seu cluster muda para normal. Depois que o seu mestre do Red Hat OpenShift estiver pronto, o fornecimento de seus nós do trabalhador será iniciado.

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

   O seu cluster não está em um estado normal? Consulte o guia Clusters de depuração para obter ajuda. Por exemplo, se o seu cluster é provisionado em uma conta protegida por um dispositivo de gateway do firewall, deve-se definir suas configurações de firewall para permitir o tráfego de saída para as portas e os endereços IP apropriados.

9. Verifique o status dos nós do trabalhador.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Quando os nós do trabalhador estiverem prontos, o estado do nó do trabalhador mudará para normal e o status mudará para Pronto. Quando o status do nó for Pronto, será possível, então, acessar o cluster. Observe que mesmo se o cluster estiver pronto, algumas de suas partes usadas por outros serviços, como segredos do Ingress ou segredos de extração de imagem, ainda poderão estar em processo. Observe que, se você criou seu cluster somente com uma VLAN privada, nenhum endereço IP público será designado aos nós do trabalhador.

   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 cada nó do trabalhador é designado um ID do nó do trabalhador e um nome de domínio exclusivos que não devem ser mudados manualmente após a criação do cluster. Se você alterar o ID ou o nome de domínio, o Red Hat OpenShift mestre não poderá gerenciar seu cluster.

10. Opcional: Se você criou seu cluster em uma região com várias zonas, é possível distribuir o pool de workers padrão entre as zonas para aumentar a disponibilidade do cluster.

11. Após a criação do cluster, é possível começar a trabalhar com seu cluster configurando sua sessão da CLI.

O seu cluster está pronto para as suas cargas de trabalho. Você também pode desejar incluir uma tag em seu cluster, como a equipe ou o departamento de faturamento que usa o cluster, para ajudar a gerenciar os recursos do IBM Cloud.

Exemplo comandos para criar clusters clássicos

Exemplo de comando para criar um cluster Classic na máquina virtual compartilhada

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

Comando de exemplo para criar um cluster Classic no 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>

Exemplo de comando para criar um cluster Classic com o direito de uso “ IBM Cloud Pak ” para um conjunto padrão de 3 nós de trabalho, cada um com 4 núcleos e 16 de memória.

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)]

Exemplo de comando para criar um cluster Classic com nós de trabalho 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

Para um cluster multizona clássico, após criar o cluster em uma região metropolitana multizona, adicione zonas. Exemplo de comando para incluir uma zona em um cluster Clássico

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>

Criando um cluster clássico de zona única com o Terraform

O Terraform no IBM Cloud permite o fornecimento previsível e consistente da infraestrutura e dos recursos da plataforma IBM Cloud, incluindo clusters clássicos. Para criar um cluster clássico com o Terraform, primeiro você cria um arquivo de configuração do Terraform que declara o tipo de recurso de cluster que deseja criar.. Em seguida, aplique o arquivo de configuração do Terraform. Para obter mais informações sobre o Terraform, consulte Sobre o Terraform no IBM Cloud.

Antes de iniciar:

• Instale a CLI do Terraform e o IBM Cloud plug-in do provedor.
• Certifique-se de que você tenha uma chave de API IBM Cloud.

1. Crie um arquivo de provedor do Terraform. Salve o arquivo em seu diretório do Terraform Para obter mais informações, consulte a Documentação do provedor do Terraform IBM Cloud

   Arquivo do provedor Terraform de exemplo.

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

2. Crie um arquivo de configuração do Terraform para um cluster clássico Salve o arquivo em seu diretório do Terraform O exemplo de configuração a seguir cria um cluster clássico com três nós de trabalho em uma zona. Para obter mais informações e opções de configuração de cluster, consulte a documentação do Terraform ibm_container_cluster

   Arquivo de configuração do Terraform de exemplo

   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

   O nome do cluster.

   datacenter

   A zona na qual o cluster será criado. Para ver zonas disponíveis, execute ibmcloud oc zones --provider classic.

   machine_type

   O tipo do nó do trabalhador O tipo determina a quantia de memória, CPU e espaço em disco que está disponível para seus nós do trabalhador. Para obter uma lista de tipos de nós do trabalhador disponíveis, execute ibmcloud oc flavors --zone <zone> --provider classic ou veja Tipos clássicos.

   hardware

   O nível de isolamento de hardware dos seus nós de trabalho. Use dedicated para que os recursos físicos disponíveis sejam dedicados apenas a você ou shared para permitir que eles sejam compartilhados com outros clientes IBM. Essa opção está disponível apenas para os tipos de nós do trabalhador da máquina virtual

   public_vlan_id e private_vlan_id

   Opcional. O ID da VLAN pública ou privada que você deseja usar para seus nós do trabalhador. Para localizar VLANs e sub-redes disponíveis, execute ibmcloud oc vlans --zone <zone>.

   subnet_id

   Opcional. O ID de uma sub-rede existente que você deseja usar para seus nós do trabalhador. Para localizar sub-redes existentes, execute ibmcloud oc subnets --provider classic --zone <zone>..

   default_pool_size

   O número de nós do trabalhador que você deseja incluir no conjunto de trabalhadores padrão..

3. Na CLI, navegue para o seu diretório do Terraform

   cd <terraform_directory>
   

4. Execute os comandos para inicializar e planejar suas ações do Terraform. Revise a saída do plano para assegurar que as ações corretas sejam executadas.

   terraform init
   

   terraform plan
   

5. Aplique os arquivos do Terraform para criar o cluster Em seguida, navegue para o console do IBM Cloud para verificar se o cluster está fornecendo.

   terraform apply