Actualización de un pool de nodos

Descubra cómo actualizar un pool de nodos gestionado mediante Container Engine for Kubernetes (OKE).

Para obtener información general sobre la actualización de pools de nodos, consulte Modificación de las propiedades de los pools de nodos y las propiedades de los nodos de trabajador.

Para modificar las propiedades del pool de nodos y los nodos de trabajador de los clusters existentes de Kubernetes:
1. Abra el menú de navegación y haga clic en Servicios para desarrolladores. En Contenedores y artefactos, haga clic en Clusters de Kubernetes (OKE).
2. Seleccione el compartimento que contiene el cluster.
3. En la página Lista de clusters, haga clic en el nombre del cluster que desea modificar.
4. En la página Detalles de cluster, en Recursos, haga clic en Pools de nodos.
5. Haga clic en el nombre del pool de nodos que desea modificar.
6. Utilice el separador Detalles de pool de nodos para ver información sobre el pool de nodos, incluidos:
  
  El estado del pool de nodos.
  
  El OCID del pool de nodos.
  
  El tipo de nodos de trabajador en el pool de nodos (gestionado o virtual).
  
  Configuración utilizada actualmente al iniciar nuevos nodos de trabajador en el pool de nodos, incluida:
  
  la versión de Kubernetes que se debe ejecutar en los nodos de trabajador
  
  la unidad que se utilizará para los nodos de trabajador
  
  la imagen que se va a utilizar en los nodos de trabajador
  
  Los dominios de disponibilidad, los dominios de errores y diferentes subredes regionales (se recomienda) o subredes específicas de dominio de disponibilidad que alojan nodos de trabajador.
  
  El tipo de nodos de trabajador del pool de nodos (gestionados o virtuales) determina qué propiedades del pool de nodos y las propiedades del nodo de trabajador se pueden cambiar.
