Se han eliminado las APIs beta de entrada de Kubernetes en GKE 1.23

Autopilot Standard

En esta página se proporciona información sobre la retirada de las versiones beta de la API Ingress en la versión 1.22 de Kubernetes de código abierto. GKE ha hecho una excepción única para los clústeres creados en la versión 1.21 o en una anterior para que sigan usando las APIs hasta la versión 1.23 y tengan más tiempo para migrar. Debes migrar tus clústeres a las Ingress APIs de la versión 1 antes de que la versión 1.22 alcance el fin de su ciclo de vida.

Las APIs beta de Ingress obsoletas que se han retirado en la versión 1.22 de Kubernetes son APIs beta anteriores que han pasado de la fase beta (v1beta1) a la de disponibilidad general (v1). Las APIs de disponibilidad general ofrecen garantías de compatibilidad a largo plazo y deben usarse en lugar de las APIs beta obsoletas.

Se puede interactuar con todos los objetos mediante las APIs de GA.

Importante: Antes de actualizar a la versión en la que se eliminan las APIs de Ingress, debes actualizar los clientes de la API y los manifiestos para que usen las APIs de GA.

Ingress (disponible hasta la versión 1.23 para los clústeres creados con la versión 1.21 o una anterior)

Las versiones beta de la API (extensions/v1beta1 y networking.k8s.io/v1beta1) de Ingress ya no se ofrecen para los clústeres de GKE que ejecutan la versión 1.22 o posterior si el clúster se creó con la versión 1.22 o una posterior.

Sin embargo, en los clústeres creados en GKE 1.21 o versiones anteriores y actualizados a 1.22 en la versión de parche 1.22.7-gke.300 o posterior, puedes seguir usando las versiones beta de la API hasta que el clúster se actualice a la versión 1.23. Se trata de una excepción única para los clústeres antiguos, que te da más tiempo para migrar tus clústeres de estas versiones de la API, que se han retirado de Kubernetes de código abierto en la versión 1.22.

Los clústeres que ejecuten la versión 1.23 de GKE o una posterior dejarán de servir las APIs beta Ingress obsoletas. Los manifiestos que usen esas versiones de la API ya no se podrán aplicar. Los objetos que se hayan conservado anteriormente seguirán funcionando y se podrán ver y actualizar con las nuevas versiones de la API, tanto antes como después de actualizar a la versión 1.23.

• Migra los manifiestos y los clientes de API para que usen la versión networking.k8s.io/v1 de la API.

• En la siguiente tabla se describen los cambios más importantes de la versión de la API de GA:

  Campo	Cambiar
  spec.backend	Se ha cambiado el nombre a spec.defaultBackend.
  backend serviceName	Se ha cambiado el nombre a service.name.
  servicePort	Los campos numéricos de backend servicePort se han renombrado como service.port.number. Se ha cambiado el nombre de los campos de backend de cadena servicePort a service.port.name.
  pathType	Ahora es obligatorio para cada ruta especificada. El valor puede ser Prefix, Exact o ImplementationSpecific. Para que coincida con el comportamiento indefinido de v1beta1, usa ImplementationSpecific.

Los siguientes manifiestos describen el mismo Ingress en v1 y v1beta1:

Manifiesto de v1beta1

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example
spec:
  backend:
    serviceName: default-backend
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Manifiesto de la versión 1

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
spec:
  defaultBackend:
    service:
      name: default-backend
      port:
        number: 80
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: ImplementationSpecific
        backend:
          service:
            name: test
            port:
              number: 80

Puedes usar la siguiente consulta para identificar los clientes que acceden a las APIs de Ingress v1beta1 en los clústeres en los que Google Cloud Observability está habilitado:

resource.type="k8s_cluster"
resource.labels.cluster_name="$CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.request.apiVersion=("extensions/v1beta1" OR "networking.k8s.io/v1beta1")
protoPayload.request.kind="Ingress"
NOT ("kube-system")

Buscar clústeres que usen APIs obsoletas

Puedes consultar qué clústeres usan APIs obsoletas en Estadísticas de obsolescencia. Las estadísticas de las APIs obsoletas también proporcionan información, como qué clientes de API llaman a las APIs obsoletas de tu clúster.

También puedes usar los registros de auditoría para saber qué clientes están haciendo llamadas a APIs obsoletas.

Localizar clientes de API que hacen llamadas de escritura a APIs obsoletas

En los clústeres en los que Google Cloud Observability esté habilitado, puedes usar la siguiente consulta del registro de auditoría de actividad de administrador para mostrar el uso de APIs obsoletas por parte de agentes de usuario que no estén gestionados por Google:

resource.type="k8s_cluster"
labels."k8s.io/removed-release"="DEPRECATED_API_MINOR_VERSION"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")

Sustituye DEPRECATED_API_MINOR_VERSION por la versión secundaria en la que se ha retirado la API obsoleta (por ejemplo, 1.22).

Los registros de auditoría de actividad de administración se habilitan automáticamente en los clústeres de GKE. Con esta consulta, los registros muestran agentes de usuario que hacen llamadas de escritura a las APIs obsoletas.

Localizar clientes de API que hagan llamadas de lectura a APIs obsoletas

De forma predeterminada, los registros de auditoría solo muestran las llamadas de escritura a las APIs obsoletas. Para mostrar también las llamadas de lectura a APIs obsoletas, configura los registros de auditoría de acceso a datos.

Precaución: Si habilita registros de auditoría adicionales, puede que se le apliquen costes de registro adicionales. El volumen de registros de auditoría de acceso a datos ingeridos se tiene en cuenta en la cuota de ingesta de registros de Cloud Logging.

Sigue las instrucciones para configurar registros de auditoría de acceso a datos con la consola Google Cloud . En la Google Cloud consola, selecciona la API de Kubernetes Engine. En la pestaña Tipos de registro del panel de información, selecciona Admin Read y Data Read.

Con estos registros habilitados, ahora puede usar la consulta original para ver tanto las llamadas de lectura como las de escritura a las APIs obsoletas.

Actualizar componentes de terceros

Estadísticas de obsolescencia: puede que se muestren resultados de agentes de terceros que hagan llamadas a APIs obsoletas en tu clúster.

Para resolver estos problemas, sigue estos pasos:

1. Ponte en contacto con el proveedor del software de terceros para obtener una versión actualizada.
2. Actualiza el software de terceros a la versión más reciente. Si no puedes actualizar el software, debes probar si la actualización de GKE a la versión con las APIs obsoletas eliminadas afectaría a tu servicio.

Te recomendamos que realices esta actualización y la de la versión de GKE en un clúster de staging para monitorizar las interrupciones antes de actualizar tus clústeres de producción.

Preparación para actualizar a la versión 1.23

No es necesario que elimines ni vuelvas a crear ninguno de tus objetos de API. Todos los objetos de API persistentes se pueden leer y actualizar con las nuevas versiones de la API. Sin embargo, te recomendamos que migres tus clientes y manifiestos antes de actualizar a Kubernetes 1.23. Consulta más información en la sección "Qué hacer" de la guía de migración de APIs obsoletas de Kubernetes.

Puedes consultar estadísticas y recomendaciones sobre las obsolescencias para determinar si tu clúster está usando una función o una API de Kubernetes obsoleta. Busca información valiosa y recomendaciones sobre el uso de la API beta de Ingress con el subtipo DEPRECATION_K8S_1_22_V1BETA1_API.

Las estadísticas de obsolescencia se basan en las llamadas a APIs obsoletas que se han observado en los user-agents, no en la configuración de tus objetos de Kubernetes.

Advertencia: Si no actualiza un cliente o un manifiesto antes de la actualización a la versión 1.23, no podrá leer ni modificar objetos, ni crear objetos nuevos. El cliente o el manifiesto solo podrán leer, modificar o crear objetos una vez que lo actualices.

Actualizar clústeres afectados por las obsolescencias

Para actualizar los clústeres afectados por las obsolescencias, sigue estos pasos:

1. Consulta qué user-agents usan las APIs obsoletas en la estadística de obsolescencia o en los registros.
2. Actualiza los user-agents que usan las APIs obsoletas para que usen versiones de la API compatibles.
3. Actualiza a las versiones más recientes el software de terceros que llame a APIs obsoletas.
4. Actualiza un clúster de prueba y prueba tu aplicación en un entorno de pruebas antes de actualizar tu clúster de producción para reducir el riesgo de interrupciones cuando las APIs obsoletas ya no estén disponibles.
5. Una vez que hayas actualizado todos los user-agents, GKE esperará hasta que no se haya observado el uso de APIs obsoletas durante 30 días y, a continuación, desbloqueará las actualizaciones automáticas. Las actualizaciones automáticas se realizan según la programación de lanzamientos.
6. Si no puedes actualizar un user-agent afectado, actualiza un clúster de prueba independiente para comprobar si la actualización provoca interrupciones. Si la actualización no provoca interrupciones, puedes actualizar tu clúster manualmente.

Recursos

Puede consultar más información en la documentación de Kubernetes de software libre:

• Blog de Kubernetes: API eliminadas en la versión 1.22 de Kubernetes
• Notas de la versión 1.22 de Kubernetes
• Guía de migración de APIs obsoletas de Kubernetes