Container Service for Kubernetes:ALB ingress FAQ

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

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

Para corrigir isso, encontre o Ingress com o erro — geralmente um criado antes dos Ingresses afetados — e corrija sua configuração. Os outros Ingresses voltarão a funcionar assim que o erro for resolvido.

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

Os ALB Ingresses são baseados no ALB, um service de cloud totalmente gerenciado que não exige manutenção manual. Já os NGINX Ingresses exigem que você mesmo gerencie o controlador.

Para obter uma comparação detalhada, consulte Comparison among NGINX Ingresses, ALB Ingresses, and MSE Ingresses.

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

O ALB exige uma regra de encaminhamento padrão antes que um listener possa ser criado, e cada regra de encaminhamento deve estar associada a exatamente um grupo de servidores. O grupo de servidores kube-system-fake-svc-80 atende a esse requisito: ele é um espaço reservado usado pela regra de encaminhamento padrão. Ele não processa nenhuma requisição e não é possível excluí-lo.

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

Sim. Crie uma instância do ALB voltada para a Internet. A instância provisiona automaticamente um endereço IP elástico (EIP) em cada zona para o 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.

Se você precisar apenas de acesso interno, crie uma instância do 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 fica visível no namespace kube-system apenas em clusters dedicados do ACK. Nos clusters ACK Basic, ACK Pro e ACK Serverless, o controlador de ALB Ingress é executado como um componente totalmente gerenciado e não é exposto como um pod no seu cluster.

Se você quiser migrar de um cluster dedicado do ACK, consulte Hot migration from ACK dedicated clusters to ACK Pro clusters.

Como impedir 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 por ele. Ao usar um objeto AlbConfig para criar uma instância do ALB, o Ingress referencia essa instância por meio de um IngressClass. O nome de domínio está vinculado à instância do ALB, e não ao próprio Ingress.

Uma instância do ALB é criada automaticamente quando ativo o ALB Ingress durante a criação do cluster?

Não. Selecione o ALB Ingress durante a criação de um cluster gerenciado do ACK para instalar apenas o controlador do ALB Ingress. Não ative o ALB Ingress esperando que a instância seja provisionada sozinha. Você deve criar a instância do ALB separadamente.

O ALB Ingress oferece suporte à seleção de Services entre namespaces?

Não. O ALB Ingress não oferece suporte à seleção de Services entre namespaces. Um recurso de Ingress só pode referenciar Services no mesmo namespace. Se o Service referenciado residir em um namespace diferente, o Ingress não conseguirá associar corretamente o service de backend.

O limitador de taxa de QPS do ALB Ingress tem cobrança separada? Qual é o seu escopo? Como configure limites de taxa diferentes para caminhos diferentes?

Faturamento: O limitador de taxa de QPS não tem cobrança separada. No entanto, a instância do ALB é cobrada com base no uso. Consulte ALB billing.

Escopo aplicável: A anotação alb.ingress.kubernetes.io/traffic-limit-qps se aplica no nível do Ingress. Quando você configure essa anotação, o controlador aplica a mesma configuração de limitação de taxa a cada regra de encaminhamento do ALB gerada para o Ingress. Para um único caminho, não defina essa configuração de forma independente, nem a cota de QPS é compartilhada entre vários caminhos.

Configurações de limitação de taxa diferentes: Se caminhos diferentes exigirem valores de limitação de taxa diferentes, divida a configuração em vários Ingresses e configure uma anotação de limitação de taxa específica para cada um. Você não precisa criar várias instâncias do ALB, pois uma única instância do ALB pode ser associada a vários Ingresses. Para cenários avançados, configure TrafficLimit usando uma ação de regra de encaminhamento personalizada. No entanto, não use este método com a anotação global traffic-limit-qps.

O ALB Ingress oferece suporte a vários nomes de domínio?

Sim. Um único listener do ALB pode vincular diferentes nomes de domínio por meio da configuração de várias regras de encaminhamento.

Para configurar vários nomes de domínio, defina várias entradas host em spec.rules no recurso de Ingress. Cada entrada host especifica um nome de domínio, e você pode associar diferentes Services de backend a diferentes nomes de domínio dentro do mesmo Ingress.

