Criação de um cluster VPC no console

Crie seu cluster do Red Hat OpenShift na VPC usando o console do IBM Cloud. Siga as instruções do console para fazer as configurações de cluster a seguir: Para começar a criar o cluster, navegue até o console e clique em Create cluster (Criar cluster ).

Virtual Private Cloud

Selecione a instância existente do Virtual Private Cloud (VPC) na qual você deseja criar seu cluster. Se você não tiver uma VPC, pode criar uma.

Local

Revise as Zonas do trabalhador e Sub-redes para seu cluster. As zonas são filtradas com base no VPC que você selecionou e inclua as sub-redes de VPC que criou anteriormente. Dependendo do nível de disponibilidade desejado para seu cluster, selecione uma ou mais zonas. Por padrão, seus recursos de cluster são difundidos entre três zonas para alta disponibilidade É possível incluir zonas no cluster posteriormente.

Versão

Selecione a sua versão do cluster Por padrão, os clusters são criados com a versão padrão do Kubernetes, mas é possível especificar uma versão suportada diferente

Licença

Aplique uma autorização ou compre uma licença para o seu cluster Para obter mais informações, consulte Designando licenças de software para sua conta, Incluindo Cloud Paks, autorizações ou licenças para seu cluster e o Cloud Pak FAQ.

Conjunto do trabalhador

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

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

• Flavor: O flavor define a arquitetura, a quantidade de CPU virtual, a memória, a GPU e o espaço em disco que são configurados em cada nó de trabalho e disponibilizados 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. Para obter uma lista de tipos disponíveis, consulte Tipos de VPC
• Ao escolher um tipo no console, é possível filtrar os tipos disponíveis por Tipo de máquina, Arquitetura e Sistema operacional. Os tipos de máquina disponíveis são shared ou dedicated Observe que a opção dedicated estará disponível apenas se você já tiver um conjunto de hosts dedicadas em sua conta Para obter uma lista dos sistemas operacionais e arquiteturas disponíveis por versão do cluster, consulte as versões disponíveis

• 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. Se você ativar a criptografia, cada nó do trabalhador no conjunto de trabalhadores será criptografado usando as credenciais do provedor do KMS que você gerencia Somente os nós do conjunto de trabalhadores do default são criptografados Depois de criar o cluster, se você criar mais conjuntos de trabalhadores, deverá ativar a criptografia em cada conjunto separadamente. Cada conjunto de trabalhadores em seu cluster usa a mesma instância do KMS e chave raiz, a mesma instância do KMS com chaves raiz diferentes ou instâncias diferentes.

• Armazenamento Secundário: é possível provisionar um disco secundário para os nós do trabalhador, como um disco de armazenamento de bloco do 900gb.5iops-tier. Ao adicionar um disco secundário, esse disco é usado para o tempo de execução do container, enquanto que o disco primário é usado para o sistema operacional. Discos secundários são úteis em cenários em que mais armazenamento de contêiner é necessário, como pods em execução com imagens grandes. Observe que, ao usar o armazenamento secundário, os pods podem não ser capazes de usar todos os recursos de IOPS/largura de banda dos volumes devido aos sistemas de arquivos sobrepostos. Os discos secundários são provisionados em sua conta e é possível vê-los no console da VPC Os encargos para esses discos são separados do custo de cada trabalhador e mostrados como um item de linha diferente em sua conta. Esses volumes secundários também são contabilizados no uso da cota da sua conta. Se você planeja usar o armazenamento secundário em nós nos quais volumes persistentes podem ser conectados, é altamente recomendado usar as camadas de 10 iops ou superior. Isso ocorre porque a alocação de banda de armazenamento para os nós é compartilhada entre volumes de armazenamento secundários e quaisquer PVCs conectados. Ao usar 5-iops, as camadas podem levar a um desempenho degradado para extrair imagens ou para gravação de pods no armazenamento. Para obter mais informações sobre alocação de largura de banda, consulte Alocação de largura de banda em instâncias de servidor virtual.

