Creación de un clúster VPC en la consola

Crea tu clúster de VPC Red Hat OpenShift utilizando la consola IBM Cloud. Siga las instrucciones de la consola para realizar las siguientes configuraciones de clúster. Para empezar a crear tu clúster, ve a la consola y haz clic en Crear clúster.

Nube privada virtual

Seleccione la instancia de Virtual Private Cloud (VPC) existente donde desea crear el clúster. Si no tienes una VPC, puedes crear una.

Ubicación

Revise las Zonas de trabajo y Subredes para el clúster. Las zonas se filtran en función de la VPC que ha seleccionado e incluyen las subredes de VPC que ha creado anteriormente. En función del nivel de disponibilidad que desee para el clúster, seleccione una o más zonas. De forma predeterminada, los recursos de clúster se distribuyen entre tres zonas para la alta disponibilidad. Puede añadir zonas al clúster más adelante.

Versión

Seleccione la versión del clúster. De forma predeterminada, los clústeres se crean con la versión predeterminada de Kubernetes, pero puede especificar una versión soportada diferente.

Licencia

Aplique una titularidad o adquiera una licencia para el clúster. Para obtener más información, consulte Asignación de licencias de software a su cuenta, Adición de Cloud Paks, titularidades o licencias al clúster y Cloud Pak FAQ.

Agrupación de trabajadores

La agrupación de nodos trabajadores del clúster define el número y el tipo de nodos trabajadores que ejecutan la carga de trabajo. Puede cambiar los detalles de la agrupación de nodos trabajadores en cualquier momento.

• Nodos trabajadores por zona: Para la alta disponibilidad, se recomiendan al menos 3 nodos trabajadores por zona.

• Configuración: La configuración define la arquitectura, la cantidad de CPU virtual, la memoria, la GPU y el espacio en disco que se configuran en cada nodo de trabajo y que se ponen a disposición de los contenedores. Los tipos de máquinas nativas y virtuales varían según la zona en la que se despliega el clúster. Para obtener una lista de tipos disponibles, consulte Tipos de VPC.
• Cuando elija un tipo en la consola, puede filtrar los tipos disponibles por Tipo de máquina, Arquitectura y Sistema operativo. Los tipos de máquina disponibles son shared o dedicated. Tenga en cuenta que la opción dedicated solo está disponible si ya tiene una agrupación de hosts dedicados en su cuenta. Para obtener una lista de los sistemas operativos y arquitecturas disponibles por versión de clúster, consulte las versiones disponibles.

• Cifrar disco local: de forma predeterminada, los nodos trabajadores de cuentan con cifrado de disco AES de 256 bits. Puede optar por desactivar el cifrado de disco al crear el clúster. Si habilita el cifrado, cada nodo trabajador de la agrupación de nodos trabajadores se cifra utilizando las credenciales de proveedor KMS que gestiona. Solo se cifran los nodos de la agrupación de nodos trabajadores de default. Una vez creado el clúster, si se crean más agrupaciones de trabajadores, deberá habilitar el cifrado en cada agrupación por separado. Cada agrupación de trabajadores del clúster puede usar la misma instancia de KMS y la misma clave raíz, la misma instancia de KMS con distintas claves raíz o distintas instancias.

