Eventos
Compilación de Intelligent Apps
17 mar, 23 - 21 mar, 23
Únase a la serie de reuniones para crear soluciones de inteligencia artificial escalables basadas en casos de uso reales con compañeros desarrolladores y expertos.
Regístrese ahoraInstrucciones para ejecutar una puerta de enlace autohospedada en Kubernetes en producción
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
- Restricciones de propagación de topología de pod (recomendado: Kubernetes v1.19+)
- Antiafinidad de pod
Nota
Si usa Azure Kubernetes Service, obtenga información sobre cómo usar zonas de disponibilidad en este artículo.
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.
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.
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.
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.
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.
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.
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.
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á.
- Para obtener más información sobre la puerta de enlace autohospedada, consulte Introducción a la puerta de enlace autohospedada.
- Aprenda a implementar una puerta de enlace de API Management autohospedada en clústeres de Kubernetes habilitados para Azure Arc.