• GPU: Se você planeja implementar cargas de trabalho de IA, visuais ou gráficas de alta qualidade em seu cluster, certifique-se de selecionar uma variante de nó de trabalho de GPU.

Tipos de sabores adicionais, incluindo sabores com GPUs, A100NVIDIAV100 H100H200, e, estão disponíveis apenas para contas incluídas na lista de permissões. Para solicitar acesso a outros tipos incluídos na lista de permissões, solicite acesso à lista de permissões.

Criptografia do conjunto de trabalhadores

Gerencie a criptografia dos seus nós de trabalho ativando um provedor de serviço de gerenciamento de chaves (KMS) no nível do pool de nós de trabalho. Selecione sua instância do KMS e CRN.

Plug-in de rede 4.20 ou versão posterior

Selecione a interface de rede do contêiner (CNI) que você deseja usar. Escolha entre “ Calico ” e “Open Virtual Network”. Observe que o Open Virtual Network está disponível apenas para a versão de cluster do OpenShift ( 4.20 ) e versões posteriores, bem como para nós de trabalho do RHCOS. Para obter mais informações, consulte “Seleção de uma interface de rede de contêiner(CNI) ”.

Configurações de rede

Os terminais de serviço fornecem comunicação para o principal É possível optar por configurar seu cluster com um terminal em serviço público ou um terminal em serviço de nuvem 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 endpoints do serviço de nuvem depois de criar o cluster.

Registro interno

Selecione a sua instância do COS As imagens de contêiner armazenadas no registro interno do cluster do Red Hat OpenShift on IBM Cloud são submetidas a backup automaticamente para um depósito do Object Storage. Todos os dados armazenados no bucket de armazenamento de objetos permanecem, mesmo quando você exclui o cluster.

Proteção do tráfego de saída

O comportamento padrão para clusters na versão 4.15 e posterior é permitir apenas o tráfego de rede necessário para o cluster funcionar e desativar todas as outras conexões de saída. Se você tiver aplicativos ou serviços que exijam conexão à Internet pública, como GitHub repositórios, Docker Eixo,quay.io, o Red Hat Marketplace e OperatorHub, observe que você deve desabilitar completamente a proteção do tráfego de saída (para que todo o tráfego de saída seja permitido) ou adicionar regras de grupo de segurança para permitir apenas o tráfego de saída necessário.

Criptografia de cluster

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.

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.

Grupos de segurança de VPC

Forneça até quatro grupos de segurança personalizados para aplicar a todos os nós de trabalho no cluster VPC, além do grupo de segurança “ kube-<clusterID> ”. Para obter mais informações, consulte Noções básicas sobre a rede VPC de cluster Secure by Default.

Detalhes do cluster

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

Escolha o Grupo de recursos no qual criar seu cluster 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. 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.

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: É possível 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 e Proteção de carga de trabalho: a integração do serviço de monitoramento permite visibilidade operacional do desempenho e da integridade de seus aplicativos, serviços e plataformas. Se você desativar essa integração e quiser ativá-la posteriormente, consulte Monitoramento da integridade do cluster. A integração do Security and Compliance Center com o Workload Protection encontra e prioriza vulnerabilidades de software, detecta e responde a ameaças e gerencia configurações, permissões e conformidade desde a origem até a 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 instâncias existentes na página de detalhes da instância Monitoramento ou Proteção de carga de trabalho.

Criação de clusters de VPC pela CLI

• Certifique-se de cumprir os pré-requisitos para preparar sua conta e definir a configuração do seu cluster.
• Instale a CLI da IBM Cloud e o plug-in do Red Hat OpenShift on IBM Cloud.
• Instale o plug-in da CLI da VPC.

