Documentación de Oracle Cloud Infrastructure

Actualización de nodos gestionados a la versión 1.35 (o posterior) de Kubernetes

Descubra cómo actualizar los nodos gestionados que utilizan actualmente una imagen OL7 de OKE, una imagen de plataforma OL7 o una imagen personalizada basada en una imagen OL7 para ejecutar Kubernetes versión 1.35 (o posterior) y OL8, mediante Kubernetes Engine (OKE).

Nota

Esta sección solo se aplica a los nodos gestionados. Para obtener información sobre la actualización de nodos autogestionados, consulte Actualización de nodos autogestionados a una versión más reciente de Kubernetes mediante la sustitución de un nodo autogestionado existente.

A partir de la versión 1.35 de Kubernetes, Kubernetes necesita cgroups v2 para la gestión de recursos de contenedor.

Los grupos de control (cgroups) son una función del núcleo de Linux que proporciona un mecanismo para gestionar y controlar la asignación de recursos para procesos o grupos de procesos. Los grupos de control versión 2 (cgroups v2) proporcionan una única jerarquía de grupos de control en la que se montan todos los controladores de recursos. En esta jerarquía, puede coordinar el uso de recursos entre diferentes controladores de recursos.

Oracle Linux 7 (OL7) admite cgroups v1, pero no admite cgroups v2. Oracle Linux 8 (OL8) y versiones posteriores admiten tanto los cgroups v1 como los cgroups v2, pero los cgroups v2 no siempre están activados por defecto en OL8.

En resumen, la versión 1.35 de Kubernetes requiere, por lo tanto, OL8 (o posterior) con cgroups v2 activados.

Los Cgroups v2 están activados de forma predeterminada en las imágenes OL8 de OKE que tienen un número de creación de 1367 o superior. Sin embargo, en las imágenes OL8 de OKE que tienen un número de compilación inferior a 1367 (y en las imágenes de plataforma OL8), los cgroups v1 están activados de forma predeterminada.

Para los nodos de trabajador en clusters que ejecutan Kubernetes versión 1.35 (y posterior), Kubernetes Engine soporta las siguientes imágenes:

En los clusters que ejecutan Kubernetes versión 1.35 (y posterior), no se recomienda el uso de imágenes de plataforma (tanto imágenes de plataforma OL7 como imágenes de plataforma OL8). Recomendamos encarecidamente el uso de imágenes de OKE para todos los nuevos despliegues y actualizaciones. Si desea seguir utilizando una imagen de plataforma, cree una imagen personalizada basada en la imagen de plataforma y especifique el OCID de la imagen personalizada al crear o actualizar un pool de nodos (tenga en cuenta que no recomendamos este enfoque).

Al actualizar los nodos gestionados que utilizan actualmente una imagen OL8 a la versión 1.35 (y posterior) de Kubernetes, tenga en cuenta lo siguiente:

  • Puede actualizar los nodos gestionados que actualmente utilizan una imagen OL8 de OKE (o una imagen personalizada basada en una imagen OL8 de OKE) con un número de compilación inferior a 1367, realizando una actualización in situ y especificando una imagen OL8 de OKE con un número de compilación de 1367 o superior.
  • Puede actualizar los nodos gestionados que actualmente utilizan una imagen de plataforma OL8 realizando una actualización in situ y especificando una imagen OL8 de OKE con un número de compilación de 1367 o superior.
  • Puede realizar actualizaciones in situ de los nodos gestionados que actualmente utilizan una imagen OL8, independientemente de si los núcleos de Linux de las instancias informáticas que alojan los nodos ya tienen activados los cgroups v2.
  • Para obtener instrucciones sobre cómo realizar actualizaciones in situ, consulte Actualización de nodos gestionados a una versión más reciente de Kubernetes.
  • Para obtener más información sobre la introducción del soporte para la versión 1.35 de Kubernetes, consulte OKE da la bienvenida a Kubernetes 1.35: novedades, cambios y qué hacer a continuación.

Validar cargas de trabajo para cgroups v2

Antes de actualizar los nodos de trabajador de producción, verifique que las aplicaciones y los agentes de soporte sean compatibles con cgroups v2.

cgroups v2 puede cambiar la forma en que se contabiliza la memoria del contenedor. Un aumento en el uso de memoria del contenedor informado por sí solo no indica necesariamente la saturación de la memoria. Investigar un aumento cuando se acompaña de una o más de las siguientes condiciones:

  • Terminaciones de contenedor sin memoria (OOM).
  • Reinicios de contenedor o pod.
  • Desalojos pod.
  • Condición de nodo MemoryPressure.

Para obtener información sobre los requisitos de cgroups v2, la contabilidad de memoria, la compatibilidad en tiempo de ejecución y la determinación de la versión de cgroups utilizada por un nodo, consulte Acerca de cgroup v2 en la documentación de Kubernetes.

Es posible que los tiempos de ejecución de aplicaciones anteriores no detecten correctamente los límites de recursos de contenedor en los sistemas que utilizan cgroups v2. Por ejemplo, una aplicación Java puede calcular la pila u otra configuración de memoria de los recursos del nodo de trabajador en lugar del límite de memoria del contenedor. Como resultado, el contenedor puede superar su límite de memoria configurado y ser terminado por el cancelador de OOM de Linux.

