Nginx Ingress controller

Introdução

O Kubernetes usa o kube-proxy para expor Serviços e fornecer balanceamento de carga. A implementação está na camada de transporte. Quando se trata de aplicações da Internet, onde um bucket de informações é gerado, o encaminhamento precisa ser mais refinado, controlado de forma precisa e flexível por políticas e balanceadores de carga para oferecer maior desempenho.

É aqui que entram os ingresses. Ingresses fornecem funções de encaminhamento da camada de aplicação, como hosts virtuais, balanceamento de carga, proxy SSL e roteamento HTTP, para Serviços que podem ser acessados diretamente fora de um cluster.

O Kubernetes lançou oficialmente o controlador de ingress baseado em Nginx. O Nginx Ingress controller do CCE usa diretamente modelos e imagens da comunidade. O Nginx Ingress controller gera a configuração do Nginx e armazena a configuração usando ConfigMap. A configuração será gravada nos pods do Nginx por meio da API do Kubernetes. Desta forma, a configuração do Nginx é modificada e atualizada. Para mais detalhes, consulte Como funciona o nginx-ingress.

Você pode visitar a comunidade de código aberto para obter mais informações.

• Ao instalar o complemento, você pode adicionar configurações definindo a configuração do Nginx. As configurações entram em vigor globalmente. Esse parâmetro é gerado pela configuração do arquivo nginx.conf e afeta todos os ingresses gerenciados. Você pode pesquisar parâmetros relacionados no ConfigMap. Se os parâmetros configurados não estiverem incluídos nas opções listadas no ConfigMap, as configurações não terão efeito.
• Depois que o complemento for instalado, você poderá se interconectar com o Nginx e adicionar annotations do Kubernetes a um ingress específico para personalizar seu comportamento ao criar um ingress no console do CCE. Para obter detalhes sobre o campo annotations do Kubernetes, consulte Anotações.
• Não modifique ou exclua manualmente o balanceador de carga e o ouvinte que são criados automaticamente pelo CCE. Caso contrário, a carga de trabalho será anormal. Se você modificou ou excluiu-os por engano, desinstale o complemento nginx-ingress e reinstale-o.

Como funciona o nginx-ingress

nginx-ingress consiste no objeto de ingress, no controlador de ingress e no Nginx. O controlador de ingress monta os ingresses no arquivo de configuração do Nginx (nginx.conf) e recarrega o Nginx para que as configurações alteradas tenham efeito. Quando ele detecta que o pod em um Serviço muda, ele altera dinamicamente a configuração do grupo de servidores upstream do Nginx. Nesse caso, o processo de Nginx não precisa ser recarregado. Figura 1 mostra como funciona o nginx-ingress.

• Um ingress é um grupo de regras de acesso que encaminha solicitações para Serviços especificados com base em nomes de domínio ou URLs. Ingresses são armazenados no serviço de armazenamento de objetos etcd e são adicionados, excluídos, modificados e consultados por meio de APIs.
• O controlador de ingress monitora as alterações de objetos de recursos, como ingresses, Serviços, pontos de extremidade, segredos (principalmente certificados e chaves TLS), nós e ConfigMaps em tempo real e executa operações automaticamente no Nginx.
• O Nginx implementa balanceamento de carga e controle de acesso na camada de aplicação.

Figura 1 Princípios de funcionamento do nginx-ingress

Restrições

• Esse complemento pode ser instalado somente em clusters v1.15 ou posterior.
• kubernetes.io/ingress.class: "nginx" deve ser adicionado à anotação do Ingress criado por meio da API.
• Os balanceadores de carga dedicados devem ser do tipo de rede (TCP/UDP) que suportam redes privadas (com um IP privado).
• O nó onde o nginx-ingress-controller está em execução e os contêineres em execução no nó não podem acessar o Nginx Ingress. Nesse caso, execute a implementação de antiafinidade para as cargas de trabalho e o nginx-ingress-controller. Para mais detalhes, consulte Implementação de antiafinidade para cargas de trabalho e nginx-ingress-controller.

Pré-requisitos

Antes de criar uma carga de trabalho, você deve ter um cluster disponível. Se nenhum cluster estiver disponível, crie um de acordo com Compra de um cluster do CCE.

Instalar o complemento

• A vulnerabilidade CVE-2021-25746 foi corrigida no nginx-ingress-controller da v1.2.0 (correspondente ao complemento do CCE nginx-ingress 2.1.0). Regras são adicionadas para desabilitar algumas anotações propensas a acesso não autorizado.
• A vulnerabilidade CVE-2021-25745 foi corrigida no nginx-ingress-controller da v1.2.0 (correspondente ao complemento do CCE nginx-ingress 2.1.0). Regras são adicionadas para desabilitar alguns caminhos de acesso propensos a acesso não autorizado.

1. Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster. Escolha Add-ons no painel de navegação, localize NGINX Ingress Controller na direita e clique em Install.
2. Na página Install Add-on, configure as especificações.

   Tabela 1 Configuração de nginx-ingress

   Parâmetro	Descrição
   Add-on Specifications	As especificações podem ser Custom.
   Instances	Se você selecionar Custom, poderá ajustar o número de pods conforme necessário.
   Containers	Se você selecionar Custom, poderá ajustar as especificações do contêiner conforme necessário.

3. Configure os parâmetros do complemento.
   • Load Balancer: selecione um balanceador de carga compartilhado ou dedicado. Se nenhum balanceador de carga estiver disponível, crie um. O balanceador de carga tem pelo menos dois ouvintes, e as portas 80 e 443 não são ocupadas por ouvintes.
   • Nginx Parameters: a configuração do arquivo nginx.conf afetará todos os ingresses gerenciados. Você pode pesquisar parâmetros relacionados através do ConfigMaps. Se os parâmetros configurados não estiverem incluídos nas opções listadas nesses ConfigMaps, os parâmetros não terão efeito.

     Por exemplo, você pode usar o parâmetro keep-alive-requests para descrever como definir o número máximo de solicitações para manter conexões ativas como 100.

     {
         "keep-alive-requests": "100"
     }

   • Default 404 Service: por padrão, o serviço 404 fornecido pelo complemento é usado. Para personalizar o serviço 404, insira o namespace/nome do serviço. Se o serviço não existir, a instalação do complemento falhará.

4. Configure as políticas de agendamento para o complemento.
   

   • As políticas de agendamento não entram em vigor em instâncias complementares do tipo DaemonSet.
   • Ao configurar a implementação de várias AZs ou a afinidade de nó, verifique se há nós que atendem à política de agendamento e se os recursos são suficientes no cluster. Caso contrário, o complemento não pode ser executado.

   Tabela 2 Configurações para programação de complementos

   Parâmetro	Descrição
   Multi-AZ Deployment	Preferred: os pods de Implementação do complemento serão agendados preferencialmente para nós em diferentes AZs. Se todos os nós no cluster forem implementados na mesma AZ, os pods serão agendados para essa AZ. Forcible: os pods de Implementação do complemento serão forçosamente agendados para nós em diferentes AZs. Se houver menos AZs do que pods, os pods extras não funcionarão.
   Node Affinity	Incompatibility: a afinidade de nó está desabilitada para o complemento. Node Affinity: especifique os nós em que o complemento é implementado. Se você não especificar os nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Specified Node Pool Scheduling: especifique o pool de nós em que o complemento é implementado. Se você não especificar o pool de nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Custom Policies: insira os rótulos dos nós em que o complemento será implementado para políticas de agendamento mais flexíveis. Se você não especificar rótulos de nó, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Se várias políticas de afinidade personalizadas estiverem configuradas, certifique-se de que existem nós que atendam a todas as políticas de afinidade no cluster. Caso contrário, o complemento não pode ser executado.
   Taints and Tolerations	O uso de manchas e tolerâncias permite (não forçosamente) que Implementação do complemento seja agendada para um nó com as manchas correspondentes e controla as políticas de despejo de Implementação depois que o nó onde a Implementação está localizada é contaminado. O complemento adiciona a política de tolerância padrão para as manchas node.kubernetes.io/not-ready e node.kubernetes.io/unreachable, respectivamente. A janela de tempo de tolerância é 60s. Para mais detalhes, consulte Manchas e tolerâncias.

5. Clique em Install.

Componentes

Implementação de antiafinidade para cargas de trabalho e nginx-ingress-controller

O nó onde o nginx-ingress-controller está em execução e os contêineres em execução no nó não podem acessar o Nginx Ingress. Para evitar esse problema, configure uma regra de antiafinidade para informar ao agendador para não co-localizar a carga de trabalho e o nginx-ingress-controller no mesmo nó.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:aplpine
        imagePullPolicy: IfNotPresent
        name: nginx
      imagePullSecrets:
      - name: default-secret
				      
				
					affinity:
				
				
					        podAntiAffinity:
				
				
					          requiredDuringSchedulingIgnoredDuringExecution:
				
				
					            - labelSelector:
				
				
					                matchExpressions:
				    # Use the labels of nginx-ingress-controller to implement anti-affinity.
				
					                  - key: app
				
				
					                    operator: In
				
				
					                    values:
				
				
					                      - nginx-ingress
				
				
					                  - key: component
				
				
					                    operator: In
				
				
					                    values:
				
				
					                      - controller
				
				
					              namespaces:
				
				
					                - kube-system
				
				
					              topologyKey: kubernetes.io/hostname