1. Em sua linha de comandos, efetue login em sua conta da IBM Cloud e vise a região e o grupo de recursos da IBM Cloud nos quais você deseja criar seu cluster de VPC. Para ver as regiões suportadas, consulte Criando uma VPC em uma região diferente. Insira suas credenciais do IBM Cloud quando solicitadas. Se você tiver uma identificação federada, use a opção “ --sso ” para fazer login.

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

2. Crie uma VPC na mesma região na qual deseja criar o cluster. Os clusters de nós do trabalhador em sua VPC precisam enviar e receber informações para e da infraestrutura clássica da IBM Cloud? Siga as etapas em Criando sub-redes VPC para acesso clássico para criar uma VPC ativada para clássico e sub-redes VPC sem os prefixos automáticos de endereço padrão.

3. Crie uma sub-rede para sua VPC.

   • Se você quiser criar um cluster multizona, repita esta etapa para criar sub-redes adicionais em todas as zonas que deseja incluir no seu cluster.
   • As sub-redes VPC fornecem endereços IP para os seus nós do trabalhador e serviços de balanceador de carga no cluster, portanto, crie uma sub-rede VPC com endereços IP suficientes, como 256. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois.
   • Não use os intervalos reservados a seguir: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16.
   • Se os nós do trabalhador devem acessar terminais públicos, ou se você planeja ativar ambos os terminais de serviço de nuvem pública e privada, deve-se conectar um gateway público em cada sub-rede para acessar componentes padrão do Red Hat OpenShift, como o console da web ou o OperatorHub.
   • Importante: não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.
   • Para obter mais informações, consulte Visão geral da rede de VPC em Red Hat OpenShift on IBM Cloud: sub-redes.

