Container Service for Kubernetes:ALB Ingress FAQ

Por que as regras de ALB Ingress não entram em vigor?

Os ALB Ingresses mantêm as regras de roteamento em modo inline. Quando vários Ingresses compartilham a mesma instância de ALB, um erro de configuração em qualquer um deles impede o funcionamento de todos os outros Ingresses dessa instância.

Para corrigir esse problema, localize o Ingress com erro — geralmente aquele criado antes dos Ingresses afetados — e ajuste sua configuração. Os demais Ingresses voltarão a funcionar assim que você resolver o erro.

Qual é a diferença entre ALB Ingresses e NGINX Ingresses?

Os ALB Ingresses baseiam-se no ALB, um serviço de nuvem totalmente gerenciado que não exige manutenção manual. Já os NGINX Ingresses exigem que você gerencie o controlador por conta própria.

Para obter uma comparação detalhada, consulte Comparação entre NGINX Ingresses, ALB Ingresses e MSE Ingresses.

O que é o grupo de servidores kube-system-fake-svc-80?

O ALB exige uma regra de encaminhamento padrão antes da criação de um listener, e cada regra deve associar-se a exatamente um grupo de servidores. O grupo de servidores kube-system-fake-svc-80 atende a esse requisito como um espaço reservado utilizado pela regra de encaminhamento padrão. Ele não processa nenhuma solicitação e não pode ser excluído.

É possível ativar o acesso interno e externo simultaneamente para um ALB Ingress?

Sim. Crie uma instância de ALB voltada para a Internet. A instância provisiona automaticamente um endereço IP elástico (EIP) em cada zona para tráfego de internet e também recebe um endereço IP virtual privado (VIP) para acesso à rede interna. Assim, ambos os modos de acesso funcionam simultaneamente.

Caso precise apenas de acesso interno, crie uma instância de ALB voltada para a rede interna.

Por que não consigo visualizar o pod do controlador de ALB Ingress no meu cluster?

O pod do controlador de ALB Ingress aparece no namespace kube-system apenas em clusters dedicados do ACK. Em clusters ACK Basic, ACK Pro e ACK Serverless, o controlador opera como um componente totalmente gerenciado e não fica exposto como um pod no seu cluster.

Se desejar migrar de um cluster dedicado do ACK, consulte Migração a quente de clusters dedicados do ACK para clusters ACK Pro.

Como evitar que o nome de domínio do ALB seja alterado?

O nome de domínio permanece estável desde que você não modifique o IngressClass ou o objeto AlbConfig referenciado. Ao utilizar um objeto AlbConfig para criar uma instância de ALB, o Ingress faz referência a essa instância por meio de um IngressClass. Portanto, o nome de domínio vincula-se à instância de ALB, e não ao próprio Ingress.

Uma instância de ALB é criada automaticamente ao ativar o ALB Ingress durante a criação do cluster?

Não. Selecionar o ALB Ingress durante a criação de um cluster gerenciado do ACK instala apenas o controlador de ALB Ingress. Você deve criar a instância de ALB separadamente.

Por que minhas alterações no console de ALB estão sendo sobrescritas?

O objeto ALB Ingress ou AlbConfig no servidor de API do cluster gerencia a configuração do ALB Ingress. Alterações feitas diretamente no console de ALB não são sincronizadas de volta para o servidor de API. Assim, qualquer chamada interna ou operação do cluster sobrescreve as mudanças do console com a configuração armazenada no cluster.

O que fazer se eu receber um erro HTTP 503 após excluir uma regra de encaminhamento recém-criada?

Verifique se o ALB Ingress associado à regra de encaminhamento possui a anotação canary:true. Em implantações canário, o tráfego é redirecionado da versão antiga do Service para a versão canário. Adicione canary:true somente ao Ingress canário, e não ao Ingress do Service antigo.

As implantações canário suportam apenas dois Ingresses e um número limitado de condições de encaminhamento. Para um roteamento de tráfego mais flexível, utilize regras de encaminhamento personalizadas. Consulte Usar ALB Ingresses para realizar implantações canário e Configurar regras de encaminhamento personalizadas para ALB Ingresses.

Por que as alterações no meu ALB Ingress não têm efeito mesmo sem erros aparentes?

O IngressClass pode estar apontando para o objeto AlbConfig incorreto. Verifique se o campo parameters no seu IngressClass está configurado corretamente. Consulte Usar um IngressClass para associar um objeto AlbConfig a um Ingress.

Por que alguns listeners foram excluídos após executar kubectl apply para atualizar o AlbConfig?

O comando kubectl apply sobrescreve todo o recurso AlbConfig. Se o seu arquivo YAML omitir algum listener configurado anteriormente, esses listeners serão excluídos.

Sempre que possível, utilize kubectl edit. Esse comando abre o recurso atual completo para edição e evita omissões acidentais:

kubectl -n <namespace> edit AlbConfig <albconfig-name>

Caso os listeners já tenham sido excluídos, adicione-os novamente usando o mesmo comando kubectl edit mencionado acima.

Como reduzir o tempo de reconciliação durante o dimensionamento de pods?

O tempo de reconciliação aumenta conforme a quantidade de Ingresses associados a um Service. Adote uma das seguintes abordagens:

• Limite os Ingresses por Service: Mantenha no máximo 30 Ingresses associados a um único Service.

• Consolide as regras de Ingress: Associe múltiplos Services ao mesmo Ingress e defina regras de roteamento distintas dentro dele, em vez de criar um Ingress separado para cada Service.