Por que as minhas alterações no console do ALB estão sendo substituídas?

A configuração do ALB Ingress é gerenciada por meio do ALB Ingress ou do objeto AlbConfig no servidor de API do cluster. As alterações feitas diretamente no console do ALB não são sincronizadas de volta para o servidor de API. Portanto, qualquer chamada interna ou operação do cluster substituirá as alterações do console pela configuração armazenada no cluster.

O que fazer se eu receber um erro HTTP 503 caso eu exclua uma regra de encaminhamento que acabei de criar?

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

As versões canary oferecem suporte a apenas dois Ingresses e a um número limitado de condições de encaminhamento. Para um roteamento de tráfego mais flexível, use regras de encaminhamento personalizadas. Consulte Use ALB Ingresses to perform canary releases e Configure custom forwarding rules for ALB Ingresses.

Por que as minhas alterações no ALB Ingress não entram em vigor mesmo sem erros?

O IngressClass pode estar apontando para o objeto AlbConfig incorreto. Verifique se o campo parameters no seu IngressClass está configurado corretamente. Consulte Use an IngressClass to associate an AlbConfig object with an Ingress.

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

O comando kubectl apply substitui todo o recurso AlbConfig. Se o seu arquivo YAML omitir qualquer listener configurado anteriormente, esses listeners serão removidos. Para evitar que o comando exclua listeners indevidamente, verifique o arquivo.

Sempre que possível, execute o kubectl edit e edite o recurso inteiro. Ele abre o recurso atual completo para edição e evita omissões acidentais:

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

Se os listeners já foram excluídos, adicione-os de volta usando o mesmo comando kubectl edit acima.

Por que o endpoint externo (Endpoint) de um ALB Ingress está vazio ou o endereço não pode ser obtido, e como resolvo isso?

Se o endpoint externo de um ALB Ingress estiver vazio ou o endereço não puder ser obtido, verifique as causas comuns a seguir e tome as medidas correspondentes:

1. IngressClass não especificado: Certifique-se de que o recurso de Ingress especifique o ingressClassName correto (por exemplo, alb). Se o ingressClassName não estiver definido ou o valor não corresponder ao IngressClass gerenciado pelo ALB Ingress Controller, o controlador não processará o Ingress e o endpoint permanecerá vazio.

2. Associação incorreta do AlbConfig: Verifique se o IngressClass está associado ao nome correto do AlbConfig e verifique se o status do AlbConfig está normal. Uma associação incorreta ou um AlbConfig em estado anormal impede o provisionamento do ALB. Para obter mais informações, consulte Use an IngressClass to associate an AlbConfig with an ingress.

3. IPs insuficientes no vSwitch: Verifique o número de endereços IP disponíveis nos vSwitches associados ao AlbConfig. Para garantir que os recursos elásticos do ALB sejam totalmente suportados, reserve pelo menos 8 endereços IP em cada vSwitch onde a instância do ALB está implantada. Se os IPs disponíveis forem insuficientes, substitua o vSwitch ou expanda o intervalo CIDR do vSwitch.

4. Zonas de disponibilidade insuficientes: O ALB exige alta disponibilidade e precisa de vSwitches em pelo menos duas zonas de disponibilidade diferentes. Se apenas uma zona de disponibilidade estiver configurada, adicione vSwitches em pelo menos uma outra zona de disponibilidade.

5. Opção de instalação do componente: Se a opção None foi selecionada durante a instalação do componente, nenhuma instância do ALB ou AlbConfig foi criada automaticamente. Nesse caso, instale o componente manualmente através de manually create AlbConfig and IngressClass e associate an AlbConfig with an Ingress using IngressClass.

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

O tempo de reconciliação aumenta conforme o número de Ingresses associados a um Service. Use uma das seguintes abordagens:

• Limite de Ingresses por Service: Mantenha no máximo 30 Ingresses associados a qualquer Service individual.

• Consolide as regras de Ingress: Associe vários Services ao mesmo Ingress e defina regras de roteamento separadas dentro dele. Não crie um Ingress para cada Service.