4. Crie o cluster em seu VPC. É possível usar o comando ibmcloud oc cluster create vpc-gen2 para criar um cluster de zona única em sua VPC com nós do trabalhador que estão conectados a somente uma sub-rede VPC. 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. Ele leva alguns minutos para ser provisionado.

   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>

   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.

   --zone <zone>

   Especifique a zona do IBM Cloud na qual deseja criar seu cluster. Certifique-se de usar uma zona que corresponda ao local da cidade metropolitana selecionada na criação de seu VPC e ter uma sub-rede existente do VPC para ela. Por exemplo, se você criou seu VPC na cidade metropolitana de Dallas, sua zona deverá ser configurada como us-south-1, us-south-2 ou us-south-3. Para listar zonas de cluster VPC disponíveis, execute ibmcloud oc zone ls --provider vpc-gen2. Observe que, ao selecionar uma zona fora de seu país, uma autorização jurídica poderá ser necessária antes de armazenar fisicamente os dados em um país estrangeiro.

   --vpc-id <vpc_ID>

   Insira o ID do VPC criado anteriormente. Para recuperar o ID da sua VPC, execute ibmcloud oc vpcs.

   --subnet-id <subnet_ID>

   Insira o ID da sub-rede do VPC criada anteriormente. Ao criar um cluster de VPC por meio da CLI, é possível criar inicialmente seu cluster em uma zona com uma sub-rede somente. Para criar o cluster multizona, inclua mais zonas com as sub-redes criadas anteriormente em seu cluster após ele ser criado. Para listar os IDs de suas sub-redes em todos os grupos de recursos, execute ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

   --flavor <worker_flavor>

   Insira o tipo de nó do trabalhador que você deseja usar. 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 da VPC podem ser criados como máquinas virtuais somente em infraestrutura compartilhada. As máquinas de armazenamento bare metal ou definidas por software não são suportadas. Para visualizar os flavors disponíveis, primeiro liste as zonas de VPC disponíveis com o comando ibmcloud oc zone ls --provider vpc-gen2 e, em seguida, use a zona para listar os flavors compatíveis executando o comando ` `ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2. Depois de criar o cluster, é possível incluir diferentes tipos, incluindo um nó do trabalhador ou um conjunto de trabalhadores no cluster.

   --version 4.21_openshift

   A versão do Red Hat OpenShift para o nó do cluster mestre. Para ver as versões disponíveis, execute ibmcloud oc versions.

   --cos-instance <cos_CRN>

   Inclua o ID do CRN de uma instância IBM Cloud Object Storage padrão para fazer backup do registro interno do seu cluster. Para listar o CRN de instâncias existentes, execute ibmcloud resource service-instances --long e localize o ID da sua instância de armazenamento de objetos. Para criar uma instância de armazenamento de objetos padrão, execute ibmcloud resource service-instance-create <name> cloud-object-storage standard global e observe seu ID.

   --workers <number>

   Especifique o número de nós do trabalhador a serem incluídos no cluster. Se você não especificar essa opção, um cluster com o valor mínimo de um será criado.

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS: Opcional. O sistema operacional dos nós do trabalhador no cluster. Para obter uma lista dos sistemas operacionais disponíveis por versão do cluster, consulte as informações da versão Red Hat OpenShift on IBM Cloud. Se nenhuma opção for especificada, o sistema operacional padrão que corresponde à versão do cluster será usado

   --offering <offering>

   Opcional. Especifique o tipo de oferta de cluster. Os valores aceitos são kubernetes, openshift e openshift-vs. Use o openshift-vs para criar um cluster do Serviço de Virtualização Red Hat OpenShift com recursos de virtualização pré-configurados. Para obter mais informações, consulte a visão geral do Serviço de Virtualização do Red Hat OpenShift.

   --cluster-security-group <group_ID>

   Opcional. Especifique um ou mais IDs de grupo de segurança para aplicar a todos os trabalhadores no cluster. Para OpenShift versão 4.15 e Kubernetes versão 1.30 e mais recente, esses grupos de segurança são aplicados além do grupo de segurança IBM kube-clusterID. Para versões anteriores do cluster, especifique a opção --cluster-security-group cluster para aplicar o grupo de segurança do kube-clusterID Se nenhum valor for especificado, um conjunto padrão de grupos de segurança incluindo kube-clusterID será aplicado. Para obter mais informações, consulte Incluindo grupos de segurança VPC em clusters e conjuntos de trabalhadores durante o tempo de criação.

   Os grupos de segurança aplicados a um cluster não podem ser mudados após a criação do cluster. É possível mudar as regras dos grupos de segurança que são aplicadas ao cluster, mas não é possível incluir ou remover grupos de segurança no nível do cluster. Se você aplicar os grupos de segurança incorretos no tempo de criação do cluster, deverá excluir o cluster e criar um novo. Veja Incluindo grupos de segurança VPC em clusters e conjuntos de trabalhadores durante o tempo de criação para obter mais detalhes antes de incluir grupos de segurança em seu cluster.

   --sm-group GROUP

   Opcional. 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. Use essa opção para especificar um grupo de segredos que controla quem em sua equipe tem acesso aos segredos do cluster

   --sm-instance INSTANCE

   Opcional. O CRN da instância do Secrets Manager. Para obter o CRN de uma instância, execute ibmcloud oc ingress instance ls --cluster CLUSTER. Inclua esta opção se você quiser registrar uma instância Secrets Manager para o 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.

   --pod-subnet

   No primeiro cluster que você cria em uma VPC, a sub-rede de pod padrão é 172.17.0.0/18.

   No segundo cluster que você criar nessa VPC, a sub-rede padrão dos pods é 172.17.64.0/18. Em cada cluster subsequente, o intervalo de sub-rede do pod é a próxima sub-rede disponível não sobreposta /18. 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.

   É possível especificar o tamanho da sub-rede incluindo-o na opção --pod-subnet. Por exemplo: --pod-subnet 0.0.0.0/X em que X é o tamanho de sub-rede do pod necessário. Em seguida, a sub-rede do pod é selecionada automaticamente. Ao alocar a sub-rede do pod automaticamente, a alocação começará em 172.17.0.0, a sub-rede máxima é limitada a 13 e o tamanho mínimo da sub-rede é limitado a 23.

   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, o que fornece endereços IP de pod suficientes para um máximo de quatro nós de trabalho 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. Se você utilizar sub-redes com intervalo personalizado para seus nós de trabalho, é necessário garantir que as sub-redes desses nós não se sobreponham à sub-rede de pods do seu cluster. A sub-rede escolhida deve estar em um dos seguintes intervalos: 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, que permite um máximo de 255 serviços no cluster, ou maior. A sub-rede escolhida deve estar em um dos seguintes intervalos: 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

   --disable-public-service-endpoint

   Inclua essa opção em seu comando para criar o seu cluster de VPC somente com um terminal em serviço de nuvem privada. Se você não incluir essa opção, o cluster será configurado com um terminal em serviço de nuvem pública e privada. O terminal em serviço determina como o seu mestre do Red Hat OpenShift e os nós do trabalhador se comunicam, como seu cluster acessa outros serviços e apps da IBM Cloud fora do cluster e como seus usuários se conectam ao seu cluster. Para obter mais informações, consulte Planejando a configuração de rede do cluster. Se você incluir essa opção, seu cluster será criado com roteadores e controladores Ingress que, por padrão, expõem seus aplicativos apenas na rede privada. Se posteriormente você quiser expor aplicativos para uma rede pública, deverá criar manualmente roteadores públicos e controladores do Ingress.

   --kms-account-id <KMS_acount_ID>

   Opcional: Deve ser incluído se as opções --kms-instance-id e --crk forem fornecidas e a instância do KMS residir em uma conta diferente da conta do cluster, caso contrário, ele poderá ser omitido. A configuração de criptografia usando um KMS de uma conta diferente está disponível apenas para contas permitidas. Para ser incluído na lista de allowlist, abra um case com suporte.

   --kms-instance <KMS_instance_ID>

   Opcional: inclua o ID de uma instância de serviço de gerenciamento de chaves (KMS) para criptografar o disco local nos nós do trabalhador no conjunto de trabalhadores default. Para listar instâncias do KMS disponíveis, execute ibmcloud oc kms instance ls. Ao incluir esta opção, é preciso também incluir a opção --crk. Antes de usar a criptografia KMS, é preciso criar uma instância KMS e configurar a autorização de serviço necessária no IAM. Consulte Gerenciando a criptografia para os nós de processamento em seu cluster.

   --crk <root_key>

   Opcional: inclua o ID da chave raiz na instância do KMS para criptografar o disco local nos nós do trabalhador no conjunto de trabalhadores default. Para listar chaves raiz disponíveis, execute ibmcloud oc kms crk ls --instance-id. Ao incluir esta opção, é preciso também incluir a opção --kms-instance. Antes de usar a criptografia KMS, é preciso criar uma instância KMS e configurar a autorização de serviço necessária no IAM. Consulte Gerenciando a criptografia para os nós de processamento em seu cluster.

   --secondary-storage STORAGE

   Opcional. A opção de armazenamento para o sabor. Por exemplo, 900gb.5iops-tier. Ao adicionar um disco secundário, esse disco é usado para o tempo de execução do container, enquanto que o disco primário é usado para o sistema operacional. Para visualizar as opções de armazenamento para um aroma, execute o comando ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2. Para visualizar uma lista de tipos de nós do trabalhador do VPC, consulte Tipos de VPC

   --disable-outbound-traffic-protection

   Opcional. Desativar a proteção do tráfego de saída.

   --cni CNI

   Defina o plug-in de rede para o cluster. Calico está definido por padrão. Valores aceitos: Calico, OVNKubernetes.

   --offering OFFERING

   Opcional. Especifique o tipo de oferta de cluster. Use o openshift-vs para criar um cluster do Serviço de Virtualização Red Hat OpenShift com recursos de virtualização pré-configurados. Se não for especificado, será criado um cluster padrão do OpenShift. Para obter mais informações, consulte a visão geral do Serviço de Virtualização do Red Hat OpenShift.

