1.36 Información sobre la versión y acciones de actualización

Consulta la información sobre la versión « 1.36 » de « IBM Cloud® Kubernetes Service ». Para obtener más información sobre la versión del proyecto « Kubernetes » ( 1.36 ), consulta el registro de cambios de « Kubernetes ».

Esta insignia indica que se trata de una certificación de la versión Kubernetes 1.36 para IBM Cloud Kubernetes Service
Kubernetes, con la insignia de certificación de la versión 1.36

IBM Cloud Kubernetes Service Es un producto certificado como « Kubernetes » para la versión 1.36 en el marco del programa de certificación de conformidad de software « Kubernetes » de la CNCF. Kubernetes® es una marca registrada de The Linux Foundation en Estados Unidos y otros países, y se utiliza en virtud de una licencia de The Linux Foundation.

Calendario de releases

La siguiente tabla recoge el calendario previsto de lanzamiento de la versión 1.36 de IBM Cloud® Kubernetes Service. Puede utilizar esta información con fines de planificación, por ejemplo, para estimar el momento en general en el que la versión puede dejar de estar soportada.

Las fechas que están marcadas con el símbolo † son provisionales y están sujetas a cambios.

Calendario de lanzamiento de la versión « IBM Cloud Kubernetes Service » 1.36
Versión ¿Está soportada? Fecha del release Fecha no soportada
1.36 Sí 26 de junio de 2026 1 de agosto de 2027 †

Preparación para la actualización

Para obtener una lista completa de los cambios que podrían afectar a tus aplicaciones implementadas al actualizar tu clúster, consulta el registro de cambios de la comunidad Kubernetes y el registro de cambios de versión IBM correspondiente a la versión 1.36. También puedes consultar las útiles advertencias de Kubernetes.

Kubernetes El servidor API y el túnel de Konnectivity se ofrecen a través del puerto 443

El servidor de la API de Kubernetes y el túnel de Konnectivity ahora se alojan en el puerto estándar 443 de HTTPS, en lugar de en un puerto de nodo asignado dinámicamente (por ejemplo, un puerto del rango 20000–32767 ). El tráfico se redirige al servicio de fondo adecuado mediante el enrutamiento basado en nombres de host, por lo que cada función tiene un nombre de host específico, aunque todos los servicios compartan el puerto 443. Este cambio facilita la conexión a tu clúster desde entornos de red restrictivos, ya que ya no es necesario permitir el paso de un puerto no estándar a través de tus cortafuegos y controles de salida. Tu clúster expone dos nombres de host específicos a través de sus puntos de conexión de servicio privados y públicos:

  • <cluster>.api.<region-domain> — el punto final del servidor de la API de Kubernetes
  • <cluster>.tunnel.<region-domain> — el punto final del túnel de Konnectivity utilizado para la comunicación entre el plano de control y el nodo de trabajo

Esta función está disponible a partir de la versión 1.36 de IKS en las siguientes regiones: Montreal (ca-mon), Chennai (in-che) y Mumbai (in-mum). Próximamente se añadirá compatibilidad con otras regiones.

Si has actualizado un clúster que utiliza el punto de conexión de servicio público, un archivo kubeconfig que siga haciendo referencia a dicho punto de conexión ( URL ) seguirá utilizando el puerto antiguo, lo que provocará que comandos kubectl fallen debido a tiempos de espera de conexión agotados. Para evitarlo, descarga un nuevo archivo kubeconfig ejecutando el comando ibmcloud ks cluster config``, o bien cambia manualmente el puerto del archivo kubeconfig que ya tienes por el 443.

  • Nuevos clústeres: No es necesario realizar ninguna acción. Los nuevos clústeres se crean con puntos finales en el puerto 443 y el archivo kubeconfig que descargas ya utiliza el puerto 443.
  • Clústeres actualizados que utilizan únicamente el punto de conexión del servicio privado: No es necesario tomar ninguna medida de inmediato. Las conexiones existentes que apuntan a la dirección anterior NodePort seguirán funcionando tras la actualización. El nuevo archivo kubeconfig que descargues utiliza el punto final del puerto 443.
  • Reglas de red personalizadas: Actualiza cualquier regla del cortafuegos, del grupo de seguridad o de la lista de permisos de salida que haga referencia explícita al antiguo puerto del plano de control de número alto para permitir, en su lugar, el tráfico de salida HTTPS en el puerto 443. Se pueden eliminar todas las reglas que fijaban el puerto anterior con el número más alto.
  • Listas de permitidos basadas en IP: Los registros DNS del punto final del servicio público ahora apuntan a las direcciones IP del front-end de Akamai IP Protect (IPP), en lugar de a las direcciones IP del equilibrador de carga (NLB) que se utilizaban anteriormente. Si tu cortafuegos o tus reglas de salida permiten el tráfico hacia tu clúster por dirección IP de destino, actualízalas para que utilicen los rangos de IP actuales de Akamai IPP.
