Uso de la consola para crear un cluster con una configuración definida explícitamente en el flujo de trabajo "Creación personalizada"

Descubra cómo utilizar el flujo de trabajo "Creación personalizada" para crear un cluster de Kubernetes con una configuración definida explícitamente y recursos de red existentes mediante Kubernetes Engine (OKE).

Para crear un cluster con una configuración definida explícitamente y recursos de red existentes en el flujo de trabajo "Creación personalizada" mediante Kubernetes Engine:

1. En la página de lista Clusters, seleccione Crear cluster. Si necesita ayuda para encontrar la página de lista, consulte Listing Clusters.
2. En el recuadro de diálogo Crear clúster, seleccione Creación personalizada y seleccione Continuar.

3. En la página de creación de cluster, acepte los detalles de configuración por defecto para el nuevo cluster o especifique alternativas de las siguientes formas:

   • Nombre: el nombre del nuevo cluster. Acepte el nombre por defecto o introduzca un nombre de su elección. Evite introducir información confidencial.
   • Compartimento: compartimento en el que se va a crear el nuevo cluster.
   • versión de Kubernetes: la versión de Kubernetes que se va a ejecutar en los nodos en el plano del control del clúster. Acepte la versión por defecto o seleccione la versión que desee. Entre otras cosas, la versión de Kubernetes seleccionada determina el juego por defecto de controladores de admisión activados en el cluster creado (consulte Controladores de admisión admitidos).

4. Acepte los valores por defecto de las opciones avanzadas de cluster o seleccione Opciones avanzadas y defina los valores de la siguiente forma:

   1. Verificación de imagen: especifique si solo se permite el despliegue de imágenes de Oracle Cloud Infrastructure Registry que han sido firmadas por claves de cifrado maestras concretas. Para aplicar el uso de imágenes firmadas, seleccione Activar políticas de verificación de imágenes en este cluster y, a continuación, especifique la clave de cifrado y el almacén que la contiene. Consulte Aplicación del Uso de Imágenes Firmadas del Registro.

   2. Cifrado de secretos de Kubernetes: especifique cómo cifrar secretos de Kubernetes estáticos en el almacén de clave-valor etcd para el cluster:

      • Cifrar mediante una clave gestionada por Oracle: cifre los secretos de Kubernetes en el almacén de clave-valor etcd mediante una clave de cifrado maestra gestionada por Oracle.

      • Cifre mediante una clave que gestione: cifre los secretos de Kubernetes en el almacén de clave-valor etcd mediante una clave de cifrado maestra (almacenada en el servicio Vault) que gestione. Si selecciona esta opción, especifique:

        • Seleccionar un archivo nativo: el almacén que contiene la clave del cifrado maestra, de la lista de almacenes en el compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento.
        • Seleccionar una clave: nombre de la clave de cifrado principal, de la lista de claves en el compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento. Tenga en cuenta que no puede cambiar la clave de cifrado maestra una vez creado el cluster.

      Tenga en cuenta que si desea gestionar la clave de cifrado maestra, ya debe existir una clave, un grupo dinámico y una política adecuados para poder crear el cluster. Para obtener más información, consulte Cifrado de secretos estáticos de Kubernetes en etcd.

   3. Políticas de seguridad de pod:(versiones de Kubernetes anteriores a la versión 1.25) especifique si desea controlar las operaciones que los pods pueden realizar en el cluster aplicando políticas de seguridad de pod:

      • No aplicadas: no se aplican las políticas de seguridad de pod.
      • Aplicadas: aplique las políticas de seguridad de pod mediante la activación del controlador de admisión PodSecurityPolicy. El cluster solo acepta los pods que cumplen las condiciones de una política de seguridad de pod. Para obtener más información, consulte Uso de políticas de seguridad de pod con Kubernetes Engine (OKE).
      Atención
      
      

      Es muy importante tener en cuenta que cuando activa el controlador de admisión PodSecurityPolicy de un cluster, no se puede iniciar ningún pod de aplicación en el cluster a menos que existan políticas de seguridad de pod adecuadas, junto con Roles (o ClusterRoles) y RoleBindings (o ClusterRoleBindings) para asociar pods a políticas. No podrá ejecutar pods de aplicación en un cluster con un controlador de admisión PodSecurityPolicy activado, a menos que se cumplan estos requisitos.

      Se recomienda utilizar controladores de admisión de PodSecurityPolicy de la siguiente manera:

      • Siempre que cree un nuevo cluster, active el controlador de admisión de seguridad de pod.
      • Inmediatamente después de crear un nuevo cluster, cree políticas de seguridad de pod, junto con Roles (o ClusterRoles) y RoleBindings (o ClusterRoleBindings).
   4. Configurar complementos de clúster: (solo clusters mejorados) activa o desactiva complementos específicos, selecciona versiones de complementos, elige o descarte las actualizaciones automáticas de Oracle y gestiona las personalizaciones específicas de complementos. Seleccione Editar en el menú Acciones (tres puntos) junto a un complemento de cluster y defina las opciones de configuración según corresponda. Consulte Configuring Cluster Add-ons.
   5. OpenID Detección de Connect (OIDC): (solo clusters mejorados) especifique si desea activar el cluster para la detección de OIDC. Seleccione Activar detección de OIDC para permitir que los pods de aplicaciones que se ejecutan en el cluster se autentiquen mediante la detección de OIDC al acceder a las API alojadas en un proveedor de nube externo. Consulte Autorización de pods para acceder a recursos no OCI mediante la detección de OpenID Connect (OIDC).
   6. Etiquetado: especifique si desea agregar etiquetas de cluster al cluster, etiquetas de equilibrador de carga iniciales a los equilibradores de carga creados por los servicios de Kubernetes del tipo LoadBalancer y etiquetas de volumen en bloque iniciales para volúmenes en bloque creados por reclamaciones de volumen persistentes de Kubernetes. El etiquetado permite agrupar recursos dispares en compartimentos y, además, permite anotar recursos con sus propios metadatos. Consulte Etiquetado de recursos relacionados en clusters de Kubernetes.