• Almacenamiento secundario: puede suministrar un disco secundario a los nodos trabajadores, como un disco de almacenamiento en bloque de 900gb.5iops-tier. Cuando se añade un disco secundario, dicho disco se utiliza para el tiempo de ejecución del contenedor, mientras que el disco primario se utiliza para el sistema operativo. Los discos secundarios son útiles en escenarios en los que se necesita más almacenamiento de contenedor, como ejecutar pods con imágenes de gran tamaño. Tenga en cuenta que al utilizar almacenamiento secundario, es posible que los pods no puedan utilizar todas las capacidades de IOPS/ancho de banda de los volúmenes debido a los sistemas de archivos superpuestos. Los discos secundarios se suministran en su cuenta y puede verlos en la consola de VPC. Los cargos de estos discos son independientes del coste de cada trabajador y se muestran como una línea de detalle diferente en su factura. Estos volúmenes secundarios también se tienen en cuenta a la hora de calcular el uso de la cuota de tu cuenta. Si tiene previsto utilizar almacenamiento secundario en nodos en los que se pueden conectar volúmenes persistentes, se recomienda encarecidamente utilizar los niveles de 10 iops o superior. Esto se debe a que la asignación de ancho de banda de almacenamiento para los nodos se comparte entre los volúmenes de almacenamiento secundarios y las PVC conectadas. Cuando se utilizan 5-iops, los niveles pueden llevar a un rendimiento degradado para extraer imágenes o para pods que escriben en el almacenamiento. Para obtener más información sobre la asignación de ancho de banda, consulte Asignación de ancho de banda en instancias de servidor virtual.

• GPU: Si planea implementar cargas de trabajo de IA, visuales o gráficos de alta calidad en su clúster, asegúrese de seleccionar un tipo de nodo de trabajador GPU.

Los tipos de sabores adicionales, incluidos los sabores con NVIDIA V100, A100, H100, y H200 GPU, solo están disponibles para cuentas incluidas en la lista de permitidos. Para solicitar acceso a otros tipos de la lista de elementos permitidos, solicite acceso a la lista de elementos permitidos.

Cifrado de la agrupación de trabajadores

Gestiona el cifrado de tus nodos de trabajo habilitando un proveedor de servicios de gestión de claves (KMS) a nivel del grupo de nodos de trabajo. Seleccione la instancia de KMS y el CRN.

Módulo de red « 4.20 » o posterior

Selecciona la interfaz de red del contenedor (CNI) que desees utilizar. Elige entre « Calico » y «Open Virtual Network». Ten en cuenta que Open Virtual Network solo está disponible para la versión de clúster de OpenShift 4.20 y posteriores, así como para los nodos de trabajo de RHCOS. Para obtener más información, consulta « Selección de una interfaz de red de contenedor(CNI) ».

Valores de red

Los puntos finales de servicio proporcionan comunicación al maestro. Puede optar por configurar el clúster con un punto final de servicio público o un punto final de servicio de nube público y privado. Para obtener más información sobre la configuración necesaria para ejecutar apps de cara a Internet, o para mantener el clúster privado, consulte Planificación de la configuración de la red del clúster. No puede cambiar los puntos finales del servicio en la nube después de crear el clúster.

Registro interno

Seleccione la instancia de COS. Las imágenes de contenedor almacenadas en el registro interno del clúster Red Hat OpenShift on IBM Cloud se copian automáticamente en un grupo Object Storage. Los datos almacenados en el grupo de almacenamiento de objetos se mantiene incluso si se suprime el clúster.

Protección del tráfico saliente

El comportamiento predeterminado para los clústeres de la versión 4.15 y posteriores es permitir sólo el tráfico de red necesario para que el clúster funcione e inhabilite todas las demás conexiones de salida. Si tiene aplicaciones o servicios que requieren conexión a Internet pública, como GitHub repositorios, Docker Centro,quay.io, el Red Hat Marketplace y OperatorHub, tenga en cuenta que debe deshabilitar completamente la protección del tráfico saliente (para que se permita todo el tráfico saliente) o agregar reglas de grupo de seguridad para permitir solo el tráfico saliente que necesita.

Cifrado de clúster

Habilite el cifrado de datos con un servicio de gestión de claves (KMS) para cifrar secretos y otra información confidencial en el clúster. También puede habilitar KMS más adelante.

Gestión de secretos de Ingress

IBM Cloud Secrets Manager gestiona de forma centralizada los certificados de subdominio de Ingress y otros secretos del clúster. Puede optar por registrar una instancia de Secrets Manager en el clúster durante el proceso de creación del clúster. También puede especificar un grupo de secretos que puede utilizar para controlar el acceso a los secretos del clúster. Ambas opciones se pueden configurar o cambiar después de haber creado el clúster.