El acceso anónimo al servidor de la API de Kubernetes ya está restringido

El acceso anónimo al servidor de la API de Kubernetes queda ahora restringido a los puntos finales de comprobación de estado (/healthz, /readyz, /livez, /livez/ping). El resto de puntos finales requieren autenticación (por ejemplo, /version). Esto reduce el riesgo derivado de configuraciones erróneas accidentales del modelo RBAC que otorgan permisos a system:anonymous o system:unauthenticated.

Kubernetes El panel de control ha quedado obsoleto

El panel de control de código abierto « Kubernetes » ha quedado obsoleto y se ha archivado. El panel de control de « Kubernetes » ya no se instala en los clústeres recién creados y se elimina de los clústeres que ejecutan versiones anteriores al actualizar a « 1.36 ». El complemento «Headlamp » está disponible como sustituto de la interfaz de usuario de « Kubernetes ».

NVIDIA Los controladores de la GPU ya no se instalan automáticamente

A partir de la versión Kubernetes 1.36, IBM Cloud Kubernetes Service ya no instala automáticamente los controladores de GPU NVIDIA en los nodos de trabajo con GPU. Para ejecutar cargas de trabajo de GPU, debes instalar y gestionar tú mismo los controladores de la GPU. Para obtener más información, consulta « Migración a controladores de GPU autogestionados ».

El escalador automático de clústeres aún no es compatible con la versión 1.36. No actualices tu clúster a la versión 1.36 si tienes instalado el autoscaler.

Antes de actualizar el nodo maestro

Revisa los siguientes cambios que debes realizar antes de actualizar el servidor maestro de Kubernetes.

Cambios que hay que realizar antes de actualizar el maestro a Kubernetes 1.36
Tipo Descripción
Eliminado: el complemento de volumen « Portworx » integrado en el árbol de archivos El complemento de volumen « Portworx » integrado en el árbol de fuentes se ha eliminado en Kubernetes 1.36, con lo que se completa la migración al controlador CSI Portworx. También se han eliminado la puerta de acceso a la función « CSIMigrationPortworx » (GA y bloqueada desde 1.33 ) y la puerta de acceso a la función «alpha InTreePluginPortworxUnregister », y todas las operaciones de volumen Portworx integradas en el árbol se redirigen a CSI. Antes de realizar la actualización, asegúrate de que el controlador CSI de Portworx esté instalado y de que tus recursos StorageClass, PersistentVolume y PersistentVolumeClaim hagan referencia al controlador CSI. Los clústeres que sigan utilizando el complemento «in-tree» dejarán de tener acceso a los volúmenes « Portworx » tras la actualización.
Modificado: Validación más estricta de direcciones IP y CIDR La puerta de función « StrictIPCIDRValidation » está activada por defecto en el servidor de la API. Los campos de la API que contienen valores IP o CIDR ya no aceptan direcciones con ceros iniciales superfluos (por ejemplo, 010.000.000.005 en lugar de 10.0.0.5) ni valores CIDR con bits de host ambiguos (por ejemplo, 192.168.0.5/24 en lugar de 192.168.0.0/24 o 192.168.0.5/32). Revisa tus manifiestos y herramientas para recursos como Service, NetworkPolicy y EndpointSlice, y corrige cualquier valor de IP o CIDR no canónico antes de actualizar. Una vez actualizado el servidor maestro, se rechazan las solicitudes que crean o actualizan objetos con valores no válidos.
Modificado: Se ha cambiado el nombre de las métricas del plano de control La métrica « volume_operation_total_errors » (kube-controller-manager) pasa a llamarse « volume_operation_errors_total », y la métrica « etcd_bookmark_counts » pasa a llamarse « etcd_bookmark_total ». Si utilizas paneles de supervisión personalizados o reglas de alerta que hacen referencia a los nombres antiguos de las métricas, actualízalos con los nuevos nombres para que la supervisión siga funcionando tras la actualización del plano de control.
Se ha eliminado: el complemento de volumen « git-repo » El complemento de volumen « git-repo » está desactivado por defecto y no hay ninguna opción para volver a activarlo; la función « GitRepoVolumeDriver » ya no tiene ningún efecto. Este tipo de volumen ha dejado de ser compatible con IBM Cloud Kubernetes Service desde la versión 1.33. Si alguna carga de trabajo sigue utilizando un volumen de tipo « gitRepo », migra dicha carga de trabajo a un volumen de tipo « emptyDir » que contenga un contenedor de tipo « init » que clone el repositorio mediante git. Para obtener más información, consulta « Eliminación del controlador de volumen « gitRepo » integrado en el árbol ».