5. Seleccione Next (Siguiente) y especifique los recursos que se utilizarán para el nuevo cluster en la página Network Setup:

   • Tipo de red: especifique cómo los pods que se ejecutan en los nodos del cluster se comunican entre sí, con los nodos del plano de control del cluster, con los pods en otros clusters, con otros servicios (como los servicios de almacenamiento) y con Internet (consulte Redes de pod). Seleccione una de las opciones siguientes:
     • Redes de pods nativas de VCN: seleccione esta opción para conectar nodos de un cluster de Kubernetes a subredes de pod en una VCN de Oracle Cloud Infrastructure. Como resultado, las direcciones IP de pod dentro de una VCN son direccionables directamente desde otras redes virtuales en la nube conectadas (con intercambio de tráfico) a esa VCN y desde redes locales. Puede crear nodos virtuales y nodos gestionados si selecciona esta opción. Consulte Using the OCI VCN-Native Pod Networking CNI plugin para redes de pod.
     • Superposición de franela: seleccione esta opción para encapsular la comunicación entre pods en la red de superposición de franela, una red virtual de superposición privada simple que cumple los requisitos del modelo de red de de Kubernetes asociando direcciones IP a contenedores. Solo se puede acceder a los pods de la red privada de superposición desde otros pods del mismo cluster. Puede crear nodos gestionados (pero no nodos virtuales) si selecciona esta opción. Consulte Uso del plugin flannel CNI para redes de pod.
   • VCN: seleccione la red virtual en la nube existente que se ha configurado para la creación y el despliegue del cluster en la lista de redes virtuales en la nube del compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento. Consulte Configuración de VCN.
   • Subred de punto final de API de Kubernetes: seleccione una subred regional para alojar el punto final de API de Kubernetes del cluster, en la lista de subredes del compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento. La subred que especifique puede ser pública o privada. El punto final del API de Kubernetes siempre tiene asignada una dirección IP privada. Si especifica una subred pública, también puede exponer el punto final de API de Kubernetes a Internet asignando una dirección IP pública al punto final (así como la dirección IP privada). Para simplificar la gestión de acceso, Oracle recomienda que el punto final de API de Kubernetes se encuentre en una subred diferente a los nodos de trabajador y los equilibradores de carga. Para obtener más información, consulte Plano de control de cluster de Kubernetes y API de Kubernetes.
   • Usar reglas de seguridad en el grupo de seguridad de red (NSG): controlar el acceso al punto final de API de Kubernetes del cluster mediante reglas de seguridad definidas para uno o más grupos de seguridad de red (NSG) que especifique. Puede utilizar reglas de seguridad definidas para los NSG en lugar de las definidas para las listas de seguridad (se recomiendan los NSG). Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para el punto final de API de Kubernetes.
   • Asignar automáticamente la dirección IPv4 pública: si ha seleccionado una subred pública para el punto final de API de Kubernetes, puede exponer el punto final a Internet asignando una dirección IP pública al punto final. Si no asigna una dirección IP pública, actualice las reglas de ruta y las reglas de seguridad para permitir el acceso al punto final mediante un gateway de servicio y un gateway de NAT (consulte Configuración de subred de punto final de API de Kubernetes).
   • Asignar automáticamente la dirección IPv6 de los prefijos de subred: si ha seleccionado una subred de pila doble IPv4/IPv6 para el punto final de API de Kubernetes, puede asignar opcionalmente una dirección IPv6 al punto final para que el cluster sea un cluster de pila doble. Si selecciona esta opción, la dirección IPv6 para el punto final se selecciona automáticamente del primer prefijo IPv6 asignado a la subred. Para obtener más información, consulte Enabling Clusters for IPv4 and IPv6.

   • Subredes de equilibrador de carga: opcionalmente, seleccione las subredes existentes que se han configurado para alojar equilibradores de carga de la lista de subredes del compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento. Las subredes de equilibrador de carga deben ser diferentes de las subredes de nodos de trabajador, pueden ser públicas o privadas y pueden ser regionales (recomendado) o específicas de dominio de disponibilidad. No tiene que especificar ninguna subred de equilibrador de carga. Sin embargo, si especifica subredes de equilibrador de carga, el número de subredes de equilibrador de carga que se debe especificar depende de la región en la que se está creando el cluster y de si las subredes son regionales o específicas de dominio de disponibilidad.

     Si está creando un cluster en una región con tres dominios de disponibilidad, puede especificar:

     • Una o ninguna subred regional de equilibrador de carga (recomendado).
     • Dos o ninguna subred específica de dominio de disponibilidad de equilibrador de carga. Si especifica dos subredes específicas de dominio de disponibilidad, las dos subredes deben estar en diferentes dominios de disponibilidad.

     Si está creando un cluster en una región con un solo dominio de disponibilidad, puede especificar:

     • Una o ninguna subred regional de equilibrador de carga (recomendado).
     • Una o ninguna subred específica de dominio de disponibilidad de equilibrador de carga.

     Consulte Configuración de subred.

