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

Cree su clúster VPC Kubernetes 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.

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.

• Tipo: El flavor define la arquitectura, cantidad de CPU virtual, memoria, GPU y espacio en disco que se configura en cada nodo trabajador y se pone 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 cuentan para el uso de cuota para la 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 tiene previsto desplegar cargas de trabajo de gráficos de IA, visuales o de alta calidad en el clúster, asegúrese de seleccionar un tipo de nodo trabajador de GPU.

Los tipos de sabores adicionales, incluidos los sabores con GPU ( NVIDIA, V100, A100, H100 y H200 ), están disponibles solo 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

Gestione el cifrado de sus nodos de trabajadores habilitando un proveedor de servicios de gestión de claves (KMS) a nivel de grupo de trabajadores. Seleccione la instancia de KMS y el CRN.

Punto final de servicio maestro

Los puntos finales de servicio proporcionan comunicación al maestro. Puede elegir configurar el clúster con un punto final de servicio privado 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.

Protección del tráfico saliente

El comportamiento predeterminado para los clústeres de la versión 1.30 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 apps o servicios que requieren conexión a Internet público, como por ejemplo repositorios GitHub, Docker Hub, tenga en cuenta que debe inhabilitar completamente la protección del tráfico de salida (para que se permita todo el tráfico de salida) o añadir reglas de grupo de seguridad para permitir sólo el tráfico de salida que necesite.

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 trabajador del clúster de VPC en lugar del grupo de seguridad VPC predeterminado. No se aplicará el grupo de seguridad de VPC predeterminado. Para obtener más información, consulte Control del tráfico con grupos de seguridad de VPC.

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.

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 puede 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 clusters VPC desde la CLI

• Asegúrese de completar 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 IBM Cloud Kubernetes Service.
• 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 un ID federado, utilice la opción --sso para conectarse.

   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, conecte una pasarela pública a cada subred.
   • 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 IBM Cloud Kubernetes Service: Subredes.

4. Cree el clúster en la VPC. Puede utilizar el mandato ibmcloud ks 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 ks cluster create vpc-gen2 --name <cluster_name> --zone <vpc_zone> --vpc-id <vpc_ID> --subnet-id <vpc_subnet_ID> --flavor <worker_flavor> [--version <major.minor.patch>][--workers <number_workers_per_zone>] [--sm-group GROUP] [--sm-instance INSTANCE] [--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]
   
   

   --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 ks 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 ks 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 ks 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 los sabores disponibles, primero enumere las zonas VPC disponibles con ibmcloud ks zone ls --provider vpc-gen2, y luego utilice la zona para enumerar los sabores compatibles ejecutando ibmcloud ks 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 <major.minor.patch>

   La versión Kubernetes del nodo maestro del clúster. Para ver las versiones disponibles, ejecute ibmcloud ks versions.

   --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 UBUNTU_20_64|UBUNTU_24_64

   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 Kubernetes. Si no se especifica ninguna opción, se utiliza el sistema operativo predeterminado que corresponde a la versión de clúster.

   --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 secreto de la instancia de Secrets Manager donde se guardan sus 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 Secrets Manager. Para obtener el CRN de una instancia, ejecute ibmcloud ks ingress instance ls --cluster CLUSTER. Incluya esta opción si desea registrar una instancia de Secrets Manager en el clúster.

   --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 cree en esa VPC, la subred predeterminada del pod 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 la subred de pod automáticamente, la asignación se iniciará desde 172.17.0.0, la subred más grande se limita a 13 y el tamaño de subred más pequeño 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, que proporciona suficientes direcciones IP de pod para un máximo de cuatro nodos de trabajador 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 utiliza subredes de rango personalizado para sus nodos de trabajador, debe asegurarse de que las subredes de sus nodos de trabajador no se solapan con la subred del pod de su 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.255.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.255.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 Kubernetes 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.

   --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 ks 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 ks 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 el sabor. 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 ks 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.

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 ks cluster ls
   

   Cuando se completa el suministro del nodo maestro de Kubernetes, el estado del clúster cambia a normal. Cuando el nodo maestro de Kubernetes esté listo, se configuran los nodos trabajadores.

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

6. Compruebe el estado de los nodos trabajadores.

   ibmcloud ks 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   1.32.5_1526
   

   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 maestro de Kubernetes no puede gestionar el 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 ks cluster create vpc-gen2 --name my_cluster --version 1.32_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --flavor bx2.4x16 --workers 3

Mandato de ejemplo para crear un clúster de VPC con 3 nodos trabajadores en us-east-1 con una subred y un tamaño de pod de cliente.

ibmcloud ks cluster create vpc-gen2 --name my_cluster --version 1.32_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --flavor bx2.4x16 --workers 3  -pod-subnet 0.0.0.0/15

Ejemplo de comando para añadir nodos trabajadores añadiendo una zona a un cluster VPC multizona.

ibmcloud ks 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 en IBM Cloud permite un suministro predecible y coherente de los recursos y la infraestructura de la plataforma IBM Cloud, incluidos los clústeres de 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.

Antes de empezar:

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

1. Cree 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. Cree un archivo de configuración de Terraform para un clúster de 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.

   Archivo de configuración de Terraform de ejemplo.

   resource "ibm_container_vpc_cluster" "cluster" {
   name              = "tf-vpc"
   vpc_id            = "<vpc_id>"
   flavor            = "bx2.16x64"
   worker_count      = "3"
   operating_system  = "UBUNTU_20_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 obtener una lista de las 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 ks 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 deKubernetes.

   kube_version

   La versión Kubernetes de su 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 ks subnets --provider classic --zone <zone>.

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

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