Versiones admitidas de Kubernetes

Calendario de lanzamiento

El motor de contenedor para Kubernetes (OKE) soporta las siguientes versiones de Kubernetes para nuevos clusters:

Exención de responsabilidad legal: la tabla tiene la intención de exponer la dirección general de nuestros productos. Se proporciona únicamente con fines informativos y puede que no se incluya en ningún contrato. No se establece como compromiso la entrega de ningún tipo de material, código ni funcionalidad, y no debe tenerse en cuenta para decisiones de compra. El desarrollo, la publicación, el tiempo y el precio de cualquier función o funcionalidad descrita para los productos de Oracle pueden cambiar y quedarán a la sola discreción de Oracle Corporation.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.30

Tenga en cuenta que el soporte de Container Engine for Kubernetes para la versión 1.30 de Kubernetes también introduce cambios en el comportamiento por defecto de Container Engine for Kubernetes en lo que respecta a la reserva de CPU y memoria. En clusters que ejecutan Kubernetes versión 1.30 y posteriores, los recursos de CPU y memoria para nodos gestionados se reservan por defecto, utilizando los indicadores de kubelet --kube-reserved y --system-reserved respectivamente (como se recomienda en Mejores prácticas: reserva de recursos para daemons del sistema operativo y Kubernetes). Como resultado, en los clusters que ejecutan la versión 1.30 de Kubernetes y posteriores, hay una diferencia entre los recursos totales de un nodo y los recursos disponibles para que las cargas de trabajo las soliciten. Para obtener más información, consulte Mejores prácticas: reserva de recursos para daemons del sistema operativo y Kubernetes.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.28

Tenga en cuenta que en la versión 1.28 de Kubernetes, la política de sesgo de Kubernetes se ha ampliado. Antes de la versión 1.28 de Kubernetes, la política de sesgo necesitaba que los nodos de plano de control de un cluster no estuvieran más de dos versiones por delante de los nodos de trabajador. A partir de la versión 1.28 de Kubernetes, la política de sesgo de Kubernetes permite que los nodos de plano de control estén hasta tres versiones por delante de los nodos de trabajador. Consulte la política de soporte de sesgo de versión de Kubernetes.

Container Engine for Kubernetes aplica la política de sesgo ampliada a los clusters que ejecutan la versión 1.28 y posteriores de Kubernetes.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.27

Tenga en cuenta que la versión 1.27 de Kubernetes dejó de servir a la siguiente API de Kubernetes en desuso:

• CSIStorageCapacity (versión de API storage.k8s.io/v1beta1)

Para obtener más información sobre la migración desde las API en desuso, consulte la Guía de migración de API en desuso de Kubernetes.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.26

Tenga en cuenta que la versión 1.26 de Kubernetes dejó de servir a una serie de API de Kubernetes en desuso, que incluyen:

• FlowSchema (versión de API flowcontrol.apiserver.k8s.io/v1beta1)
• HorizontalPodAutoscaler (versión de API de escala automática/v2beta2)
• PriorityLevelConfiguration (versión de API flowcontrol.apiserver.k8s.io/v1beta1)

Para obtener más información sobre la migración desde las API en desuso, consulte la Guía de migración de API en desuso de Kubernetes.

El soporte para Kubernetes versión 1.26.7 se lanzó para abordar los siguientes problemas ascendentes con Kubernetes versión 1.26.2:

• https://github.com/opencontainers/runc/issues/3849: un bug en kubelet provoca una pérdida de memoria en los nodos que utilizan el cgroup v1 en el núcleo de Linux 5.15. Las imágenes de Oracle Linux 8.7 utilizan el núcleo 5.15 de Linux, por lo que las imágenes de Oracle Linux 8.7 se ven afectadas por el bug.
• https://github.com/cri-o/cri-o/issues/6805: faltan métricas después de un reinicio de crio.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.25

Tenga en cuenta que la versión 1.25 de Kubernetes dejó de servir a una serie de API de Kubernetes en desuso, que incluyen:

• CronJob (versión de API por lotes/v1beta1)
• EndpointSlice (versión de API de discovery.k8s.io/v1beta1)
• Evento (versión de API event.k8s.io/v1beta1)
• HorizontalPodAutoscaler (versión de API de escala automática/v2beta1)
• PodDisruptionBudget (versión de API de Policy/v1beta1)
• PodSecurityPolicy (versión de API de Policy/v1beta1)
• RuntimeClass (versión de API node.k8s.io/v1beta1)

Para obtener más información sobre la migración desde las API en desuso, consulte la Guía de migración de API en desuso de Kubernetes.

El soporte para Kubernetes versión 1.25.12 se ha lanzado para abordar los siguientes problemas ascendentes con Kubernetes versión 1.25.4:

• https://github.com/opencontainers/runc/issues/3849: un bug en kubelet provoca una pérdida de memoria en los nodos que utilizan el cgroup v1 en el núcleo de Linux 5.15. Las imágenes de Oracle Linux 8.7 utilizan el núcleo 5.15 de Linux, por lo que las imágenes de Oracle Linux 8.7 se ven afectadas por el bug.
• https://github.com/cri-o/cri-o/issues/6805: faltan métricas después de un reinicio de crio.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.22

Tenga en cuenta que la versión 1.22 de Kubernetes dejó de servir a una serie de API de Kubernetes en desuso, que incluyen:

• Recursos de webhook
• CustomResourceDefinition
• APIService
• TokenReview
• Recursos de SubjectAccessReview
• CertificateSigningRequest
• Arrendamiento
• Entrada
• IngressClass
• Recursos de RBAC
• PriorityClass
• Recursos de almacenamiento

Para obtener más información sobre la migración desde las API en desuso, consulte la Guía de migración de API en desuso de Kubernetes.

Notas sobre soporte de Container Engine for Kubernetes para Kubernetes versión 1.20

Con el anuncio de soporte para la versión 1.20.8 de Kubernetes, el tiempo de ejecución de contenedores utilizado por Container Engine for Kubernetes cambia de Docker a CRI-O. Sin embargo, no es necesario cambiar ninguna de las imágenes de Docker existentes porque las imágenes de Docker son compatibles con Open Container Initiative (OCI). En lo que respecta a Kubernetes, todas las imágenes compatibles con OCI tienen el mismo aspecto.

Tenga en cuenta lo siguiente:

• CRI-O es una implantación de la interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes, que permite el uso de tiempos de ejecución compatibles con OCI. CRI-O puede extraer las imágenes de Docker existentes y ejecutarlas en los clusters de la versión 1.20.8 de Kubernetes.
• Al utilizar el tiempo de ejecución de Docker, la configuración por defecto captura la salida estándar y los flujos de errores estándar de los contenedores mediante el formato JSON. Por el contrario, CRI-O utiliza el formato Logrus. Si utiliza una herramienta de registro como Fluentd o Fluent Bit, actualice la configuración de la herramienta para utilizar un nuevo analizador para analizar los logs de CRI. Por ejemplo:
  • Si utiliza Fluentd, utilice el analizador fluent-plugin-parser-cri.
  • Si utiliza un bit fluido, utilice el analizador de la interfaz de tiempo de ejecución de contenedor (CRI).
• Es posible que tenga un flujo de trabajo en un cluster que se base en el socket de docker subyacente /var/run/docker.sock (un patrón que se suele denominar Docker en Docker). A partir de la versión 1.20.8 de Kubernetes, dicho flujo de trabajo ya no funciona.
• Si anteriormente utilizó la CLI de Docker para ejecutar comandos en un host, debe usar crictl (una CLI para entornos de ejecución de contenedores compatibles con CRI) en su lugar.
• El proyecto de Kubernetes ascendente está dejando de lado Docker como tiempo de ejecución de contenedor después de la versión 1.20 de Kubernetes.

Para obtener más información:

• Consulte el log de cambios de Kubernetes 1.20.8 para obtener más información sobre Kubernetes 1.20.8
• Consulte las Preguntas frecuentes sobre el desuso de Dockershim para obtener más información sobre el desuso del adaptador dockershim (que anteriormente permitía al kubelet interactuar con Docker como si Docker fuera un tiempo de ejecución compatible con CRI).