6. Acepte los valores por defecto de las opciones avanzadas de la red o seleccione Opciones avanzadas y especifique alternativas a la siguiente forma:

   • Bloque de CIDR de servicio de Kubernetes: grupo disponible de direcciones de red IPv4 que se pueden exponer como servicios de Kubernetes (ClusterIPs), expresado como un único bloque de CIDRIPv4 CIDR IPv4 contiguo. Por ejemplo, 10.96.0.0/16. El bloque CIDRIPv4 CIDR IPv4 que especifique no se debe superponer con el bloque CIDRIPv4 CIDR IPv4 para la VCN. Para un cluster de pila doble, también puede especificar un prefijo IPv6 del servicio Kubernetes. Consulte Bloques IPv4 CIDR y Kubernetes Engine (OKE).
   • Prefijo IPv6 del servicio de Kubernetes: al crear un cluster de pila doble, el grupo disponible de direcciones de red IPv6 que se pueden exponer como servicios de Kubernetes (ClusterIPs), expresado como un único bloque CIDR IPv6 contiguo. Por ejemplo, fd00:eeee:eeee:0001::/108. El bloque CIDR IPv6 que especifique no se debe superponer con el bloque CIDR IPv6 para la VCN. Para un cluster de pila doble, también puede especificar un bloque CIDR del servicio Kubernetes. Consulte Enabling Clusters for IPv4 and IPv6.
   • Bloque de CIDR de pods: si ha seleccionado Superposición de franela: como Tipo de red, el grupo disponible de direcciones de red que se pueden asignar a los pods que se ejecutan en el cluster, expresado como un único bloque de CIDRIPv4 CIDR IPv4 contiguo. Por ejemplo, 10.244.0.0/16. El bloque CIDR que especifique no se debe superponer con los bloques CIDR para subredes en la VCN y puede estar fuera del bloque CIDR de VCN. Para un cluster de pila doble, puede especificar un bloque CIDRIPv4 CIDR IPv4 y un bloque CIDR IPv6 (separados por una coma). No especifique un bloque de CIDR si ha seleccionado red de pods nativa de VCN como tipo de red del cluster. Consulte Bloques IPv4 CIDR y Kubernetes Engine (OKE).