Grupos de seguridad de VPC

Proporcione hasta cuatro grupos de seguridad personalizados para aplicarlos a todos los nodos de trabajo del clúster VPC, además del grupo de seguridad kube-<clusterID>. Para obtener más información, consulte Información sobre las redes de clúster VPC seguras por defecto.

Detalles del clúster

Puede personalizar el Nombre de clúster exclusivo y las etiquetas que desee utilizar para organizar e identificar los recursos de IBM Cloud, como team o billing department.

Elija el Grupo de recursos en el que crear el clúster. Un clúster solo se puede crear en un grupo de recursos y, después de crear el clúster, no puede cambiar su grupo de recursos. Para crear clústeres en un grupo de recursos distinto al predeterminado, debe tener al menos el rol de Visor para el grupo de recursos.

Si desea añadir un perfil de confianza existente a su clúster, especifique el ID del perfil de confianza. Si no especifica un perfil de confianza, puede completar el proceso de creación del clúster con una clave API. Consulte Configurar un perfil de confianza para obtener más información.

Integraciones de observabilidad

Puede habilitar integraciones de observabilidad adicionales que desee incluir en el clúster. Algunas integraciones se habilitan automáticamente si tiene una instancia de plataforma existente de dicha integración. En este caso, no es posible desactivar la integración. Si desea utilizar una integración y sólo tiene una instancia de aplicación existente de dicha integración, la integración está inhabilitada de forma predeterminada y debe habilitarla manualmente.

• Registros: Puede utilizar IBM Cloud Logs para gestionar los registros del sistema operativo, los registros de las aplicaciones y los registros de la plataforma. Si desea activar esta integración más adelante, consulte IBM Cloud Logs.

• Monitorización y Protección de la carga de trabajo: La integración del servicio de monitorización permite obtener visibilidad operativa del rendimiento y el estado de sus aplicaciones, servicios y plataformas. Si desactiva esta integración y desea activarla más adelante, consulte Supervisión del estado del clúster. La integración Security and Compliance Center Workload Protection encuentra y prioriza las vulnerabilidades del software, detecta y responde a las amenazas, y gestiona las configuraciones, los permisos y el cumplimiento desde el origen hasta la ejecución. Para obtener más información, consulte la página Protección de la carga de trabajo Inicio.
• Especifique el Tipo de configuración para utilizar instancias nuevas o existentes de Supervisión y protección de la carga de trabajo. Si desea utilizar instancias existentes tanto de Supervisión como de Protección de la carga de trabajo, las instancias de cada integración deben estar conectadas. En este caso, especifique la instancia de Supervisión o de Protección de la carga de trabajo que desea utilizar; no puede especificar ambas instancias, pero ambas se utilizarán siempre que estén conectadas. Puede conectar instancias existentes desde la página de detalles de la instancia Supervisión o Protección de la carga de trabajo.

Creación de clústeres VPC desde la CLI

• Asegúrese de cumplir los requisitos previos para preparar su cuenta y decidir la configuración de su clúster.
• Instale la CLI de IBM Cloud y el plugin de Red Hat OpenShift on IBM Cloud.
• Instale el plugin de CLI de VPC.

1. En la línea de mandatos, inicie una sesión en su cuenta de IBM Cloud y elija como destino la región y grupo de recursos de IBM Cloud donde desea crear el clúster de VPC. Para ver las regiones soportadas, consulte Creación de una VPC en otra región. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si dispone de una identificación federada, utilice la opción --sso para iniciar sesión.

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

2. Create a VPC in the same region where you want to create the cluster. ¿Los clústeres de los nodos trabajadores de la VPC necesitan enviar y recibir información a y desde la infraestructura clásica de IBM Cloud? Siga los pasos de Creación de subredes de VPC para el acceso clásico para crear subredes de VPC y VPC habilitadas para la infraestructura clásica sin los prefijos de dirección predeterminados automáticos.