5. Verifique se a criação do cluster foi solicitada. Pode levar alguns minutos para que as máquinas do nó do trabalhador sejam solicitadas e para que o cluster seja configurado e provisionado em sua conta.

   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 mestre do Red Hat OpenShift estiver pronto, seus nós do trabalhador serão configurados.

   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. 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 Ready. Quando o nó Status mudar para Ready, será possível 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.

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

Exemplo comandos para criar clusters VPC

Tipos com armazenamento de instância estão disponíveis para contas incluídas na lista de permissões. Para ser incluído na lista de permissões, abra um caso com o suporte.

Comando de exemplo para criar um cluster de VPC com 3 nós do trabalhador no 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

Exemplo de comando para criar um cluster VPC com 3 nós de trabalho em " us-east-1 com um intervalo e tamanho de sub-rede de pod personalizado e proteção de tráfego de saída desativada.

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

Exemplo de comando para um cluster de VPC com nós do trabalhador que executam o sistema operacional 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

Exemplo de comando para um cluster VPC com nós de trabalho que executam o sistema operacional RHEL 9 e proteção de tráfego de saída desativada.

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 de exemplo para criar um cluster com 3 nós do trabalhador em us-south-1 e ativar a criptografia de disco do nó do trabalhador fornecendo seu ID da instância do provedor KMS, ID da conta 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