7. Seleccione Siguiente y especifique los detalles de configuración del primer pool de nodo del cluster en la página Pools de Nodos:

   • Nombre: un nombre que elija para el nuevo pool de nodos. Evite introducir información confidencial.
   • Compartimento: compartimento en la que se va a crear el nuevo pool de nodos.
   • Tipo de nodo: si ha seleccionado Red de pod nativo de VCN: como Tipo de red, especifique el tipo de nodos de trabajador en este pool de nodos (consulte Nodos virtuales y nodos gestionados). Seleccione una de las opciones siguientes:
     • Gestionado: seleccione esta opción cuando desee tener la responsabilidad de gestionar los nodos de trabajador en el pool de nodos. Los nodos gestionados se ejecutan en las instancias de Compute (tanto con hardware dedicado como en máquina virtual) de su arrendamiento. Puesto que es responsable de administrar los nodos gestionados, con la posibilidad de configurarlos para cumplir sus requisitos específicos. Usted se encarga de cambiar la versión de Kubernetes en los nodos gestionados y de gestionar la capacidad del cluster.
     • Virtual: seleccione esta opción cuando desee beneficiarse de una experiencia de Kubernetes "sin servidor". Los nodos virtuales permiten ejecutar pods de Kubernetes a escala sin la sobrecarga operativa que supone actualizar la infraestructura del plano de datos y gestionar la capacidad de los clusters.

     Para obtener más información, consulte Comparación de nodos virtuales con nodos gestionados.

   • Versión de Kubernetes: (solo pools de nodos gestionados) versión de Kubernetes que se ejecutará en cada nodo gestionado del pool de nodos gestionados. Por defecto, la versión de Kubernetes especificada para los nodos de plano de control está seleccionada. La versión de Kubernetes en nodos de trabajador debe ser la misma que la de los nodos de plano de control o una versión anterior que aún sea compatible. Consulte Versiones de Kubernetes y Kubernetes Engine (OKE).

     Tenga en cuenta que si especifica una imagen de OKE para nodos de trabajador, la versión de Kubernetes que seleccione aquí debe ser la misma que la versión de Kubernetes en la imagen de OKE.