3. Cree una subred para la VPC.

   • Si desea crear un clúster multizona, repita este paso para crear subredes adicionales en todas las zonas que desee incluir en su clúster.
   • Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
   • No utilice los siguientes rangos reservados: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16.
   • Si los nodos trabajadores deben acceder a puntos finales públicos o si tiene previsto habilitar los puntos finales de servicio de nube pública y privada, debe conectar una pasarela pública a cada subred para acceder a los componentes predeterminados de Red Hat OpenShift como la consola web u OperatorHub.
   • Importante: no suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
   • Para obtener más información, consulte Visión general de la red de VPC en Red Hat OpenShift on IBM Cloud: Subredes.

4. Cree el clúster en la VPC. Puede utilizar el mandato ibmcloud oc cluster create vpc-gen2 para crear un clúster de una sola zona en la VPC con nodos trabajadores que solo estén conectados a una subred de VPC. Si desea crear un clúster multizona, puede utilizar la consola de IBM Cloud o puede añadir más zonas al clúster después de crearlo. El clúster tarda unos minutos en suministrarse.

   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 un nombre para el clúster. El nombre debe empezar por una letra, puede contener letras, números, puntos (.) y guiones (-) y debe tener 35 caracteres como máximo. Utilice un nombre que sea exclusivo entre regiones. El nombre del clúster y la región en la que el clúster se despliega forman el nombre de dominio completo para el subdominio de Ingress. Para garantizar que el subdominio de Ingress es exclusivo dentro de una región, el nombre del clúster se puede truncar y se le puede añadir un valor aleatorio al nombre de dominio de Ingress.

   --zone <zone>

   Especifique la zona de IBM Cloud en la que desea crear el clúster. Asegúrese de utilizar una zona que coincida con la ubicación de la zona metropolitana que ha seleccionado al crear la VPC y de que dispone de una subred de VPC existente para dicha zona. Por ejemplo, si ha creado la VPC en la ciudad metropolitana de Dallas, su zona debe establecerse en us-south-1, us-south-2 o us-south-3. Para obtener una lista de las zonas de clúster de VPC disponibles, ejecute ibmcloud oc zone ls --provider vpc-gen2. Tenga en cuenta que cuando selecciona una zona fuera de su país, es posible que necesite autorización legal para que los datos puedan almacenarse físicamente en un país extranjero.

   --vpc-id <vpc_ID>

   Especifique el ID de la VPC que ha creado anteriormente. Para recuperar el ID de su VPC, ejecute ibmcloud oc vpcs.

   --subnet-id <subnet_ID>

   Especifique el ID de la subred de VPC que ha creado anteriormente. Cuando crea un clúster de VPC desde la CLI, inicialmente puede crear el clúster en una zona con una sola subred. Para crear un clúster multizona, añada más zonas con las subredes creadas anteriormente al clúster una vez creado este. Para listar los ID de las subredes en todos los grupos de recursos, ejecute ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

   --flavor <worker_flavor>

   Especifique el tipo de nodo trabajador que desea utilizar. El tipo determina la cantidad de memoria, espacio de disco y CPU virtual que se configura en cada nodo trabajador y que está disponible para las apps. Los nodos trabajadores de VPC solo se pueden crear como máquinas virtuales en la infraestructura compartida. Las máquinas de almacenamiento nativas o definidas por software no reciben soporte. Para ver las variantes disponibles, primero muestra una lista de las zonas VPC disponibles con ibmcloud oc zone ls --provider vpc-gen2, y a continuación utiliza la zona para mostrar una lista de las variantes compatibles ejecutando ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2. Después de crear el clúster, puede añadir distintos tipos añadiendo un nodo trabajador o una agrupación de nodos trabajadores al clúster.

   --version 4.21_openshift

   La versión de Red Hat OpenShift del nodo maestro del clúster. Para ver las versiones disponibles, ejecute ibmcloud oc versions.

   --cos-instance <cos_CRN>

   Incluya el ID de CRN de una instancia de IBM Cloud Object Storage estándar para realizar una copia de seguridad del registro interno del clúster. Para ver una lista de CRN de las instancias existentes, ejecute ibmcloud resource service-instances --long y busque el ID de la instancia de almacenamiento de objetos. Para crear una instancia de almacenamiento de objetos estándar, ejecute ibmcloud resource service-instance-create <name> cloud-object-storage standard global y anote su ID.

   --workers <number>

   Especifique el número de nodos trabajadores que desea incluir en el clúster. Si no especifica esta opción, se crea un clúster con el valor mínimo de 1.

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS: Opcional. El sistema operativo de los nodos trabajadores del clúster. Para obtener una lista de los sistemas operativos disponibles por versión de clúster, consulte la información de la versión de Red Hat OpenShift on IBM Cloud. Si no se especifica ninguna opción, se utiliza el sistema operativo predeterminado que corresponde a la versión de clúster.

   --offering <offering>

   Opcional. Especifica el tipo de oferta de clúster. Los valores válidos son kubernetes, openshift y openshift-vs. Utiliza openshift-vs para crear un clúster del Servicio de Virtualización de Red Hat OpenShift con capacidades de virtualización preconfiguradas. Para obtener más información, consulta la descripción general del servicio de virtualización de Red Hat OpenShift.

   --cluster-security-group <group_ID>

   Opcional. Especifique uno o más ID de grupo de seguridad para aplicar a todos los trabajadores del clúster. Para OpenShift versión 4.15 y Kubernetes versión 1.30 y posteriores, estos grupos de seguridad se aplican además del grupo de seguridad IBM kube-clusterID. Para versiones anteriores del clúster, especifique la opción --cluster-security-group cluster para aplicar el grupo de seguridad kube-clusterID. Si no se especifica ningún valor, se aplica un conjunto predeterminado de grupos de seguridad que incluye kube-clusterID. Para obtener más información, consulte Adición de grupos de seguridad de VPC a clústeres y agrupaciones de trabajadores durante el tiempo de creación.

   Los grupos de seguridad aplicados a un clúster no se pueden cambiar una vez que se ha creado el clúster. Puede cambiar las reglas de los grupos de seguridad que se aplican al clúster, pero no puede añadir ni eliminar grupos de seguridad a nivel de clúster. Si aplica los grupos de seguridad incorrectos en el momento de crear el clúster, debe suprimir el clúster y crear uno nuevo. Consulte Adición de grupos de seguridad de VPC a clústeres y agrupaciones de trabajadores durante el tiempo de creación para obtener más detalles antes de añadir grupos de seguridad al clúster.

   --sm-group GROUP

   Opcional. El ID del grupo de secretos de la instancia de Secrets Manager donde se almacenan tus secretos. Para obtener un ID de grupo de secretos, consulte la referencia de CLI deSecrets Manager. Utilice esta opción para especificar un grupo de secretos que controle quién de su equipo tiene acceso a los secretos del clúster.

   --sm-instance INSTANCE

   Opcional. El CRN de la instancia de Secrets Manager. Para obtener el CRN de una instancia, ejecute ibmcloud oc ingress instance ls --cluster CLUSTER. Incluya esta opción si desea registrar una instancia de Secrets Manager en el clúster.

   --trusted-profile-id ID

   Especifique el ID de un perfil de confianza existente para asociarlo con el clúster. Con los perfiles de confianza, puede conceder acceso a los recursos de su cuenta sin tener que gestionar credenciales IAM independientes. Consulte Configurar un perfil de confianza para obtener más información.

   --pod-subnet

   En el primer clúster que cree en una VPC, la subred de pod predeterminada es 172.17.0.0/18.

   En el segundo clúster que crees en esa VPC, la subred de pods predeterminada es 172.17.64.0/18. En cada clúster posterior, el rango de subred de pod es la siguiente subred /18 disponible que no se solape. Si tiene previsto conectar el clúster a redes locales mediante IBM Cloud® Direct Link o un servicio VPN, puede evitar conflictos de subred si especifica un CIDR de subred personalizada que proporcione las direcciones IP privadas de los pods.

   Puede especificar el tamaño de subred incluyéndolo en la opción --pod-subnet. Por ejemplo: --pod-subnet 0.0.0.0/X donde X es el tamaño de subred de pod necesario. A continuación, se selecciona automáticamente la subred de pod. Al asignar automáticamente la subred del pod, la asignación comenzará a partir de 172.17.0.0, la subred máxima se limita a 13, y el tamaño mínimo de la subred se limita a 23.

   Cuando elija un tamaño de subred, tenga en cuenta el tamaño del clúster que tiene previsto crear y el número de nodos trabajadores que puede añadir en el futuro. La subred debe tener un CIDR de al menos /23, lo que proporciona suficientes direcciones IP de pod para un máximo de cuatro nodos de trabajo en un clúster. Para clústeres más grandes, utilice /22 para tener suficientes direcciones IP de pod para ocho nodos trabajadores, /21 para tener suficientes direcciones IP de pod para 16 nodos trabajadores, etc. Tenga en cuenta que el pod y las subredes de servicio no se pueden solapar. Si utilizas subredes de rango personalizado para tus nodos de trabajo, debes asegurarte de que las subredes de tus nodos de trabajo no se solapen con la subred de pods de tu clúster. La subred que elija debe estar dentro de uno de los rangos siguientes: 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 todos los servicios que se despliegan en el clúster se les asigna de forma predeterminada una dirección IP en el rango 172.21.0.0/16. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services. La subred debe especificarse en formato CIDR con un tamaño de como mínimo /24, lo que permite un máximo de 255 servicios en el clúster, o mayor. La subred que elija debe estar dentro de uno de los rangos siguientes: 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. Tenga en cuenta que el pod y las subredes de servicio no se pueden solapar.

   --disable-public-service-endpoint

   Incluya esta opción en el mandato para crear el clúster de VPC solo con un punto final de servicio en la nube privado. Si no incluye esta opción, el clúster se configura con un punto final de servicio de nube pública y privada. El punto final de servicio determina cómo se comunican el nodo maestro de Red Hat OpenShift y los nodos trabajadores, cómo accede el clúster a otros servicios y apps de IBM Cloud fuera del clúster y cómo se conectan los usuarios con el clúster. Para obtener más información, consulte Planificación de su configuración de red en clúster. Si incluye esta opción, su clúster se creará con enrutadores y controladores Ingress que, de forma predeterminada, expondrán sus aplicaciones únicamente en la red privada. Si más adelante desea exponer apps en una red pública, debe crear manualmente direccionadores públicos y controladores de Ingress.

   --kms-account-id <KMS_acount_ID>

   Opcional: debe incluirse si se proporcionan las opciones --kms-instance-id y --crk y la instancia de KMS reside en una cuenta distinta de la cuenta del clúster; de lo contrario, se puede omitir. La configuración del cifrado utilizando un KMS de una cuenta diferente sólo está disponible para las cuentas de la lista de elementos permitidos. Para añadirse a la lista de elementos permitidos, abra un caso con soporte.

   --kms-instance <KMS_instance_ID>

   Opcional: incluya el ID de una instancia de servicio de gestión de claves (KMS) que se usa para cifrar el disco local en los nodos de trabajador de la agrupación de trabajadores default. Para obtener una lista de las instancias de KMS disponibles, ejecute ibmcloud oc kms instance ls. Si se incluye esta opción, también habrá que incluir la opción --crk. Para poder usar un cifrado KMS, hay que crear una instancia KMS y configurar la autorización de servicio necesaria en IAM. Consulte Gestión del cifrado de los nodos trabajadores de un clúster.

   --crk <root_key>

   Opcional: incluya el ID de la clave raíz de la instancia de KMS que se usa para cifrar el disco local en los nodos de trabajador de la agrupación de trabajadores default. Para obtener una lista de las claves raíz disponibles, ejecute ibmcloud oc kms crk ls --instance-id. Si se incluye esta opción, también habrá que incluir la opción --kms-instance. Para poder usar un cifrado KMS, hay que crear una instancia KMS y configurar la autorización de servicio necesaria en IAM. Consulte Gestión del cifrado de los nodos trabajadores de un clúster.

   --secondary-storage STORAGE

   Opcional. La opción de almacenamiento para esta variante. Por ejemplo, 900gb.5iops-tier. Cuando se añade un disco secundario, dicho disco se utiliza para el tiempo de ejecución del contenedor, mientras que el disco primario se utiliza para el sistema operativo. Para ver las opciones de almacenamiento para un tipo, ejecute el mandato ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2. Para ver una lista de tipos de nodo trabajador de VPC, consulte Tipos de VPC.

   --disable-outbound-traffic-protection

   Opcional. Desactivar la protección del tráfico saliente.

   --cni CNI

   Configura el plugin de red para el cluster. Calico está configurado de forma predeterminada. Valores aceptados: Calico, OVNKubernetes.

   --offering OFFERING

   Opcional. Especifica el tipo de oferta de clúster. Utiliza openshift-vs para crear un clúster del Servicio de Virtualización de Red Hat OpenShift con capacidades de virtualización preconfiguradas. Si no se especifica nada, se crea un clúster estándar de « OpenShift ». Para obtener más información, consulta la descripción general del servicio de virtualización de Red Hat OpenShift.