7. (Opcional) En el caso de un pool de nodos gestionados y nodos gestionados, cambie las propiedades de la siguiente manera:
  
  Haga clic en Editar y especifique:
  
  Nombre: nombre diferente para el pool de nodos. Evite introducir información confidencial.
  
  Versión: versión diferente de Kubernetes que se ejecutará en los nuevos nodos de trabajador del pool de nodos al realizar una actualización insitu. La versión de Kubernetes en los nodos de trabajador debe ser la misma que en los nodos de plano de control o una versión anterior que aún sea compatible (consulte Versiones de Kubernetes y Container Engine for Kubernetes).
  
  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.
  
  Para iniciar nuevos nodos de trabajador que ejecuten la versión de Kubernetes especificada, purgue los nodos de trabajador existentes en el pool de nodos (para evitar que comiencen nuevos pods y que se supriman pods existentes) y, a continuación, termine cada uno de los nodos de trabajador existentes a su vez.
  
  También puede especificar una versión diferente de Kubernetes que se ejecutará en nuevos nodos de trabajador realizando una actualización externa. Para obtener más información sobre la actualización de nodos de trabajador, consulte Actualización de nodos gestionados a una nueva versión de Kubernetes.
  
  Recuento de nodos: un número diferente de nodos en el pool de nodos. Consulte Escalado de pools de nodos.
  
  Configuración de colocación de nodo:
  
  Dominio de disponibilidad: un dominio de disponibilidad en el que colocar nodos de trabajador.
  
  Subred de nodo de trabajador: una subred regional (se recomienda) o subred específica de AD configurada para alojar nodos de trabajador. Si especificó subredes de equilibrador de carga, las subredes de nodos de trabajador deben ser diferentes. Las subredes que especifique pueden ser privadas (se recomienda) 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.
  
  También puede hacer clic en Mostrar 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 ubicació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 Using Capacity Reservations to Provision Managed Nodes.
  De manera opcional, haga clic en Otra 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: una unidad diferente que se utilizará para los nodos de trabajador del pool de nodos. La unidad de computación determina el número de CPU y la cantidad de memoria asignada a cada nodo.
  
  Solo se muestran las unidades de computación disponibles en el arrendamiento soportadas por Container Engine for Kubernetes.
  
  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: una imagen diferente que se utiliza en los nodos de trabajador del pool de nodos. Una imagen es una plantilla de una unidad de disco duro virtual que determina el sistema operativo y otro software para el nodo.
  
  Para cambiar la imagen, haga clic en Cambiar imagen. En la ventana Examinar todas las imágenes, seleccione un origen de imagen y seleccione una imagen de la siguiente forma:
  
  Imágenes de nodos de trabajador de OKE: recomendado. Oracle lo proporciona y se basa en imágenes de plataformas. Las imágenes de OKE se optimizan 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 solo contienen un sistema operativo Oracle Linux. Seleccione una imagen de plataforma si desea que Container Engine for Kubernetes 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.
  
  Usar reglas de seguridad en el grupo de seguridad de red (NSG): controle el acceso al pool de nodos mediante las 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 o también para las definidas para ellas (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 de trabajador.
  
  Volumen de inicio: cambie las opciones de tamaño y cifrado para el volumen de inicio del nodo de trabajador:
  
  Para especificar un tamaño personalizado para el volumen de inicio, seleccione la casilla de control Especificar un tamaño de volumen de inicio. A continuación, 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 Ampliación de la partición para un volumen de inicio. 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, aumentar el tamaño del sistema de archivos. Para obtener más información, consulte Ampliación de la partición raíz de nodos de trabajador.
  
  Para las instancias de VM, opcionalmente puede seleccionar la casilla de control 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 del servicio de almacén 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 de cifrado del servicio de almacén para cifrar los datos en este volumen. Para utilizar el servicio de almacén para sus necesidades de cifrado, seleccione la casilla de control Cifre este volumen con una clave que gestione. Seleccione el compartimento de almacén y el almacén que contengan 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 de almacén de claves para cifrar 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/o File Systems.
  
  Comunicación de pod: cuando el tipo de red del cluster es redes de pod nativas de VCN, cambie la forma en que los pods del pool de nodos se comunican entre sí mediante una subred de pod:
  
  Subred: una subred regional configurada para alojar pods. La subred de pod puede ser pública o 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 grupos de seguridad de red en lugar de en listas de seguridad). Consulte Configuración de subred.
  
  Grupo de seguridad de red: 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 o también para las definidas para ellas (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.
  
  También puede hacer clic en Mostrar 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, hasta un límite de 110. Kubernetes impone el límite de 110. Si desea más de 31 pods en un único nodo de trabajador, la unidad que especifique para el pool de nodos debe soportar 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.
  
  Acepte los valores existentes de las opciones avanzadas del pool de nodos o haga clic en Mostrar Opciones Avanzadas y especifique alternativas de la siguiente forma:
  
  Cordón y drenaje: cambie cuándo y cómo conectar y drenar nodos de trabajador antes de terminarlos.
  
  Período de gracia de expulsión (minutos): período de tiempo que se permite conectar y drenar nodos de trabajador antes de terminarlos. Acepte el valor por defecto (60 minutos) o especifique una alternativa. Por ejemplo, al reducir verticalmente un pool de nodos o cambiar su configuración de ubicación, puede que desee permitir 30 minutos para conectar nodos de trabajador y drenarlos de sus cargas de trabajo. Para terminar los nodos de trabajador inmediatamente, sin conectarlos ni drenarlos, especifique 0 minutos.
  
  Forzar finalización después del período de gracia: indica si se deben terminar los nodos de trabajador al final del período de gracia de expulsión, incluso si no se han conectado y drenado correctamente. Por defecto, esta opción no está seleccionada.
  Seleccione esta opción si siempre desea que los nodos de trabajador terminen al final del período de gracia de desalojo, incluso si no se han conectado y drenado correctamente.
  Anule la selección de esta opción si no desea que los nodos de trabajador que no se han conectado y drenado correctamente se terminen al final del período de gracia de desalojo. Los pools de nodos que contienen nodos de trabajador que no se pueden terminar dentro del 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 terminación se establece en Con fallos y la operación de terminación se cancela. Para obtener más información, consulte Monitoring Clusters.
  
  Para obtener más información, consulte Notas sobre cableado y drenado de nodos gestionados antes de la terminación.
  
  Script de inicialización: (opcional) script diferente para que cloud-init se ejecute en instancias que alojan nodos de trabajador cuando la instancia se inicia por primera vez. El script que especifique debe estar escrito 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 de la siguiente forma:
  
  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 Container Engine for Kubernetes, puede que le resulte útil hacer clic en Descargar plantilla de script cloud-Init personalizada. El archivo descargado contiene la lógica por defecto proporcionada por Container Engine for Kubernetes. Puede agregar su propia lógica personalizada antes o después de la lógica por defecto, pero no modifique la lógica por defecto. Para ver ejemplos, consulte Ejemplos de scripts personalizados de Cloud-init.
  
  Etiquetas de Kubernetes: (opcional) una o varias etiquetas (además de una etiqueta por defecto) para agregar a los nodos de trabajador en el pool de nodos a fin de permitir el targeting de cargas de trabajo en pools de nodos 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 de equilibrador de carga, especifique node.kubernetes.io/exclude-from-external-load-balancers=true (consulte node.kubernetes.io/exclude-from-external-load-balancers).
  
  Clave SSH pública: (opcional) la parte de la clave pública del par de claves que desea utilizar para el acceso SSH a los nodos 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, Container Engine for Kubernetes proporcionará una. Sin embargo, puesto que no tendrá la clave privada correspondiente, no tendrá acceso SSH a los nodos de trabajador. Tenga en cuenta que no puede utilizar SSH para acceder directamente a ningún nodo de trabajador en subredes privadas (consulte Conexión a nodos gestionados en subredes privadas mediante SSH).
  
  Haga clic en Guardar cambios para guardar las propiedades actualizadas.
8. (Opcional) En el caso de un pool de nodos virtuales y nodos virtuales, cambie las propiedades de la siguiente manera:
  
  Haga clic en Editar y especifique:
  
  Nombre: nombre diferente para el pool de nodos. Evite introducir información confidencial.
  
  Recuento de nodos: un número diferente de nodos virtuales que crear en el pool de nodos virtuales, situado en los dominios de disponibilidad que seleccione, y en la subred regional (recomendado) o en la subred específica de dominio de disponibilidad que especifique para cada dominio de disponibilidad. Consulte Escalado de pools de nodos.
  
  Configuración de colocación de nodo:
  
  Dominio de disponibilidad: un 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, haga clic en Otra fila para seleccionar más dominios y subredes en los que colocar 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.
  
  Comunicación de nodo virtual:
  
  Subred: una subred regional diferente (se recomienda) o subred específica de dominio de disponibilidad configurada para alojar nodos virtuales. Si especificó subredes de equilibrador de carga, las subredes de nodos virtuales deben ser diferentes. Las subredes que especifique pueden ser privadas (recomendado) o públicas, y pueden ser regionales (recomendado) o específicas de AD. Recomendamos que la subred de pod y la subred de nodos virtuales sean la misma subred (en cuyo caso, la subred de nodos virtuales debe ser privada). Para obtener más información, consulte Subnet Configuration.
  
  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 o también para las definidas para ellas (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 con los pods:
  
  Subred: subred regional diferente 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 grupos de seguridad de red en lugar de en listas de seguridad). Para obtener más información, consulte Subnet Configuration.
  
  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 o también para las definidas para ellas (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.
  
  Etiquetas y marcas de Kubernetes: (opcional) active el direccionamiento de cargas de trabajo en pools de nodos específicos agregando etiquetas y marcas a nodos virtuales:
  
  Etiquetas: una o varias etiquetas (además de una etiqueta por defecto) para agregar nodos virtuales en el pool de nodos virtuales a fin de permitir el destino de cargas de trabajo en pools de nodos específicos.
  
  Marcas: una o varias marcas que agregar a los nodos virtuales del pool de nodos virtuales. Las marcas permiten que los nodos virtuales repelan los pods y, por lo tanto, garantizan que los pods no se ejecuten en nodos virtuales de un pool de nodos virtual concreto. Solo puede aplicar marcas a los nodos virtuales.
  
  Para obtener más información, consulte Asignación de pods a nodos en la documentación de Kubernetes.
  
  Haga clic en Guardar cambios para guardar las propiedades actualizadas.
9. Utilice el separador Etiquetas de pool de nodos y el separador Etiquetas de nodo para agregar o modificar etiquetas aplicadas al pool de nodos y etiquetas aplicadas a instancias informáticas que alojan nodos de trabajador en el pool de nodos. El etiquetado permite agrupar recursos diversos en compartimentos y, además, permite anotar recursos con sus propios metadatos. Consulte Etiquetado de recursos relacionados con cluster de Kubernetes.
10. En Resources:
  
  Haga clic en Nodos para ver información sobre nodos de trabajador específicos en un pool de nodos gestionados. Además, puede editar los detalles de configuración de un nodo de trabajador específico haciendo clic en el nombre del nodo de trabajador.
  
  Haga clic en Nodos virtuales para ver información sobre nodos de trabajador específicos en un pool de nodos virtuales.
  
  Haga clic en Métricas para supervisar el estado, la capacidad y el rendimiento de un pool de nodos gestionado. Para obtener más información, consulte Métricas de Container Engine for Kubernetes.
  
  Haga clic en Solicitudes de trabajo para:
  
  Obtenga los detalles de una solicitud de trabajo concreta para el recurso del pool de nodos.
  
  Muestre las solicitudes de trabajo para el recurso del pool de nodos.
  
  Para obtener más información, consulte Visualización de solicitudes de trabajo.
Utilice el comando oci ce node-pool update y los parámetros necesarios para actualizar un pool de nodos gestionado:
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]
Para obtener una lista completa de parámetros y valores para los comandos de la CLI, consulte la Referencia de comandos de CLI.
Ejecute la operación UpdateNodePool para actualizar un pool de nodos gestionado.

Documentación de Oracle Cloud Infrastructure

Actualización de un pool de nodos