En esta página, se explica cómo las funciones y las bajas de API que generan Kubernetes y otras dependencias funcionan con Google Kubernetes Engine (GKE). También se incluyen tablas con información sobre las bajas específicas de Kubernetes. Para obtener información sobre cómo ver la exposición a las próximas bajas, consulta Visualiza las estadísticas y recomendaciones de baja.
¿Qué son las bajas de Kubernetes?
Los clústeres de GKE funcionan con el sistema de administración de clúster de código abierto de Kubernetes. El conjunto de atributos de Kubernetes evoluciona con el tiempo y, a medida que se incorporan nuevas funciones a lo largo del tiempo, es posible que se deba quitar una función. O bien un atributo puede cambiar de la fase Beta a la fase de disponibilidad general. La política de baja de Kubernetes garantiza que los usuarios tengan un proceso predecible para que puedan migrar de una función o API obsoleta antes de que se quite.
Después de su período de baja, cuando se quita una característica o una API, ya no se puede usar a partir de la versión secundaria de GKE correspondiente. Si un clúster dependía de una función o API obsoleta, podría verse afectada la funcionalidad.
Bajas causadas por otras dependencias upstream
Además de las funciones y APIs de Kubernetes, GKE también proporciona funciones que usan otros proveedores, como las imágenes de nodo de Windows con el respaldo de Microsoft y las imágenes de nodo de Ubuntu con el respaldo de Canonical. Cuando estos proveedores ascendentes cancelan o finalizan la compatibilidad con una característica, es posible que GKE tenga que quitar la característica correspondiente. En las tablas de esta página, también se proporciona información sobre las bajas y las eliminaciones futuras que generan las dependencias ascendentes además de Kubernetes.
Cómo funcionan las bajas de Kubernetes con GKE
La ejecución de aplicaciones en GKE implica la responsabilidad compartida entre tú y GKE.
Como usuario, debes evaluar y mitigar cualquier exposición a las funciones y API obsoletas que se quitan en las próximas versiones secundarias de Kubernetes. En las siguientes secciones, obtendrás información sobre cómo GKE facilita este proceso mediante la detección del uso de las API y las funciones de Kubernetes obsoletas, cómo compartir estadísticas sobre este uso y cómo proporcionar recomendaciones para migrar a las funciones y las API compatibles con las próximas versiones secundarias.
Si GKE detecta que un clúster usa una característica que se quita en una próxima versión secundaria de Kubernetes, se pausan las actualizaciones automáticas del clúster a la siguiente versión secundaria, y GKE comparte una estadística y recomendación de baja.
¿Qué sucede cuando GKE pausa las actualizaciones automáticas?
Si GKE detecta el uso de una función o API obsoleta, GKE pausa las actualizaciones automáticas para evitar que el clúster se actualice a un estado dañado. Las actualizaciones a la siguiente versión secundaria de Kubernetes están detenidas, pero GKE continúa entregando actualizaciones de parches al clúster en la versión secundaria actual. Por ejemplo, si un clúster se encuentra en la versión 1.21.11-gke.1100 y tiene llamadas a APIs obsoletas que se quitan de la versión 1.22, GKE pausa la actualización automática a la versión 1.22. Sin embargo, GKE no pausa la actualización automática a una versión de parche nueva, 1.21.11-gke.1900.
Como GKE no puede garantizar que se detecte todo el uso, GKE no puede garantizar que las actualizaciones siempre estén pausadas cuando se use una API o una función obsoleta. Para asegurarse de que un clúster no se actualice, se deben usar las exclusiones de mantenimiento.
¿Cuándo se reanudan las actualizaciones automáticas de GKE?
Una vez que GKE no detecta el uso de la función obsoleta o llama a las APIs obsoletas durante 30 días, el clúster se actualiza de forma automática si la siguiente versión secundaria es la versión predeterminada en el canal de versiones del clúster Para ver cuándo la versión secundaria se convierte en el canal de versiones predeterminado de tu clúster, consulta Programa de actualizaciones.
Si GKE sigue detectando el uso de la función obsoleta en el clúster, GKE mantendrá el clúster en su versión secundaria actual hasta la fecha del final de la vida útil de la versión. Una vez que se alcanza esta fecha, que está disponible en el Programa de versiones, el clúster se actualiza automáticamente a la siguiente versión secundaria, y el entorno del clúster puede verse afectado por la eliminación de la función que se siguen usando. Para obtener más información, consulta las Preguntas frecuentes sobre la compatibilidad de versiones.
¿Qué son las recomendaciones y estadísticas de baja?
Si GKE detecta que un clúster usa una función que se quita en una próxima versión secundaria de Kubernetes, GKE comparte una estadística y una recomendación de baja, lo que te notifica del uso de una función obsoleta por parte del clúster. Esta estadística proporciona información sobre el último uso detectado y más detalles según el tipo de baja. Para obtener información sobre cómo ver esta información, consulta Visualiza estadísticas y recomendaciones sobre las bajas.
Evalúa y mitiga la exposición a las próximas bajas de Kubernetes
GKE proporciona guías de migración que te indican cómo migrar de API y funciones obsoletas a las compatibles con la próxima versión secundaria. Para obtener una lista de las próximas bajas y sus guías de migración, consulta la información sobre las bajas de Kubernetes.
Si bien GKE comparte estadísticas sobre los clústeres que detecta que se exponen a una baja, no se garantiza la detección de todas las exposiciones a las bajas. Por ejemplo, si no se usó una función obsoleta en los últimos 30 días, GKE no detecta ningún uso y no se genera una estadística ni recomendación.
Debes evaluar de forma independiente la exposición del entorno del clúster a cualquier baja próxima antes de actualizar el clúster a la siguiente versión secundaria. Puedes ejercer el control sobre el proceso de actualización eligiendo un canal de versiones, mediante exclusiones y períodos de mantenimiento, o actualizando los clústeres de forma manual si determinaste que no están expuestas a bajas en la siguiente versión secundaria.
Resuelve la exposición a bajas de Kubernetes
Revisa las bajas futuras para tomar medidas. Visualiza estadísticas y recomendaciones sobre las bajas para evaluar si tu clúster está expuesto y usar guías de migración a fin de mitigar la exposición antes de que la última versión secundaria disponible que admita la función alcance el final de su ciclo de vida.
Después de realizar cambios para detener el uso de APIs o funciones obsoletas en tu clúster, GKE espera hasta que ya no haya observado el uso de APIs o funciones obsoletas durante 30 días y, luego, desbloquea las actualizaciones automáticas. Las actualizaciones automáticas continúan según el programa de lanzamientos.
También puedes actualizar tu clúster de forma manual si confirmaste que la actualización no causa interrupciones en el entorno del clúster. Para ello, primero debes crear un clúster de prueba y verificar si la actualización causa alguna interrupción. Si no es así, puedes actualizar tu clúster de forma manual.
Cuando descartas una recomendación, solo la ocultas para todos los usuarios. Las actualizaciones automáticas permanecen en pausa hasta que migres de las funciones obsoletas y GKE no detecte el uso de las funciones obsoletas durante 30 días consecutivos.
Información sobre las bajas de Kubernetes
En las siguientes secciones, se proporciona información sobre las bajas en curso, incluidas guías en las que se explica cómo migrar a funciones o API compatibles con versiones secundarias de Kubernetes disponibles. Puedes revisar estas tablas para ver si GKE detecta e informa el uso mediante estadísticas y recomendaciones.
En estas tablas, solo se proporciona información sobre las bajas en curso y se omite la información incluida antes sobre las funciones o las APIs que dejaron de estar disponibles con versiones que ya pasaron su fecha de final del ciclo de vida.
Bajas de funciones de Kubernetes
En la siguiente tabla, se describen las bajas de funciones de GKE en curso y la versión en la que ya no se admiten esas funciones:
| Nombre | Obsoleto | Eliminado | Más información | ¿GKE detecta e informa el uso? |
|---|---|---|---|---|
| Certificados TLS firmados con el algoritmo SHA-1 | GKE versión 1.24 | GKE versión 1.29 | Asistencia para la eliminación de los certificados TLS SHA-1 | Sí |
| Complemento de autenticación integrado para clientes de Kubernetes | GKE versión 1.22 | GKE versión 1.25 | Complemento de autenticación obsoleto para clientes de Kubernetes | No |
| PodSecurityPolicy | GKE versión 1.21 | GKE versión 1.25 | Baja de PodSecurityPolicy | Sí |
| Imágenes de nodos basadas en Docker | GKE versión 1.20 | GKE versión 1.24 | Baja de la imagen de nodo de Docker | Sí |
| Campo de nombre común X.509 en los certificados de webhook | GKE versión 1.19 | GKE versión 1.23 | Baja del campo de CN de los certificados de webhook | Sí |
Bajas de la API de Kubernetes
En la siguiente tabla, se proporciona una descripción general de las API de Kubernetes que ya no están disponibles y ya no se entregan, ordenadas por versión de Kubernetes:
| Versión de Kubernetes | Más información | ¿GKE detecta e informa el uso? |
|---|---|---|
| 1.29 | APIs obsoletas de Kubernetes 1.29 | Sí |
| 1.27 | APIs obsoletas de Kubernetes 1.27 | Sí |
| 1.26 | APIs obsoletas de Kubernetes 1.26 | Sí |
| 1.25 | APIs obsoletas de Kubernetes 1.25 | Sí |
| 1.22 | APIs de Kubernetes 1.22 obsoletas, APIs de Ingress de Kubernetes Beta quitadas en GKE 1.23 |
Sí |
Otras bajas de funciones
En la siguiente tabla, se proporciona información sobre las bajas y las eliminaciones generadas por otros proveedores upstream que no forman parte del proyecto de código abierto de Kubernetes.
| Nombre | Obsoleto | Eliminado | Más información | ¿GKE detecta e informa el uso? |
|---|---|---|---|---|
| Imágenes de nodo de Windows Server Semi-Annual Channel (SAC) | No disponible | 9 de agosto de 2022 | Fin del servicio de Windows Server SAC | No |