Compartir a través de

Instrucciones para ejecutar una puerta de enlace autohospedada en Kubernetes en producción

  • Artículo

SE APLICA A: Desarrollador | Premium

Para ejecutar la puerta de enlace autohospedada en producción, hay varios aspectos que debe tener en cuenta. Por ejemplo, debe implementarse de manera altamente disponible, utilizar copias de seguridad de la configuración para administrar las desconexiones temporales, entre otros.

En este artículo se proporcionan instrucciones sobre cómo ejecutar una puerta de enlace autohospedada en Kubernetes para cargas de trabajo de producción para asegurarse de que se ejecutará sin problemas y de forma confiable.

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.

Sugerencia

También puede implementar la puerta de enlace autohospedada en Kubernetes y habilitar la autenticación en la instancia de API Management mediante Microsoft Entra ID.

Escalado automático

Aunque se proporciona una guía sobre el número mínimo de réplicas para la puerta de enlace auto-hospedada, se recomienda usar el escalado automático para que la puerta de enlace auto hospedada satisfaga la demanda del tráfico de forma más proactiva.

Hay dos maneras de escalar automáticamente la puerta de enlace auto-hospedada horizontalmente:

  • Escalado automático basado en el uso de recursos (CPU y memoria)
  • Escalado automático en función del número de solicitudes por segundo

Esto es posible a través de la funcionalidad nativa de Kubernetes o mediante el escalado automático controlado por eventos (KEDA) de Kubernetes. KEDA es un proyecto de incubación de CNCF que se esfuerza por simplificar el escalado automático de aplicaciones.

Nota:

KEDA es una tecnología de código abierto que no es compatible con el soporte técnico de Azure y debe ser operada por los clientes.

Escalado automático basado en recursos

Kubernetes permite escalar automáticamente la puerta de enlace auto-hospedada en función del uso de recursos mediante un Escalador automático de pod horizontal. Permite definir umbrales de CPU y memoria, así como el número de réplicas para escalar horizontalmente o reducir horizontalmente.

Una alternativa es usar el escalado automático controlado por eventos (KEDA) de Kubernetes, lo que le permite escalar cargas de trabajo basadas en una variedad de escaladores, incluida la CPU y la memoria.

Sugerencia

Si ya usa KEDA para escalar otras cargas de trabajo, se recomienda usarlo como escalador automático de aplicaciones unificado. Si ese no es el caso, se recomienda encarecidamente confiar en la funcionalidad nativa de Kubernetes a través de un Escalador automático de pod horizontal.

Escalado automático basado en tráfico

Kubernetes no proporciona un mecanismo de configuración listo para usar para el escalado automático basado en tráfico.

El escalado automático controlado por eventos (KEDA) de Kubernetes proporciona varias maneras que pueden ayudar con el escalado automático basado en tráfico:

  • Puede escalar en función de las métricas de una entrada de Kubernetes si están disponibles en Prometheus o Azure Monitor mediante un escalador listo para usar
  • Puede instalar el complemento HTTP, que está disponible en versión beta, y se escala en función del número de solicitudes por segundo.

Copia de seguridad de configuración

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 acceso de montaje del volumen debe ser /apim/config y ser propiedad del identificador de grupo 1001. Vea un ejemplo en GitHub. Para obtener información acerca del almacenamiento en Kubernetes, consulte el sitio web de Kubernetes. Para cambiar la propiedad de una ruta de acceso montada, consulte la configuración securityContext.fsGroup del sitio web de Kubernetes.

Nota

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.

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.

Sugerencia

Al instalar con Helm, el etiquetado de imágenes se optimiza automáticamente. La versión de la aplicación del gráfico de Helm ancla la puerta de enlace a una versión determinada y no se basa en latest.

Obtenga más información sobre cómo instalar una puerta de enlace autohospedada de API Management en Kubernetes con Helm.

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.

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.

Nota

Con la puerta de enlace autohospedada v2, API Management proporciona un nuevo punto de conexión de configuración: <apim-service-name>.configuration.azure-api.net. Los nombres de host personalizados se admiten para este punto de conexión y se pueden usar en lugar del nombre de host predeterminado.

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 externalTrafficPolicy 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.

Alta disponibilidad

La puerta de enlace autohospedada es un componente fundamental de la infraestructura y debe tener alta disponibilidad. Sin embargo, el error siempre podrá producirse.

Considere la posibilidad de proteger la puerta de enlace autohospedada contra la interrupción.

