3 Consejos para Implementar APISIX en Kubernetes (Parte 2)

La era de la computación nativa en la nube ha visto una adopción generalizada de Kubernetes como plataforma de orquestación de contenedores, con Apache APISIX emergiendo como una puerta de enlace dinámica de API de alto rendimiento y nativa en la nube. La implementación de Apache APISIX en Kubernetes se ha vuelto cada vez más común. Sin embargo, a pesar de que el proceso de implementación de Apache APISIX en Kubernetes es relativamente sencillo, todavía hay algunos problemas clave que deben considerarse. En esta serie de artículos, profundizaremos en los siguientes temas:

1. Consideraciones sobre los métodos de implementación
2. Comprobaciones de salud, registro y monitoreo
3. Manejo de complementos y configuraciones personalizados

En el artículo anterior, discutimos el primer punto. Este artículo se centrará en el segundo punto: consideraciones sobre las comprobaciones de salud, el registro y el monitoreo.

Comprobaciones de Salud

Al implementar APISIX en Kubernetes, las comprobaciones de salud son particularmente importantes, ya que representan un requisito fundamental para las aplicaciones en Kubernetes. En Kubernetes, al configurar Liveness y Readiness Probes, se puede garantizar el estado de salud y la disponibilidad de las instancias de APISIX.

• Liveness Probe se utiliza para determinar si la aplicación está en ejecución. Si la aplicación se considera no saludable, Kubernetes reiniciará la instancia.

• Readiness Probe se emplea para determinar si la aplicación está lista para recibir tráfico. Si la aplicación no está lista, no recibirá ningún tráfico. Esto ayuda a evitar que el tráfico se envíe a instancias que no están completamente iniciadas o están dañadas.

Al configurar correctamente Liveness y Readiness Probes, Kubernetes puede gestionar automáticamente las instancias de Pod no saludables. Esto implica que cuando las instancias encuentren problemas, Kubernetes las reiniciará automáticamente o dejará de enviar tráfico a las instancias no saludables, mejorando así la disponibilidad y estabilidad del sistema.

Ejemplo de configuración YAML:

apiVersion: v1
kind: Deployment
metadata:
  name: my-apisix-pod
spec:
  containers:
  - name: my-apisix-container
    image: my-apisix-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 9080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /readyz
        port: 9080
      initialDelaySeconds: 10
      periodSeconds: 5

Este ejemplo define los Liveness y Readiness Probes para el contenedor. El Liveness Probe envía una solicitud HTTP GET a la ruta /healthz cada 10 segundos para verificar el estado de salud del contenedor. Si el contenedor no responde o devuelve un código de estado distinto de 200, Kubernetes considera que el contenedor no está saludable e intenta reiniciarlo. El Readiness Probe es similar, pero se utiliza para verificar si el contenedor está listo para recibir tráfico.

Monitoreo

Existen varios métodos para monitorear APISIX en tiempo de ejecución, siendo la integración con Prometheus un enfoque recomendado. De hecho, Prometheus sigue siendo el componente de monitoreo más ampliamente utilizado hasta la fecha.

La integración con Prometheus ayuda a recopilar y monitorear métricas para APISIX y los servicios que este proxy gestiona. Estas métricas pueden incluir tasas de solicitudes, tasas de errores, latencia y otros indicadores clave de rendimiento. Al monitorear estas métricas, se pueden identificar problemas de manera oportuna y realizar ajustes de rendimiento y solución de problemas. Asegúrese de configurar correctamente las métricas y las reglas de alerta para tomar medidas rápidamente cuando surjan problemas.

Habilitar el complemento de Prometheus en APISIX es sencillo. Primero, configure el export_uri en config.yaml.

plugin_attr:
  prometheus:
    export_uri: /apisix/metrics

Luego, habilite el complemento en la API o servicio que necesita ser analizado estadísticamente por Prometheus.

curl http://127.0.0.1:9180/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/hello",
    "plugins": {
        "prometheus":{}
    },
    "upstream": {
        ...
    }
}'

Finalmente, el servidor de Prometheus puede extraer configuraciones periódicamente desde el export_uri.

scrape_configs:
  - job_name: "apisix"
    scrape_interval: 15s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["127.0.0.1:9091"]

En uso práctico, Prometheus también requiere ser implementado de manera altamente disponible, como utilizando soluciones de código abierto como Thanos. La integración con APISIX se puede lograr utilizando el modo sidecar de Thanos.

Registro de Logs

En APISIX, los logs importantes se clasifican en dos tipos principales: logs de tráfico y logs de auditoría.

• Logs de tráfico se refieren al registro de cada solicitud cuando APISIX actúa como un proxy inverso. Estos logs, que contienen tanto el tráfico de solicitudes como la información devuelta, junto con los logs de operaciones internas de APISIX, son cruciales para el seguimiento y la solución de problemas. Normalmente, se configuran niveles y formatos de log adecuados para su registro. En escenarios prácticos, considere enviar los logs a un sistema de registro centralizado, como ELK (Elasticsearch, Logstash y Kibana), Fluentd o Splunk. APISIX proporciona complementos de log para su selección.

• Logs de auditoría se refieren principalmente a los logs generados al gestionar las configuraciones de APISIX. No solo ayudan a cumplir con los requisitos de cumplimiento, sino que también sirven para el análisis de seguridad. Al analizar los logs de auditoría, se pueden identificar riesgos de seguridad potenciales y configuraciones o comportamientos de gestión inapropiados, y se pueden tomar medidas correspondientes para mejorar la seguridad del sistema.

La versión de código abierto de APISIX proporciona una API de administración para facilitar la distribución de configuraciones, pero carece de configuraciones relacionadas con los logs de auditoría. Normalmente, los usuarios necesitan registrar estos logs por sí mismos o utilizar la edición empresarial de APISIX.

No hay muchas diferencias en la configuración de logs entre Kubernetes y otros entornos. Vale la pena mencionar que, al configurar el upstream y la información relacionada en APISIX, se utiliza comúnmente el descubrimiento de servicios de Kubernetes. Se recomienda registrar el nombre del servicio en los logs para facilitar la solución de problemas en problemas posteriores.

Conclusión

Al configurar mecanismos de comprobación de salud para detectar instancias no saludables de APISIX, Kubernetes puede tomar medidas rápidas para migrar el tráfico y facilitar la recuperación, asegurando así la continuidad y estabilidad de los servicios de API. APISIX también admite la integración con herramientas avanzadas de monitoreo como Prometheus, permitiendo el monitoreo del rendimiento y la estabilidad de las API, incluyendo métricas clave como tasas de solicitudes, tasas de errores y latencia. Esta capacidad de monitoreo permite a las organizaciones identificar rápidamente problemas potenciales y realizar ajustes y optimizaciones de rendimiento de manera oportuna, asegurando el funcionamiento eficiente de los servicios de API.