5. Verifique que ha solicitado la creación del clúster. La ordenación de las máquinas del nodo trabajador y la configuración y suministro del clúster en su cuenta pueden tardar varios minutos.

   ibmcloud oc cluster ls
   

   Cuando se completa el suministro del maestro deRed Hat OpenShift, el estado del clúster cambia a normal. Cuando el nodo maestro de Red Hat OpenShift está listo, se configuran los nodos trabajadores.

   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. Compruebe el estado de los nodos trabajadores.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Cuando los nodos trabajadores están listos, State del nodo trabajador cambia a normal y Status cambia a Ready. Cuando el campo Status cambia a Ready, puede acceder al clúster. Tenga en cuenta que, aunque el clúster esté listo, algunas partes del clúster que utilizan otros servicios, como por ejemplo los secretos de Ingress o los secretos de obtención de imágenes de registro, podrían estar aún en proceso.

   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 nodo trabajador se la asigna un ID exclusivo y un nombre de dominio que no se debe cambiar de forma manual después de haber creado el clúster. Si cambia el ID o el nombre de dominio, el Red Hat OpenShift maestro no podrá gestionar su clúster.

Mandatos de ejemplo para crear clústeres de VPC

Los tipos con almacenamiento de instancia están disponibles para las cuentas de la lista de elementos permitidos. Para añadirse a la lista de elementos permitidos, abra un caso con soporte.