Para cargas de trabajo Java, utilice una de las siguientes versiones de JDK o una versión posterior:

  • JDK 15
  • JDK 11.0.16
  • JDK 8u381

JDK 8u372 introdujo el conocimiento de cgroups v2. JDK 8u381 incluye mejoras adicionales en la detección de límites de recursos, métricas de contenedores y estabilidad de aplicaciones de cgroups v1 y cgroups v2. Para otras distribuciones de JDK y tiempos de ejecución de aplicaciones, consulte la documentación del proveedor para identificar una versión que admita cgroups v2.

Verifique también la compatibilidad de la supervisión, la seguridad y otros agentes que acceden directamente a /sys/fs/cgroup. Actualice los agentes incompatibles a las versiones que admiten cgroups v2.

Antes de actualizar los nodos de trabajador de producción, realice la siguiente validación en un entorno que no sea de producción:

  1. Probar cargas de trabajo representativas y agentes de soporte en nodos que utilizan cgroups v2.
  2. Compare la siguiente información antes y después de activar cgroups v2:
    • Uso de memoria de contenedores informado
    • Eventos de OOM de contenedor
    • Reinicios de contenedor y pod
    • Desalojos pod
    • Condición de nodo MemoryPressure
    • Límite de memoria detectado por el tiempo de ejecución de la aplicación

  3. Para cargas de trabajo Java:

    • Registre la versión de JDK introduciendo:

      java -version

    • Revise la configuración del sistema y del contenedor detectada por JVM introduciendo: 

      java -XshowSettings:system -version

    • Configure los valores -Xms y -Xmx explícitos cuando sea adecuado para la carga de trabajo.

Actualice los nodos gestionados de OL7 para ejecutar Kubernetes versión 1.35 (o posterior)

Para actualizar los nodos gestionados que utilizan actualmente una imagen OL7 de OKE, una imagen de plataforma OL7 o una imagen personalizada basada en una imagen OL7, para ejecutar la versión 1.35 (o posterior) de Kubernetes, realice una actualización externa para sustituir el pool de nodos existente por un nuevo pool de nodos:

  1. Identifique los pools de nodos existentes que utilizan OL7 mediante la consola o la CLI de la siguiente manera:

    • Uso de la Consola:

      1. En la página de lista Clusters, seleccione el nombre del cluster que contiene los pools de nodos que desea ver. Si necesita ayuda para encontrar la página de lista o el cluster, consulte Listing Clusters.
      2. Seleccione el separador Pools de nodos.
      3. Utilice la columna Nombre de imagen para identificar pools de nodos que utilizan imágenes Oracle-Linux-7.9.x.

    • Uso de la CLI: identifique los pools de nodos existentes que utilizan OL7 introduciendo un comando similar al siguiente:

      oci ce node-pool list --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --query 'data[*].{name:"name", image:"node-source"."image-id"}'

  2. Cree un pool de nodos de sustitución que utilice una imagen OL8 mediante la consola o la CLI de la siguiente manera:

    • Uso de la Consola:

      1. En el separador Pools de nodos, seleccione Agregar pool de nodos e introduzca los detalles del nuevo pool de nodos.
      2. Seleccione una imagen de nodo de trabajador de OKE basada en una imagen Oracle Linux 8.x.
      3. Configure el nuevo pool de nodos con la misma unidad, tamaño y ubicación que el pool de nodos OL7.
      4. Seleccione Crear.

    • Con la CLI: cree un pool de nodos de sustitución que utilice una imagen OL8 introduciendo un comando similar al siguiente:

      oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name "nodepool-ol8-workers" --node-shape "VM.Standard.E4.Flex" --kubernetes-version "v1.35.0" --node-image-id <ol8-image-ocid> --size 3 --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"<subnet-ocid>"}]'

  3. Conecte los nodos OL7:

    1. Para obtener los nombres de los nodos OL7, introduzca:

      kubectl get nodes -l node.kubernetes.io/os=ol7

    2. Conecte cada nodo introduciendo:

      kubectl cordon <node-name>

  4. Drene los nodos OL7 para migrar cargas de trabajo correctamente:

    1. Drene cada nodo OL7 introduciendo:
      kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
    2. Verifique que las cargas de trabajo se han reprogramado en los nuevos nodos introduciendo:
      kubectl get pods -A -o wide | grep <node-name>

  5. Suprima el pool de nodos OL7 mediante la consola o la CLI, de la siguiente manera:

    • Uso de la Consola:

      1. En el separador Pools de nodos, seleccione Suprimir pool de nodos en el menú Acciones (tres puntos) junto al pool de nodos OL7.
      2. Haga clic en Suprimir.
      3. Confirme que desea suprimir el pool de nodos y seleccione Suprimir.

    • Con la CLI: suprima el pool de nodos OL7:

      oci ce node-pool delete --node-pool-id <ol7-nodepool-ocid>

  6. Actualice el cluster (por ejemplo, a la versión 1.35 de Kubernetes):

    oci ce cluster update --cluster-id <cluster-ocid> --kubernetes-version "v1.35.0"

Para obtener más información, consulte Realización de un cambio de versión de Kubernetes de nodo gestionado fuera de la ubicación mediante el reemplazo de un pool que ya existe por un nuevo pool.