Sugerencia

Al instalar con Helm, habilite fácilmente la programación de alta disponibilidad mediante la habilitación de la opción de configuración highAvailability.enabled.

Obtenga más información sobre cómo instalar una puerta de enlace autohospedada de API Management en Kubernetes con Helm.

Protección contra errores de nodo

Para evitar verse afectado por errores de nodo o del centro de datos, considere la posibilidad de usar un clúster de Kubernetes que use zonas de disponibilidad para lograr una alta disponibilidad en el nivel de nodo.

Las zonas de disponibilidad permiten programar el pod de la puerta de enlace autohospedada en nodos distribuidos entre las zonas mediante:

Nota

Si usa Azure Kubernetes Service, obtenga información sobre cómo usar zonas de disponibilidad en este artículo.

Protección contra la interrupción del pod

Los pods pueden experimentar interrupciones debido a diversos motivos, como la eliminación manual de pods, el mantenimiento de nodos, etc.

Considere la posibilidad de usar presupuestos de interrupción de pods para exigir que haya disponible un número mínimo de pods en un momento dado.

Proxy HTTP(S)

La puerta de enlace autohospedada proporciona compatibilidad con el proxy HTTP(S) mediante las variables de entorno tradicionales HTTP_PROXY, HTTPS_PROXY y NO_PROXY.

Una vez configurada, la puerta de enlace autohospedada usará automáticamente el proxy para todas las solicitudes HTTP(S) salientes a los servicios back-end.

Con la versión 2.1.5 o superior, la puerta de enlace autohospedada proporciona observabilidad relacionada con el proxy de solicitud:

  • El Inspector de API mostrará pasos adicionales cuando se use el proxy HTTP(S) y las interacciones relacionadas.
  • Se proporcionan registros detallados para proporcionar una indicación del comportamiento del proxy de solicitud.

Nota:

Debido a un problema conocido con servidores proxy HTTP que usan la autenticación básica, no se admite la validación de la lista de revocación de certificados (CRL). Obtenga más información en nuestra referencia de configuración de puerta de enlace autohospedada sobre cómo configurarla correctamente.

Advertencia

Asegúrese de que se han cumplido los requisitos de infraestructura y que la puerta de enlace autohospedada todavía puede conectarse a ellos o determinadas funcionalidades no funcionarán correctamente.

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.

Se recomienda utilizar Azure Monitor Container Insights para supervisar los contenedores o 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.

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 adecuadas para producción es tres, preferiblemente combinado con la programación de alta disponibilidad de las instancias.

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.

Rendimiento

Se recomienda reducir los registros de contenedor a advertencias (warn) para mejorar el rendimiento. Obtenga más información en nuestra referencia de configuración de puerta de enlace autohospedada.

Regulación de solicitudes

La limitación de solicitudes en una puerta de enlace autohospedada se puede habilitar mediante la directiva de API Management rate-limit o rate-limit-by-key. Configure los recuentos de límites de volumen para que se sincronicen entre instancias de puerta de enlace a lo largo de los nodos de clúster mediante la exposición de los siguientes puertos en la implementación de Kubernetes para la detección de instancias:

  • Puerto 4290 (UDP), para la sincronización de la limitación del volumen
  • Puerto 4291 (UDP), para enviar latidos a otras instancias

Nota

Los recuentos de límites de volumen en una puerta de enlace autohospedada se pueden configurar para sincronizarse localmente (entre instancias de puerta de enlace en nodos de clúster), por ejemplo, mediante la implementación de gráficos de Helm para Kubernetes o con las plantillas de implementación de Azure Portal. Pero los recuentos de límites de volumen no se sincronizan con otros recursos de puerta de enlace configurados en la instancia de API Management, incluida la puerta de enlace administrada en la nube.

Seguridad

La puerta de enlace autohospedada puede ejecutarse como no raíz en Kubernetes, lo que permite a los clientes ejecutar la puerta de enlace de forma segura.

Este es un ejemplo del contexto de seguridad del contenedor de la puerta de enlace autohospedada:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Advertencia

No se admite la ejecución de la puerta de enlace autohospedada con el sistema de archivos de solo lectura (readOnlyRootFilesystem: true).

Advertencia

Al usar certificados de CA locales, la puerta de enlace autohospedada debe ejecutarse con el identificador de usuario (UID) 1001 para administrar los certificados de CA. De lo contrario, la puerta de enlace no se iniciará.

Pasos siguientes