Mandato de ejemplo para crear un clúster de VPC con 3 nodos trabajadores en 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 de ejemplo para crear un clúster VPC con 3 nodos de trabajador en ' us-east-1 ' con un rango y tamaño de subred de pod personalizado y protección de tráfico saliente desactivada.

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

Mandato de ejemplo para un clúster de VPC con nodos trabajadores que ejecutan el 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 de ejemplo para un clúster VPC con nodos trabajadores que ejecutan el sistema operativo RHEL 9 y la protección del tráfico saliente desactivada.

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

Mandato de ejemplo para crear un clúster con 3 nodos trabajadores en us-south-1 y habilitar el cifrado de disco de nodo trabajador proporcionando el ID de instancia de proveedor de KMS, el ID de cuenta y la 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

Ejemplo de comando para añadir nodos trabajadores añadiendo 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

Creación de un clúster de VPC con Terraform

• Terraform permite un aprovisionamiento predecible y coherente IBM Cloud de la IBM Cloud infraestructura y los recursos de la plataforma, incluidos los clústeres VPC.

• Para crear un clúster de VPC con Terraform, primero debe crear un archivo de configuración de Terraform que declare el tipo de recurso de clúster que desea crear. A continuación, aplique el archivo de configuración de Terraform.

• Para obtener más información sobre Terraform, consulte Acerca de Terraform en IBM Cloud.

