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 adequadas e limites de recursos

Por padrão, um NGINX Ingress controller instalado durante a criação do cluster ou pela página Add-ons possui duas réplicas. Ajuste esse número conforme as necessidades do seu negócio. Garanta que os pods do NGINX Ingress controller estejam distribuídos em nós diferentes para evitar contenção de recursos e pontos únicos de falha. Também é possível atribuir nós exclusivos para assegurar desempenho e estabilidade. Para mais informações, consulte Use exclusive nodes to improve NGINX Ingress performance and stability. Para evitar interrupções de tráfego causadas por eventos de falta de memória (OOM), não defina limites de recursos para o NGINX Ingress controller. Caso seja obrigatório definir limites, configure o limite de CPU para pelo menos 1.000 millicores e o limite de memória para no mínimo 2 GiB.

Uso de nós exclusivos

• Para requisitos de alta estabilidade, atribua nós exclusivos ao Ingress controller e evite contenção de recursos. Para mais informações, consulte Deploy a highly available NGINX Ingress controller.

• Em cenários de alta carga, configure o Ingress controller para oferecer suporte a aplicações com tráfego intenso. Para mais informações, consulte Configure the NGINX Ingress controller for high-load scenarios.

Otimização do desempenho do NGINX Ingress

O ajuste de desempenho do NGINX Ingress controller envolve duas áreas principais: parâmetros de sistema e parâmetros do NGINX.

• Parâmetros de sistema: os sistemas operacionais da Alibaba Cloud já incluem otimizações padrão para parâmetros comuns. Outros parâmetros que podem exigir ajuste incluem o backlog máximo do sistema e o intervalo de portas disponíveis. Ajustar esses parâmetros ajuda a garantir que o NGINX lide com alta concorrência e evita falhas de conexão com backends devido à exaustão de portas.

• Parâmetros do NGINX:

  • Ajuste o número máximo de conexões por processo worker para garantir que o NGINX Ingress controller suporte alta concorrência.

  • Aumente o tempo limite de conexão: diferentemente do comportamento padrão do NGINX, o NGINX Ingress controller utiliza conexões keep-alive para enviar requisições aos pods de backend. Portanto, aumente o tempo limite de conexão para permitir que uma única conexão processe mais requisições e reduza a sobrecarga de criação de novas conexões.

  • Defina o tempo limite de keep-alive: configure o tempo limite de keep-alive dos serviços de backend como igual ou superior ao tempo limite de conexão do NGINX Ingress controller, cujo valor padrão é 900s em clusters ACK.

O componente NGINX Ingress inclui parâmetros de ajuste padrão que oferecem desempenho ideal na maioria dos cenários. Se você tiver requisitos específicos, otimize ainda mais os parâmetros de sistema e do NGINX usando os campos relevantes no ConfigMap. Para mais informações sobre ConfigMaps, consulte ConfigMaps.

Dimensionamento automático com HPA

Na maioria dos casos, o NGINX Ingress controller consegue lidar com picos repentinos de tráfego. Se a capacidade padrão for insuficiente para seus cenários de alta carga, configure um Horizontal Pod Autoscaler (HPA) para dimensionar automaticamente o NGINX Ingress controller. Para mais informações, consulte Use Horizontal Pod Autoscaler (HPA).

A seguir, um exemplo de configuração 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

Configuração de hook preStop

Durante uma atualização contínua de um service de backend, o NGINX Ingress controller remove o endpoint de um pod em encerramento, mantendo as conexões das requisições em andamento. Se um pod do service de backend sair imediatamente após receber o sinal de encerramento, as requisições em andamento podem falhar. Devido a questões de sincronismo, parte do novo tráfego ainda pode ser roteada para o pod encerrado, resultando em perda de tráfego.

Para evitar perda de tráfego durante atualizações contínuas, configure um hook preStop nos pods do service de backend. Esse hook permite que o pod continue processando requisições em andamento mesmo após a remoção do endpoint, prevenindo interrupções no service.

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 e Managed Service for Prometheus

Uso de múltiplos NGINX Ingress controllers

Pode ser necessário implantar vários NGINX Ingress controllers em um cluster, por exemplo, para isolar tráfego interno e externo. Para mais informações, consulte Deploy multiple Ingress controllers for traffic isolation.

Acesso intracluster

Em um cluster, o tráfego destinado ao endpoint externo de um LoadBalancer Service (o endereço IP público do NGINX Ingress controller) é normalmente interceptado e encaminhado por iptables ou IPVS. Quando externalTrafficPolicy está definido como Local e nenhum pod do NGINX Ingress está em execução em um nó, ocorrem problemas de conectividade de rede. Por padrão, o NGINX Ingress controller em um cluster ACK usa um LoadBalancer Service no modo Local. Consequentemente, você pode enfrentar problemas de conectividade ao acessar o endereço do Classic Load Balancer (CLB) associado de dentro do cluster. Portanto, para acesso intracluster, utilize o ClusterIP do Service ou o nome de domínio interno (nginx-ingress-lb.kube-system). Além disso, evite cenários em que o NGINX Ingress controller tenta acessar a si mesmo, pois isso pode levar a falhas de rede devido a problemas de hairpinning. Para mais informações sobre como resolver esse problema, consulte Cannot access the SLB instance of a LoadBalancer Service from within a Kubernetes cluster.

Uso do WAF

Implantações blue-green ou canary releases

Implemente um canary release com o NGINX Ingress controller usando o recurso disponível no ACK console ou adicionando manualmente uma annotation. Para mais informações, consulte Use NGINX Ingress to implement canary releases and blue-green deployments.

Proxy de requisições não HTTP