Container Service for Kubernetes:Best practices for the NGINX Ingress controller

• Improve the performance and stability of the NGINX Ingress controller

  • Use appropriate replicas and resource limits

  • Use exclusive nodes to improve NGINX Ingress performance and stability

  • Optimize NGINX Ingress performance

  • Configure HPA for the NGINX Ingress controller for auto scaling

  • Configure a proper preStop hook for backend services

• Improve the observability of the NGINX Ingress controller

• Advanced features of the NGINX Ingress controller

  • Use multiple NGINX Ingress controllers

  • Access the NGINX Ingress controller from within a cluster

  • Use WAF

  • Implement blue-green deployments or canary releases by using the NGINX Ingress controller

  • Proxy non-HTTP requests by using the NGINX Ingress controller

• References

Réplicas adecuadas y límites de recursos

De forma predeterminada, un controlador NGINX Ingress instalado durante la creación del clúster o desde la página Add-ons cuenta con dos réplicas. Ajuste esta cantidad según los requisitos de su negocio. Asegúrese de que los pods del controlador NGINX Ingress se distribuyan en distintos nodos para evitar la contención de recursos y los puntos únicos de falla. También puede asignar nodos exclusivos para garantizar el rendimiento y la estabilidad. Para obtener más información, consulte Use exclusive nodes to improve NGINX Ingress performance and stability. No establezca límites de recursos para el controlador NGINX Ingress; así evitará interrupciones de tráfico por eventos de falta de memoria (OOM). Si es obligatorio establecerlos, configure el límite de CPU como mínimo en 1,000 millicores y el de memoria como mínimo en 2 GiB.

Uso de nodos exclusivos

• Si requiere alta estabilidad, asigne nodos exclusivos al controlador Ingress para evitar la contención de recursos. Para obtener más información, consulte Deploy a highly available NGINX Ingress controller.

• En escenarios de alta carga, también puede configurar el controlador Ingress para admitir aplicaciones con mucho tráfico. Para obtener más información, consulte Configure the NGINX Ingress controller for high-load scenarios.

Optimización del rendimiento de NGINX Ingress

La optimización del rendimiento del controlador NGINX Ingress abarca dos áreas principales: el ajuste de parámetros del sistema y el ajuste de parámetros de NGINX.

• Ajuste de parámetros del sistema: los sistemas operativos de Alibaba Cloud incluyen optimizaciones predeterminadas para los parámetros comunes. Otros parámetros del sistema que podría necesitar ajustar incluyen el backlog máximo del sistema y el rango de puertos disponibles. Este ajuste ayuda a asegurar que NGINX maneje una alta concurrencia y previene fallas de conexión hacia los backends por agotamiento de puertos.

• Ajuste de parámetros de NGINX:

  • Ajustar el número máximo de conexiones por proceso worker garantiza que el controlador NGINX Ingress maneje una alta concurrencia.

  • Aumentar el tiempo de espera de conexión: a diferencia del comportamiento predeterminado de NGINX, el controlador NGINX Ingress usa conexiones keep-alive para enviar solicitudes a los pods del backend. Por lo tanto, aumente el tiempo de espera de conexión para permitir que una sola conexión procese más solicitudes y reducir la sobrecarga de crear conexiones nuevas.

  • Establecer el tiempo de espera de keep-alive: configure el tiempo de espera de keep-alive de los servicios del backend para que sea igual o mayor al tiempo de espera de conexión del controlador NGINX Ingress, cuyo valor predeterminado es 900 s en los clústeres ACK.

El componente NGINX Ingress incluye parámetros de ajuste predeterminados que ofrecen un rendimiento óptimo en la mayoría de los escenarios. Si tiene requisitos específicos, puede optimizar aún más los parámetros del sistema y de NGINX mediante los campos correspondientes del ConfigMap. Para obtener más información sobre los ConfigMaps, consulte ConfigMaps.

Escalado automático con HPA

En la mayoría de los casos, el controlador NGINX Ingress maneja picos repentinos de tráfico. Si la capacidad predeterminada resulta insuficiente para sus escenarios de alta carga, configure un Horizontal Pod Autoscaler (HPA) para escalar automáticamente el controlador NGINX Ingress. Para obtener más información, consulte Use Horizontal Pod Autoscaler (HPA).

A continuación se muestra un ejemplo de configuración YAML:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-ingress-controller-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Configuración de un hook preStop

Durante una actualización continua de un servicio del backend, el controlador NGINX Ingress elimina el endpoint de un pod en finalización y mantiene las conexiones de las solicitudes en curso. Si un pod del servicio del backend se cierra inmediatamente después de recibir la señal de terminación, las solicitudes en curso podrían fallar. Debido a problemas de sincronización, parte del tráfico nuevo podría seguir dirigiéndose al pod finalizado, lo que provoca pérdida de tráfico.

Para evitar la pérdida de tráfico durante las actualizaciones continuas, configure un hook preStop en los pods de su servicio del backend. Este hook permite que el pod siga procesando las solicitudes en curso después de eliminar su endpoint, lo que previene interrupciones del servicio.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        lifecycle:
          # Configure a preStop hook to wait for 30 seconds before exiting.
          # The sleep command must be available in the container.
          preStop:
            exec:
              command:
              - sleep
              - "30"

Log Service y Managed Service for Prometheus

Uso de varios controladores NGINX Ingress

Es posible que necesite desplegar varios controladores NGINX Ingress en un clúster, por ejemplo, para aislar el tráfico interno del externo. Para obtener más información, consulte Deploy multiple Ingress controllers for traffic isolation.

Acceso dentro del clúster

Dentro de un clúster, iptables o IPVS suelen interceptar y reenviar el tráfico dirigido al endpoint externo de un LoadBalancer Service (la dirección IP pública del controlador NGINX Ingress). Cuando externalTrafficPolicy se establece en Local y ningún pod de NGINX Ingress se ejecuta en un nodo, se producen problemas de conectividad de red. De forma predeterminada, el controlador NGINX Ingress en un clúster ACK usa un LoadBalancer Service en modo Local. En consecuencia, podría experimentar problemas de conectividad al acceder a la dirección del Classic Load Balancer (CLB) asociado desde dentro del clúster. Por lo tanto, para el acceso dentro del clúster, utilice el ClusterIP del Service o el nombre de dominio interno (nginx-ingress-lb.kube-system). Además, evite los escenarios donde el controlador NGINX Ingress intente acceder a sí mismo, ya que esto puede provocar fallas de red debido a problemas de hairpinning. Para obtener más información sobre cómo resolver este problema, consulte No se puede acceder a la instancia SLB de un LoadBalancer Service desde dentro de un clúster de Kubernetes.

Uso de WAF

Despliegues azul-verde o versiones canary

Puede implementar una versión canary con el controlador NGINX Ingress mediante la función disponible en la consola de ACK o si agrega manualmente una anotación. Para obtener más información, consulte Use NGINX Ingress to implement canary releases and blue-green deployments.

Proxy de solicitudes que no son HTTP