8. Si ha seleccionado red de pods nativa de VCN como Tipo de red y Gestionada como Tipo de nodo, o si ha seleccionado Superposición de franela: como Tipo de red:

   1. Especifique los detalles de configuración para el pool de nodos gestionados:
      • Configuración de colocación de nodo:
        • Dominio de Disponibilidad: dominio de Disponibilidad en el que colocar nodos de trabajador.
        • Subred de nodo de trabajador: subred regional (recomendada) o subred específica de dominio de disponibilidad configurada para alojar nodos de trabajador desde la lista de subredes del compartimento especificado. Por defecto, el compartimento es el que va a crear el cluster, pero puede seleccionar otro compartimento. Si especificó subredes de equilibrador de carga, las subredes de nodos de trabajador deben ser diferentes. Las subredes que especifique pueden ser privadas (recomendadas) o públicas. Consulte Configuración de subred.
        • Dominios de errores: (opcional) uno o más dominios de errores en el dominio de disponibilidad en el que colocar los nodos de trabajador.

        Opcionalmente, seleccione Opciones avanzadas para especificar un tipo de capacidad que utilizar (consulte Gestión de tipos de capacidad de nodo de trabajador). Si especifica una reserva de capacidad, tenga en cuenta que la unidad de nodo, el dominio de disponibilidad y el dominio de errores de la configuración de colocación del pool de nodos gestionado deben coincidir con el tipo de instancia, el dominio de disponibilidad y el dominio de errores de la reserva de capacidad, respectivamente. Consulte Uso de reservas de capacidad para aprovisionar nodos gestionados.

        De manera opcional, seleccione Agregar fila para seleccionar dominios y subredes adicionales donde colocar nodos de trabajador.

        Cuando se crean los nodos de trabajador, se distribuyen lo más equitativamente posible en los dominios de disponibilidad y los dominios de errores que seleccione. Si no selecciona ningún dominio de errores para un dominio de disponibilidad concreto, los nodos de trabajador se distribuyen lo más equitativamente posible en todos los dominios de errores de ese dominio de disponibilidad.

      • Unidad de nodo: unidad que se utilizará para nodos de trabajador en el pool de nodos gestionado. La unidad determina la cantidad de CPU y la cantidad de memoria asignada a cada nodo gestionado. Para cambiar la unidad por defecto, seleccione Cambiar unidad.

        Solo se muestran aquellas unidades de computación disponibles en el arrendamiento soportadas por Kubernetes Engine.

        Si selecciona una unidad flexible, puede especificar explícitamente el número de CPU y la cantidad de memoria.

        Consulte Imágenes soportadas (incluidas imágenes personalizadas) y unidades para nodos de trabajador.

      • Imagen: imagen que se va a utilizar en los nodos de trabajador del pool de nodos gestionados. Una imagen es una plantilla de un disco duro virtual que determina el sistema operativo y otro software para el pool de nodos gestionado.

        Para cambiar la imagen por defecto, seleccione Cambiar imagen. En la ventana Examinar todas las imágenes, seleccione un origen de imagen y seleccione una imagen como se indica a continuación:

        • Imágenes de nodos de trabajador de OKE: se recomienda. Proporcionado por Oracle y basado en imágenes de plataforma. Las imágenes de OKE están optimizadas para servir como imágenes base para los nodos de trabajador, con todas las configuraciones necesarias y el software necesario. Seleccione una imagen de OKE si desea minimizar el tiempo que se tarda en aprovisionar nodos de trabajador en tiempo de ejecución en comparación con las imágenes de plataforma y las imágenes personalizadas.

          Los nombres de imagen de OKE incluyen el número de versión de la versión de Kubernetes que contienen. Tenga en cuenta que si especifica una versión de Kubernetes para el pool de nodos, la imagen de OKE que seleccione aquí debe tener el mismo número de versión que la versión de Kubernetes del pool de nodos.

        • Imágenes de plataforma: proporcionadas por Oracle y que solo contienen un sistema operativo Oracle Linux. Seleccione una imagen de plataforma si desea que Kubernetes Engine descargue, instale y configure el software necesario cuando la instancia informática que aloja un nodo de trabajador se inicie por primera vez.

        Consulte Imágenes soportadas (incluidas imágenes personalizadas) y unidades para nodos de trabajador.

      • Recuento de nodos: el número de nodos de trabajador que hay que crear en el pool de nodo gestionado, situado en los dominios de disponibilidad que seleccione, y en la subred regional (recomendado) o en el subred específica de dominio que especifique para cada dominio del servicio.
      • Usar reglas de seguridad en el grupo de seguridad de red (NSG): controle el acceso al pool de nodos mediante reglas de seguridad definidas para uno o más grupos de seguridad de red (NSG) que especifique (hasta un máximo de cinco). Puede utilizar reglas de seguridad definidas para los NSG en lugar de las definidas para las listas de seguridad (se recomiendan los NSG). Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para los nodos de trabajador.

      • Volumen de inicio: configure las opciones de tamaño y cifrado para los volúmenes de inicio de nodo gestionados:

        • Para especificar un tamaño personalizado para el volumen en inicio, seleccione Especificar un tamaño del volumen en inicio personalizado e introduzca un tamaño personalizado de 50 GB a 32 TB. El tamaño especificado debe ser mayor que el tamaño de volumen de inicio por defecto para la imagen seleccionada. Consulte Tamaños de volumen de inicio personalizado para obtener más información.

          Tenga en cuenta que si aumenta el tamaño del volumen de inicio, también debe ampliar la partición del volumen de inicio (la partición raíz) para aprovechar el tamaño más grande. Consulte Extending the Partition for a Boot Volume. Las imágenes de la plataforma Oracle Linux incluyen el paquete oci-utils. Puede utilizar el comando oci-growfs de ese paquete en un script cloud-init personalizado para ampliar la partición raíz y, a continuación, ampliar el sistema de archivos. Para obtener más información, consulte Ampliación de la partición raíz de nodos de trabajador.

        • Para la instancias de VM, opcionalmente puede seleccionar Usar cifrado en tránsito. Para las instancias dedicadas que soportan el cifrado en tránsito, se activa por defecto y no se puede configurar. Consulte Cifrado de volumen en bloque para obtener más información sobre el cifrado en tránsito. Si utiliza su propia clave de cifrado para el volumen de inicio, esta clave también se utiliza para el cifrado en tránsito. De lo contrario, se utiliza la clave de cifrado proporcionada por Oracle.
        • Los volúmenes de inicio se cifran por defecto, pero, opcionalmente, puede utilizar su propia clave del cifrado de servicio Vault para cifrar los datos en este volumen. Para utilizar el servicio de almacén para sus necesidades del cifrado, seleccione Cifre este volumen con una clave que gestione. Seleccione el compartimento de almacén y el almacén que contiene la clave de cifrado maestra que desea utilizar y, a continuación, seleccione el compartimento de clave de cifrado maestra y la clave de cifrado maestra. Si activa esta opción, esta clave se utiliza tanto para el cifrado de datos como para el cifrado en tránsito.
          Importante
          
          El servicio Block Volume no soporta el cifrado de volúmenes con claves cifradas mediante el algoritmo Rivest-Shamir-Adleman (RSA). Al utilizar sus propias claves, debe utilizar claves cifradas con el algoritmo Estándar de cifrado avanzado (AES). Esto se aplica a los volúmenes en bloque y los volúmenes de inicio.

        Tenga en cuenta que para utilizar su propia clave de cifrado del servicio Vault para cifrar los datos, una política de IAM debe otorgar acceso a la clave de cifrado del servicio. Consulte Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

      • Comunicación de pod: si ha seleccionado red de pod nativo de VCN como Tipo de red y Gestionada como Tipo de nodo, especifique cómo se comunican los pods del pool de nodos gestionados entre sí mediante una subred de pod:
        • Compartimento de subred: compartimento en el que reside la subred del pod.
        • Subred: subred regional configurada para alojar pods. La subred de pod que especifique debe ser privada. En algunas situaciones, la subred del nodo de trabajador y la subred del pod pueden ser la misma subred (en cuyo caso, Oracle recomienda definir reglas de seguridad en los grupos de seguridad de red en lugar de en las listas de seguridad). Consulte Configuración de subred.
        • Usar reglas de seguridad en el grupo de seguridad de red (NSG): controle el acceso a la subred de pod mediante reglas de seguridad definidas para uno o más grupos de seguridad de red (NSG) que especifique (hasta un máximo de cinco). Puede utilizar reglas de seguridad definidas para los NSG en lugar de las definidas para las listas de seguridad (se recomiendan los NSG). Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para nodos y pods de trabajador.

        Opcionalmente, seleccione Opciones avanzadas para especificar el número máximo de pods que desea ejecutar en un único nodo de trabajador en un pool de nodos gestionado, hasta un límite de 110. El límite de 110 lo impone Kubernetes. Si desea más de 31 pods en un solo nodo de trabajador, la unidad que especifique para el pool de nodos debe admitir tres o más VNIC (una VNIC para conectarse a la subred del nodo de trabajador y al menos dos VNIC para conectarse a la subred del pod). Consulte Maximum Number of VNICs and Pods Supported by Different Shapes.

        Para obtener más información sobre la comunicación de pod, consulte Redes de pod.

   2. Acepte los valores por defecto de las opciones del pool de nodos gestionado avanzado o seleccione Opciones avanzadas y especifique alternativas de la siguiente manera:

      • Cordón y drenaje: especifique cuándo y cómo acordonar y drenar los nodos gestionados antes de cerrarlos o terminarlos.

        • Período de gracia de expulsión (minutos): el tiempo que se tarda en permitir acordonar y drenar los nodos de trabajador antes de cerrarlos o terminarlos. Acepte el valor por defecto (60 minutos, que es el máximo) o especifique una alternativa. Por ejemplo, al reducir un pool de nodos o cambiar su configuración de ubicación, puede que desee permitir 30 minutos para acordonar nodos de trabajador y vaciarlos de sus cargas de trabajo. Para cerrar o terminar los nodos de trabajador inmediatamente, sin acordonarlos ni drenarlos, especifique 0 minutos.
        • Forzar terminación después del período de gracia: al sustituir nodos o suprimir nodos en el pool de nodos, si se deben terminar los nodos de trabajador al final del período de gracia de expulsión, incluso si no se han corregido y drenado correctamente. Por defecto, esta opción no está seleccionada.
        • Forzar acción después del período de gracia: al realizar tareas de mantenimiento en nodos de trabajador (como reiniciar un nodo y sustituir el volumen de inicio de un nodo), si se debe realizar la acción al final del período de gracia de expulsión, incluso si el nodo de trabajador no se ha corregido y drenado correctamente. Por defecto, esta opción no está seleccionada.

        Los pools de nodos que contienen nodos de trabajador que no se pueden cerrar ni terminar en el período de gracia de expulsión tienen el estado Necesita atención. El estado de la solicitud de trabajo que inició la operación de cierre o terminación se establece en Fallo y la operación se cancela. Para obtener más información, consulte Monitoring Clusters.

        Para obtener más información, consulte Cordoning and Draining Managed Nodes Before Shut Down or Termination.

      • Script de inicialización: (opcional) script para que cloud-init se ejecute en cada instancia que aloja nodos gestionados cuando la instancia se inicia por primera vez. El script que especifique debe escribirse en uno de los formatos admitidos por cloud-init (por ejemplo, cloud-config) y debe ser un tipo de archivo admitido (por ejemplo, .yaml). Especifique el script como se indica a continuación:
        • Seleccionar script cloud-init: seleccione un archivo que contenga el script cloud-init o arrastre y suelte el archivo en el cuadro.
        • Pegar script cloud-init: copie el contenido de un script cloud-init y péguelo en el cuadro.

        Si no ha escrito previamente scripts cloud-init para inicializar nodos de trabajador en clusters creados por Kubernetes Engine, puede que le resulte útil seleccionar Descargar para descargar una plantilla de script cloud-init. El archivo descargado contiene la lógica por defecto proporcionada por Kubernetes Engine. Puede agregar su propia lógica personalizada antes o después de la lógica predeterminada, pero no modifique la lógica predeterminada. Para ver ejemplos, consulte Casos de uso de ejemplo para scripts personalizados de Cloud-init.

      • etiquetas de Kubernetes: (opcional) una o más etiquetas (además de una etiqueta por defecto) para agregar a los nodos del trabajador en el pool de nodo a fin del objetivo de permitir el direccionamiento de cargas de trabajo en pools de nodo específicos. Por ejemplo, para excluir todos los nodos de un pool de nodos de la lista de servidores backend de un juego de backends del equilibrador de carga, especifique node.kubernetes.io/exclude-from-external-load-balancers=true (consulte node.kubernetes.io/exclude-from-external-load-balancers).
      • Etiquetas de pool de nodos y Etiquetas de nodo: (opcional) una o más etiquetas para agregar al pool de nodos y a instancias informáticas que alojan nodos de trabajador en el pool de nodos. El etiquetado permite agrupar recursos dispares en compartimentos y, además, permite anotar recursos con sus propios metadatos. Consulte Etiquetado de recursos relacionados en clusters de Kubernetes.
      • Agregar una clave SSH: (opcional) genere un par de Claves o cargue la parte de la clave pública de la clave que desea utilizar para acceder a SSH a cada nodo del pool de nodos. La clave pública está instalada en todos los nodos de trabajador del cluster. Tenga en cuenta que si no especifica una clave SSH pública, Kubernetes Engine proporcionará una. Sin embargo, puesto que no tendrá la clave privada correspondiente, no tendrá acceso SSH a los nodos de trabajador. Debe tener en cuenta que no puede utilizar SSH para acceder directamente a ningún nodo del trabajador en subredes privadas (consulte Conexión a nodos gestionados en subredes privadas mediante SSH).

