Versiones de Kubernetes y Container Engine for Kubernetes

Descubra el esquema de control de versiones de Kubernetes y el soporte de Container Engine for Kubernetes (OKE) para diferentes versiones de Kubernetes.

Los números de versión de Kubernetes tienen el formato x.y.z, donde x es una versión principal, y es una versión secundaria y z es una versión de parche. Por ejemplo, 1.30.1.

El proyecto de Kubernetes soporta las tres versiones secundarias más recientes de Kubernetes.

Al crear un nuevo cluster de Kubernetes mediante Container Engine for Kubernetes, especifique:

  • Versión de Kubernetes que se va a ejecutar en los nodos de plano de control del cluster.
  • Versión de Kubernetes que se va a ejecutar en los nodos de trabajador del cluster. Diferentes nodos de trabajador del mismo pool de nodos pueden ejecutar diferentes versiones de Kubernetes. Los diferentes pools de nodos de un cluster pueden ejecutar diferentes versiones de Kubernetes.

La versión de Kubernetes que especifique para los nodos de trabajador en un cluster debe ser la misma versión de Kubernetes que se ejecuta en los nodos de plano de control o una versión anterior de Kubernetes que aún sea compatible. Como se describe en la política de soporte de sesgo de versión de Kubernetes, se permite una cierta cantidad de variación de versión entre los nodos de plano de control y los nodos de trabajador en un cluster:

  • Los nodos de plano de control deben ejecutar la misma versión de Kubernetes que la versión que se ejecuta en los nodos de trabajador o no tener más de dos versiones (o tres versiones, a partir de la versión 1.28 de Kubernetes) por delante.
  • Los nodos de trabajador pueden ejecutar una versión de Kubernetes que esté por detrás de la versión en los nodos de plano de control hasta dos versiones (o tres versiones, a partir de la versión 1.28 de Kubernetes), pero no más. Si la versión en los nodos de trabajador es de más de dos versiones (o tres versiones, a partir de la versión 1.28 de Kubernetes) detrás de la versión en los nodos de plano de control, las versiones de Kubernetes en los nodos de trabajador y los nodos de plano de control son incompatibles.
  • Los nodos de trabajador de un cluster no pueden ejecutar una versión más reciente de Kubernetes que los nodos de plano de control asociados.

Las restricciones garantizan que la versión secundaria admitida más antigua de los componentes kubelet y kube-proxy que se ejecutan en los nodos de trabajador de un cluster siempre sea compatible con la versión secundaria admitida más reciente de los componentes kube-apiserver, kube-scheduler, kube-controller-manager y cloud-controller-manager que se ejecutan en los nodos de plano de control del cluster.

Para obtener más información, consulte Política de soporte de sesgo de versión de Kubernetes.

Soporte de versiones secundarias de Kubernetes

Las versiones secundarias de Kubernetes suelen introducir nuevas funciones y otras mejoras. El proyecto de Kubernetes publica regularmente versiones secundarias, tres veces al año.

Oracle supervisa y valida las versiones secundarias publicadas por el proyecto de Kubernetes, y lanza el soporte de Container Engine for Kubernetes para versiones secundarias en el momento oportuno.

Container Engine for Kubernetes soporta tres versiones secundarias de Kubernetes para nuevos clusters. Durante un mínimo de 30 días después del anuncio de soporte para una nueva versión de Kubernetes, Container Engine for Kubernetes sigue soportando la cuarta versión secundaria de Kubernetes disponible más antigua. Después de ese tiempo, la versión anterior de Kubernetes deja de estar soportada.

Cuando ya no se admite una versión secundaria, no puede:
  • Cree nuevos clusters que ejecuten esa versión secundaria.
  • Agregue nuevos pools de nodos que ejecuten esa versión secundaria.

Por lo tanto, Oracle recomienda actualizar los clusters existentes que actualmente están ejecutando una versión secundaria que pronto no estará soportada para ejecutar una versión secundaria que Container Engine for Kubernetes sí soporta. Los clusters que no se actualicen seguirán funcionando como se esperaba. Sin embargo, ya no recibirán apoyo.

Puede actualizar los nodos de plano de control mediante versiones secundarias no soportadas. Kubernetes necesita actualizar los nodos de plano de control de una versión secundaria a la vez. Sin embargo, no tiene que actualizar los nodos de trabajador de una versión secundaria a la vez.

Soporte de versiones de parches de Kubernetes

Las versiones de parches de Kubernetes suelen abordar bugs críticos o vulnerabilidades de seguridad que se han identificado recientemente en una versión secundaria de Kubernetes. El proyecto de Kubernetes publica con frecuencia versiones de parches, normalmente una vez al mes, pero a veces con más frecuencia.

Oracle supervisa y valida las versiones de parches publicadas por el proyecto de Kubernetes, y lanza el soporte de Container Engine for Kubernetes para versiones de parches críticos en el momento oportuno.

Cuando Oracle le notifica el soporte de Container Engine for Kubernetes para una nueva versión de parche de Kubernetes, le recomendamos que actualice cualquier cluster que ejecute la versión secundaria correspondiente de Kubernetes a la última versión de parche disponible lo antes posible. Tiene treinta días después del anuncio del soporte de Container Engine for Kubernetes para una nueva versión de parche de Kubernetes para actualizar clusters de una versión de parche anterior a la nueva versión de parche. Después de treinta días, los clusters que ejecutan la versión de parche anterior ya no están soportados.

Tenga en cuenta que, aunque los clusters que ejecutan una versión de parche anterior dejan de estar soportados después de treinta días, es posible que la versión de parche anterior siga estando disponible para su selección. Sin embargo, Oracle recomienda seleccionar la última versión del parche.