Después de actualizar el maestro

Revisa los siguientes cambios que debes realizar tras actualizar el servidor maestro de Kubernetes.

Cambios que hay que realizar tras actualizar el maestro a Kubernetes 1.36
Tipo Descripción
Obsoleto: Servicio .spec.externalIPs El campo « .spec.externalIPs » de los recursos « Service » ha quedado obsoleto, y el servidor de la API devuelve ahora una advertencia de obsolescencia cuando se establece dicho campo. Planea dejar de utilizar externalIPs y, en su lugar, redirigir el tráfico externo a través de un servicio de LoadBalancer o de un Ingress. Para obtener más información, consulta « Direcciones IP externas ».
Modificado: Perfil predeterminado de « kubectl debug » El perfil predeterminado de kubectl debug cambia de legacy a general. Si tienes scripts o guías de ejecución que dependen del comportamiento del perfil « legacy », indica explícitamente « --profile=legacy ». Está previsto eliminar el perfil « legacy » en Kubernetes 1.39. Para obtener más información, consulta la sección « Depuración de pods en ejecución ».
Modificado: orden de los eventos del informador de client-go (AtomicFIFO) La función «client-go AtomicFIFO » está activada por defecto. Las tiendas de Informer ahora se actualizan por completo a una versión de recursos coherente antes de que se llamen los controladores por elemento OnAdd, OnUpdate y OnDelete, y el proceso de resincronización de Informer ha cambiado ligeramente, lo que puede dar lugar a diferencias apreciables en el momento de la invocación de los controladores. Prueba los controladores y operadores personalizados que incorporan client-go. Si observas retrocesos, puedes configurar temporalmente la puerta de acceso « AtomicFIFO » de la función «client-go» en « false » en tu propio binario del controlador mientras realizas los ajustes necesarios.
Modificado: Validación numérica más estricta en « CustomResourceDefinition » CustomResourceDefinition La validación (CRD) ahora aplica de forma estricta los rangos de los formatos numéricos int32, int64, float y double cuando se definen en un esquema. Los objetos existentes que ya contienen valores fuera de rango se conservan mediante el mecanismo de validación por escalonamiento, pero los valores nuevos o actualizados deben estar dentro del rango. Revisa los recursos personalizados que utilizan estos formatos numéricos.
Obsoleto: campo «Lista de permitidos» del complemento de credenciales En la lista de permitidos del complemento de credenciales de cliente, el campo « AllowlistEntry.Name » pasa a llamarse « AllowlistEntry.Command ». Si configuras una lista de permitidos para un complemento de credenciales (por ejemplo, a través de kuberc), actualiza tu configuración para utilizar el nuevo nombre de campo.
Obsoleto: Acceso directo a metav1.FieldsV1.Raw El acceso directo al campo « Raw » de « metav1.FieldsV1 » ha quedado obsoleto. El código que crea o lee objetos FieldsV1 (por ejemplo, controladores o herramientas que inspeccionan campos gestionados) debe migrarse a los nuevos métodos de acceso NewFieldsV1(string), GetRawBytes(), GetRawString()`` y SetRawBytes() .
Acción necesaria: Programador personalizado PreBind plugins El marco del programador ahora permite ejecutar en paralelo los complementos de PreBind. Si mantienes complementos personalizados para el programador, actualízalos para que devuelvan un PreBindPreFlightResult desde el método PreBindPreFlight ; si devuelven nil , se mantiene el comportamiento secuencial actual, y los complementos optan por la ejecución en paralelo devolviendo AllowParallel: true``. Esta acción solo se aplica a los clústeres que ejecutan complementos de programador personalizados.
Acción necesaria: RBAC granular para los controladores DRA Cuando se habilita la función « DRAResourceClaimGranularStatusAuthorization » (en fase beta en 1.36 ), los controladores y los controladores de la asignación dinámica de recursos (DRA) necesitan permisos RBAC granulares para actualizar los estados de ResourceClaim. Los programadores y controladores necesitan update o patch en resourceclaims/binding, y los controladores DRA necesitan associated-node:update o arbitrary-node:update en resourceclaims/driver, con restricciones según su resourceNames específico. Si utilizas controladores DRA, actualiza su RBAC. Esta acción solo se aplica a los clústeres que utilizan DRA.