• El módulo Terraform IBM- Red Hat OpenShift VPC cluster en IBM Cloud incluye código de infraestructura listo para usar y ejemplos prácticos que pueden acelerar su despliegue. Si desea aprovisionar un entorno OpenShift de nivel empresarial de forma rápida y coherente, este módulo es un buen punto de partida.

Antes de empezar:

• Instale la CLI de Terraform y el plug-in de proveedor IBM Cloud.
• Asegúrese de que dispone de una clave API IBM Cloud.

1. Crear un archivo de proveedor de Terraform. Guarde el archivo en el directorio de Terraform. Para obtener más información, consulte la documentación de Terraform IBM Cloud Provider.

   Archivo de proveedor de Terraform de ejemplo.

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

2. a) Cree un archivo de configuración Terraform para un clúster VPC. Guarde el archivo en el directorio de Terraform. Para obtener más información y opciones de configuración de clúster, consulte la documentación de Terraform ibm_container_cluster.

   Ejemplo de archivo de configuración de 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

   Obligatorio. El nombre del clúster.

   vpc_id

   Obligatorio. El ID de la VPC que desea utilizar para su clúster. Para ver la lista de VPC disponibles, ejecute ibmcloud is vpcs.

   flavor

   Obligatorio. El tipo de nodo trabajador. El tipo determina la cantidad de memoria, CPU y espacio de disco que está disponible para los nodos trabajadores. Para obtener una lista de los tipos de nodo trabajador disponibles, ejecute ibmcloud oc flavors --zone <zone> --provider classic o consulte Tipos clásicos.

   worker_count

   El número de nodos trabajadores que desea añadir a la agrupación de nodos trabajadores predeterminada.

   operating_system

   El sistema operativo de los nodos trabajadores de la agrupación de nodos trabajadores. Para obtener una lista de los sistemas operativos soportados por versión de clúster, consulte Información de versión deRed Hat OpenShift on IBM Cloud.

   kube_version

   La versión Kubernetes de tu clúster. De forma predeterminada, los clústeres se crean con la versión predeterminada de Kubernetes, pero puede especificar una versión soportada diferente.

   resource_group_id

   El ID del grupo de recursos. Para ver los grupos de recursos disponibles, ejecute ibmcloud resource groups. Si no se proporciona ningún valor, se utiliza el grupo de recursos predeterminado.

   zones

   Bloque anidado que describe las zonas de la agrupación de nodos trabajadores predeterminada del clúster de VPC.

   • subnet_id: Obligatorio. El ID de la subred de VPC que desea utilizar para los nodos trabajadores. Para buscar subredes existentes, ejecute ibmcloud oc subnets --provider classic --zone <zone>.

   • name: Obligatorio. El nombre de zona para la agrupación de nodos trabajadores predeterminada. Para ver las zonas disponibles, ejecuta ibmcloud oc zones --provider vpc-gen2.

   b) Alternativamente, si prefiere utilizar Módulos Terraform IBM, puede consultar el siguiente ejemplo para aprovisionarse Red Hat OpenShift Clúster en 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. En la CLI, vaya al directorio de Terraform.

   cd <terraform_directory>
   

4. Ejecute los mandatos para inicializar y planificar las acciones de Terraform. Revise la salida del plan para asegurarse de que se realizan las acciones correctas.

   terraform init
   

   terraform plan
   

5. Aplique los archivos de Terraform para crear el clúster. A continuación, vaya a la consola de IBM Cloud para comprobar que el clúster se está suministrando.

   terraform apply