Implementación de una puerta de enlace autohospedada en Kubernetes

  • Artículo
  • 7 minutos para leer

En este artículo se describen los pasos para implementar un componente de puerta de enlace autohospedada de Azure API Management en un clúster de Kubernetes.

Nota

También puede implementar una puerta de enlace autohospedada en un clúster de Kubernetes habilitado para Azure Arc como una extensión de clúster.

Prerrequisitos

Implementación en Kubernetes

  1. Seleccione Puertas de enlace en Deployment and infrastructure (Implementación e infraestructura).

  2. Seleccione el recurso de puerta de enlace autohospedada que quiere implementar.

  3. Seleccione Implementación.

  4. Se ha generado automáticamente un token de acceso en el cuadro de texto Token según los valores predeterminados de Expiración y Clave secreta. Si es necesario, elija valores en uno o ambos controles para generar un nuevo token.

  5. Seleccione la pestaña Kubernetes en Scripts de implementación.

  6. Seleccione el vínculo del archivo <gateway-name>.yml y descargue el archivo YAML.

  7. Seleccione el icono copiar situado en la esquina inferior derecha del cuadro de texto Implementar para guardar los comandos kubectl en el Portapapeles.

  8. Pegue los comandos en la ventana de terminal o comando. El primer comando crea un secreto de Kubernetes que contiene el token de acceso generado en el paso 4. El segundo comando aplica el archivo de configuración descargado en el paso 6 al clúster de Kubernetes y espera que el archivo esté en el directorio actual.

  9. Ejecute los comandos para crear los objetos de Kubernetes necesarios en el espacio de nombres predeterminado e inicie los pods de la puerta de enlace autohospedada desde la imagen de contenedor descargada de Microsoft Azure Container Registry.

  10. Ejecute el siguiente comando para comprobar si la implementación se realizó correctamente. Tenga en cuenta que la creación de todos los objetos y la inicialización de los pods pueden tardar un poco.

    kubectl get deployments
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s

  11. Ejecute el siguiente comando para comprobar si el servicio se creó correctamente. Tenga en cuenta que las direcciones IP y los puertos del servicio serán diferentes.

    kubectl get services
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
<gateway-name>   LoadBalancer   10.99.236.168   <pending>     80:31620/TCP,443:30456/TCP   9m1s

  12. Vuelva a Azure Portal y seleccione Información general.

  13. Confirme que Estado muestra una marca de verificación verde seguida de un recuento de nodos que coincide con el número de réplicas especificado en el archivo YAML. Este estado significa que los pods de puerta de enlace autohospedados implementados se comunican correctamente con el servicio de API Management y tienen un "latido" normal.

    Estado de la puerta de enlace

Sugerencia

Ejecute el comando kubectl logs deployment/<gateway-name> para ver los registros de un pod seleccionado aleatoriamente si hay más de uno. Ejecute kubectl logs -h para un conjunto completo de opciones de comando; por ejemplo, para ver los registros de un pod o contenedor específico.

Consideraciones de implementación en producción

Access token

Sin un token de acceso válido, una puerta de enlace autohospedada no puede tener acceso a los datos de configuración del punto de conexión del servicio API Management asociado ni descargarlos. El token de acceso puede ser válido durante 30 días como máximo. Se debe regenerar y el clúster se debe configurar con un token nuevo, ya sea manualmente o mediante automatización antes de que expire.

Al automatizar la actualización de tokens, use esta operación de la API de administración para generar un nuevo token. Para obtener información sobre la administración de secretos de Kubernetes, consulte el sitio web de Kubernetes.

Espacio de nombres

Los espacios de nombres de Kubernetes ayudan a dividir un solo clúster entre varios equipos, proyectos o aplicaciones. Los espacios de nombres proporcionan un ámbito para los recursos y los nombres. Pueden asociarse con una cuota de recursos y directivas de control de acceso.

Azure Portal proporciona comandos para crear recursos de la puerta de enlace autohospedada en el espacio de nombres predeterminado. Este espacio de nombres se crea automáticamente, existe en todos los clústeres y no se puede eliminar. Considere la posibilidad de crear e implementar una puerta de enlace autohospedada en un espacio de nombres independiente en producción.

Número de réplicas

El número mínimo de réplicas adecuado en producción es dos.

De forma predeterminada, la puerta de enlace autohospedada se implementa con una estrategia de implementación RollingUpdate. Revise los valores predeterminados y considere la posibilidad de establecer de forma explícita los campos maxUnavailabley maxSurge, especialmente si usa un número elevado de réplicas.