Exemplo de comando para adicionar nós de trabalho adicionando uma zona a um cluster de VPC multizona.

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

Criando um cluster VPC com o Terraform

• O IBM Cloud Terraform permite o provisionamento previsível e consistente da infraestrutura IBM Cloud e dos recursos da plataforma, incluindo clusters VPC.

• Para criar um cluster de VPC 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 em IBM Cloud.

• O Terraform IBM Module - Red Hat OpenShift VPC cluster em IBM Cloud inclui código de infraestrutura pronto para uso e exemplos práticos que podem acelerar sua implantação. Se você deseja provisionar um ambiente OpenShift de nível empresarial de forma rápida e consistente, este módulo é um ótimo ponto de partida.

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. a) Crie um arquivo de configuração do Terraform para um cluster VPC. Salve o arquivo em seu diretório do Terraform Para obter mais informações e opções de configuração de cluster, consulte a documentação do Terraform ibm_container_cluster

   Exemplo de arquivo de configuração do 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

   Obrigatório. O nome do cluster.

   vpc_id

   Obrigatório. O ID da VPC que você deseja usar para o seu cluster. Para listar as VPCs disponíveis, execute o comando ibmcloud is vpcs``.

   flavor

   Obrigatório. 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.

   worker_count

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

   operating_system

   O sistema operacional dos nós do trabalhador no conjunto de trabalhadores Para obter uma lista de sistemas operacionais suportados por versão do cluster, consulte Informações da versão Red Hat OpenShift on IBM Cloud

   kube_version

   A versão do seu cluster no Kubernetes. Por padrão, os clusters são criados com a versão padrão do Kubernetes, mas é possível especificar uma versão suportada diferente

   resource_group_id

   O ID do grupo de recursos. Para ver os grupos de recursos disponíveis, execute o comando ibmcloud resource groups``. Se nenhum valor for fornecido, o grupo de recursos padrão será usado

   zones

   Um bloco aninhado que descreve as zonas do conjunto de trabalhadores padrão do cluster de VPC

   • subnet_id: necessário. O ID da sub-rede de VPC que você deseja usar para seus nós do trabalhador... Para localizar sub-redes existentes, execute ibmcloud oc subnets --provider classic --zone <zone>..

   • name: Obrigatório. O nome da zona para o conjunto de trabalhadores padrão Para ver as zonas disponíveis, execute o comando ibmcloud oc zones --provider vpc-gen2``.

   b) Como alternativa, se preferir usar o site Terraform IBM Módulos, você pode consultar o exemplo abaixo para provisionar Red Hat OpenShift Cluster na 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. 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