9. Si ha seleccionado Virtual como Tipo de nodo:

   1. Especifique los detalles de configuración para el pool de nodos virtuales:
      • Configuración de colocación de nodo:
        • Dominio de Disponibilidad: dominio de Disponibilidad en el que colocar nodos virtuales.
        • Dominios de errores: (opcional) uno o más dominios de errores en el dominio de disponibilidad en el que colocar los nodos virtuales.

        De manera opcional, seleccione Agregar fila para seleccionar dominios adicionales en los que colocar los nodos virtuales.

        Cuando se crean los nodos virtuales, se distribuyen lo más equitativamente posible en los dominios de disponibilidad y los dominios de errores que seleccione. Si no selecciona ningún dominio de errores para un dominio de disponibilidad concreto, los nodos virtuales se distribuyen lo más equitativamente posible en todos los dominios de errores de ese dominio de disponibilidad.

      • Recuento de nodos: el número de nodos virtuales que hay que crear en el pool de nodo virtual, situado en los dominios de disponibilidad que seleccione, y en la subred regional (recomendado) o en el subred específica de dominio que especifique para cada dominio del servicio.

      • Unidad de pod: la unidad que se utilizará para los pods que se ejecutan en nodos virtuales en el pool de nodos virtuales. La unidad determina el tipo de procesador en el que se va a ejecutar el pod.

        Solo se muestran aquellas unidades disponibles en el arrendamiento soportadas por Kubernetes Engine. Consulte Imágenes soportadas (incluidas imágenes personalizadas) y unidades para nodos de trabajador.

        Tenga en cuenta que especifica explícitamente los requisitos de recursos de CPU y memoria para los nodos virtuales en la especificación de pod (consulte Asignación de recursos de memoria a contenedores y pods y Asignación de recursos de CPU a contenedores y pods en la documentación de Kubernetes).

      • Comunicación de nodo virtual:
        • Compartimento de subred: compartimento en el que reside la subred del nodo virtual.
        • Subred: una subred regional (recomendado) o subred específica de AD configurada para alojar nodos virtuales. Si especificó subredes del equilibrio de carga, las subredes del nodo virtual deben ser diferentes. Las subredes que especifique pueden ser privadas (recomendado) o públicas y pueden ser regionales (recomendado) o específicas de dominio de disponibilidad. Recomendamos que la subred de pod y la subred de nodo virtual sean la misma subred (en cuyo caso, la subred de nodo virtual debe ser privada). Consulte Configuración de subred.
        • Usar reglas de seguridad en el grupo de seguridad de red (NSG): controle el acceso a la subred del nodo virtual mediante reglas de seguridad definidas para uno o más grupos de seguridad de red (NSG) que especifique (hasta un máximo de cinco). Puede utilizar reglas de seguridad definidas para los NSG en lugar de las definidas para las listas de seguridad (se recomiendan los NSG). Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para nodos y pods de trabajador.
      • Comunicación de pod: los pods que se ejecutan en nodos virtuales utilizan redes de pods nativas de VCN. Especifique cómo se comunican los pods del pool de nodos entre sí mediante una subred de pod:
        • Compartimento de subred: compartimento en el que reside la subred del pod.
        • Subred: subred regional configurada para alojar pods. La subred de pod que especifique para los nodos virtuales debe ser privada. Recomendamos que la subred de pod y la subred de nodo virtual sean la misma subred (en cuyo caso, Oracle recomienda definir reglas de seguridad en los grupos de seguridad de red en lugar de en las listas de seguridad). Consulte Configuración de subred.
        • Usar reglas de seguridad en el grupo de seguridad de red (NSG): controle el acceso a la subred de pod mediante reglas de seguridad definidas para uno o más grupos de seguridad de red (NSG) que especifique (hasta un máximo de cinco). Puede utilizar reglas de seguridad definidas para los NSG en lugar de las definidas para las listas de seguridad (se recomiendan los NSG). Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para nodos y pods de trabajador.

        Para obtener más información sobre la comunicación de pod, consulte Redes de pod.

   2. Acepte los valores por defecto de las opciones avanzadas del pool de nodos virtuales o seleccione Opciones avanzadas y especifique alternativas de la siguiente manera:

      • Etiquetas de pool de nodos: (opcional) una o más etiquetas para agregar al pool de nodos virtuales. El etiquetado permite agrupar recursos dispares en compartimentos y, además, permite anotar recursos con sus propios metadatos. Consulte Etiquetado de recursos relacionados en clusters de Kubernetes.
      • etiquetas de Kubernetes: (opcional) una o más etiquetas (además de una etiqueta por defecto) para agregar a los nodos virtuales en el grupo de nodos virtuales a fin del objetivo de permitir el targeting de cargas de trabajo en pools de nodo específicos. Para obtener más información, consulte Asignación de pods a nodos en la documentación de Kubernetes.
      • Contenido de Kubernetes: (opcional) uno o más elementos que se deben agregar a los nodos virtuales en el pool de nodos virtuales. Los mantos permiten que los nodos virtuales repelan los pods, lo que garantiza que los pods no se ejecuten en nodos virtuales en un pool de nodos virtuales concreto. Tenga en cuenta que solo puede aplicar contaminantes a los nodos virtuales. Para obtener más información, consulte Asignación de pods a nodos en la documentación de Kubernetes.