Recursos de contenedor

De forma predeterminada, el archivo YAML proporcionado en Azure Portal no especifica solicitudes de recursos de contenedor.

No es posible predecir de forma confiable y recomendar la cantidad de recursos de memoria y CPU por contenedor y el número de réplicas necesarias para admitir una carga de trabajo específica. Hay muchos factores en juego; por ejemplo:

  • Hardware específico en el que se ejecuta el clúster
  • Presencia y tipo de virtualización
  • Número y tasa de conexiones de cliente simultáneas
  • Velocidad de solicitudes
  • Tipo y número de directivas configuradas
  • Tamaño de carga útil y si las cargas útiles se almacenan en búfer o se transmiten en secuencias
  • Latencia del servicio back-end

Se recomienda establecer las solicitudes de recursos en dos núcleos y 2 GiB como punto de partida. Realice una prueba de carga y escale o reduzca vertical u horizontalmente en función de los resultados.

Etiqueta de la imagen de contenedor

El archivo YAML proporcionado en Azure Portal usa la etiqueta más reciente. Esta etiqueta siempre hace referencia a la versión más reciente de la imagen de contenedor de la puerta de enlace autohospedada.

Considere la posibilidad de usar una etiqueta de versión específica en producción para evitar una actualización involuntaria a una versión más reciente.

Puede descargar una lista completa de etiquetas disponibles.

Directiva de DNS

La resolución de nombres DNS desempeña un rol fundamental en la capacidad de una puerta de enlace autohospedada para conectarse a las dependencias en Azure y enviar llamadas API a los servicios de back-end.

El archivo YAML proporcionado en Azure Portal aplica la directiva ClusterFirst predeterminada. Esta directiva hace que las solicitudes de resolución de nombres que el DNS del clúster no resuelve se reenvíen al servidor DNS ascendente heredado del nodo.

Para obtener información acerca de la resolución de nombres en Kubernetes, consulte el sitio web de Kubernetes. Considere la posibilidad de personalizar la directiva de DNS o la configuración de DNS según corresponda para su configuración.

Directiva de tráfico externo

El archivo YAML proporcionado en Azure Portal establece el campo externalTrafficPolicy en el objeto Servicio en Local. Esto conserva la dirección IP del autor de la llamada (accesible en el contexto de la solicitud) y deshabilita el equilibrio de carga entre nodos, lo que elimina los saltos de red causados por él. Tenga en cuenta que esta configuración puede provocar una distribución asimétrica del tráfico en implementaciones con un número desigual de pods de puerta de enlace por nodo.

Nombres de dominio personalizados y certificados SSL

Si usa nombres de dominio personalizados para los puntos de conexión de API Management, especialmente si usa un nombre de dominio personalizado para el punto de conexión de administración, es posible que tenga que actualizar el valor de config.service.endpoint en el archivo <gateway-name>.yaml para reemplazar el nombre de dominio predeterminado por el nombre de dominio personalizado. Asegúrese de que se puede acceder al punto de conexión de administración desde el pod de la puerta de enlace autohospedada del clúster de Kubernetes.

En este escenario, si el certificado SSL que usa el punto de conexión de administración no está firmado por una entidad de certificación conocida, debe asegurarse de que el pod de la puerta de enlace autohospedada confíe en el certificado de CA.

Copia de seguridad de configuración

Para obtener información sobre el comportamiento de la puerta de enlace autohospedada en caso de interrupción temporal de la conectividad de Azure, consulte Información general de la puerta de enlace autohospedada.

Configure un volumen de almacenamiento local para el contenedor de la puerta de enlace autohospedada, de modo que pueda conservar una copia de seguridad de la última configuración descargada. Si la conectividad está inactiva, el volumen de almacenamiento puede usar la copia de seguridad al reiniciar. La ruta de montaje del volumen debe ser /apim/config. Vea un ejemplo en GitHub. Para obtener información acerca del almacenamiento en Kubernetes, consulte el sitio web de Kubernetes.

Registros y métricas locales

La puerta de enlace autohospedada envía telemetría a Azure Monitor y Azure Application Insights según los valores de configuración del servicio API Management asociado. Cuando la conectividad a Azure se pierde temporalmente, se interrumpe el flujo de telemetría a Azure y se pierden los datos mientras dure la interrupción. Considere la posibilidad de configurar la supervisión local para garantizar la capacidad de observar el tráfico de la API y evitar la pérdida de telemetría durante las interrupciones de la conectividad de Azure.

Pasos siguientes