10. Seleccione Siguiente para revisar los detalles que ha introducido para el nuevo cluster.
11. Si no ha seleccionado ninguna de las funciones de cluster mejoradas y desea crear el nuevo cluster como cluster básico en lugar de como cluster mejorado, seleccione la opción Crear un cluster básico en la página Revisar y crear. Consulte Trabajar con clusters mejorados y clusters básicos.

12. Seleccione Crear Cluster para crear el nuevo cluster ahora.

    Kubernetes Engine empieza a crear el cluster con el nombre especificado.

    Si ha especificado detalles para uno o más pools de nodos, Kubernetes Engine crea:

    • pools de nodos con los nombres especificados
    • nodos de trabajador con nombres generados automáticamente (los nombres de nodos gestionados tienen el formato oke-c<part-of-cluster-OCID>-n<part-of-node-pool-OCID>-s<part-of-subnet-OCID>-<slot>, los nombres de nodos virtuales son los mismos que la dirección IP privada del nodo)

    No cambie los nombres de nodos de trabajador generados automáticamente.

    Tenga en cuenta que, en lugar de crear el nuevo cluster inmediatamente, puede crearlo más tarde mediante Resource Manager y Terraform, seleccionando Guardar como pila para guardar la definición de recurso como configuración de Terraform. Para obtener más información sobre cómo guardar pilas a partir de definiciones de recursos, consulte Creación de una pila a partir de una página de creación de recursos.

13. Seleccione Cerrar para volver a la consola.

Inicialmente, el nuevo cluster aparece en la Consola con el estado Creando. Cuando se ha creado el cluster, tiene el estado Activo.

Kubernetes Engine también crea un archivo de configuración de Kubernetes kubeconfig que se utiliza para acceder al cluster mediante kubectl.