Esta página responde às perguntas mais comuns sobre Application Load Balancer (ALB) Ingresses no Container Service for Kubernetes (ACK) e no Container Compute Service (ACS).
Referência rápida: por que minha configuração não surte efeito?
Diversas causas raiz distintas podem gerar um sintoma semelhante: um ALB Ingress que parece saudável, mas cujas alterações não são aplicadas. Consulte esta tabela para identificar seu cenário.
|
Sintoma |
Causa mais provável |
Solução |
|
Regras em um Ingress recém-criado não são aplicadas |
Outro Ingress que compartilha a mesma instância ALB possui erro de configuração |
Localize e corrija o Ingress com erro |
|
Alterações não aplicadas, sem erros no Ingress |
O IngressClass aponta para o AlbConfig incorreto |
Verifique o campo |
|
Alterações feitas no console ALB são sobrescritas |
Mudanças no console não persistem no servidor de API |
Edite o AlbConfig ou o ALB Ingress diretamente via |
|
Alguns listeners desapareceram após |
O comando |
Restaure os listeners ausentes com |
Por que as regras do 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 ALB, todos gravam em um único conjunto de regras. Se qualquer Ingress contiver um erro de configuração, esse erro bloqueia todo o conjunto e impede que os demais Ingresses nessa instância entrem em vigor.
Quando múltiplos ALB Ingresses compartilham a mesma instância ALB, um único Ingress mal configurado impede a aplicação das regras de todos os outros Ingresses nessa instância. Verifique cada Ingress associado à instância, não apenas o criado mais recentemente.
Se o seu Ingress recém-criado não funcionar, verifique se um Ingress anterior na mesma instância ALB possui erro de configuração. Corrija esse erro primeiro para que o novo Ingress entre em vigor.
Para localizar o erro, execute:
kubectl describe ingress <ingress-name> -n <namespace>Procure eventos com status Error ou Warning. Para verificar se o controlador do ALB Ingress relata erros, execute:
kubectl logs -n kube-system -l app=alb-ingress-controller --tail=50Quais são as diferenças entre ALB Ingresses e NGINX Ingresses?
O ALB Ingress é um serviço em nuvem totalmente gerenciado, sem necessidade de manutenção de infraestrutura. Já o NGINX Ingress exige que você gerencie a implantação do controlador e seus recursos subjacentes.
Os ALB Ingresses escutam requisições enviadas ao grupo de servidores kube-system-fake-svc-80 por padrão. Qual a finalidade desse grupo de servidores?
Todo listener requer uma regra de encaminhamento padrão, e cada regra deve associar-se a exatamente um grupo de servidores. O grupo de servidores kube-system-fake-svc-80 funciona como espaço reservado para essa regra de encaminhamento padrão. Ele não processa requisições e não pode ser excluído.
É possível ativar o acesso interno e externo simultaneamente?
Sim. Crie uma instância ALB voltada para a Internet. A instância cria automaticamente um endereço IP elástico (EIP) em cada zona para acesso à Internet e também recebe um endereço IP virtual privado (VIP) para acesso pela rede interna.
Para acesso exclusivamente interno, crie uma instância ALB voltada para a rede interna.
Por que não consigo visualizar o pod do controlador do ALB Ingress no meu cluster?
O pod do controlador do ALB Ingress aparece no namespace kube-system apenas em clusters dedicados do ACK. Em clusters ACK Basic, ACK Pro e Alibaba Cloud Container Compute Service (ACS), o controlador do ALB Ingress opera como componente totalmente gerenciado e não fica visível no cluster.
Como manter o nome de domínio do ALB estável?
O nome de domínio do ALB vincula-se à instância ALB, referenciada pelo ALB Ingress por meio da cadeia IngressClass -> AlbConfig. Desde que você não modifique o IngressClass ou o AlbConfig, o nome de domínio permanece inalterado após a criação da instância.
Uma instância ALB é criada automaticamente ao provisionar um cluster gerenciado ACK com ALB Ingress ativado?
Não. Selecionar ALB Ingress durante a criação do cluster instala automaticamente o controlador do ALB Ingress, mas não cria uma instância ALB. Crie a instância ALB separadamente após o cluster estar pronto.
Por que minhas alterações no console ALB são sobrescritas?
O controlador do ALB Ingress considera os recursos ALB Ingress e AlbConfig no servidor de API do cluster como fonte da verdade. Alterações feitas diretamente no console ALB não persistem no servidor de API. Qualquer chamada interna ou operação no cluster faz o controlador sobrescrever as configurações do console ALB com aquelas armazenadas no servidor de API.
Para tornar as alterações persistentes, edite o recurso AlbConfig ou ALB Ingress diretamente:
kubectl -n <namespace> edit AlbConfig <albconfig-name>Como agir quando um HTTP 503 é retornado logo após excluir uma regra de encaminhamento?
Verifique se algum dos Ingresses envolvidos na regra de encaminhamento possui a anotação canary:true. A anotação canary:true pertence exclusivamente ao Ingress da versão canário, não ao Ingress do Service original. Aplicá-la no Ingress errado faz o controlador remover a regra de encaminhamento do Service original, resultando em erros 503.
Implantações canário suportam apenas dois Ingresses e um número limitado de condições de encaminhamento. Para roteamento de tráfego mais flexível, utilize regras de encaminhamento personalizadas. Para configurar implantações canário, veja Usar ALB Ingresses para realizar implantações canário.
O que fazer quando o ALB Ingress não apresenta erros, mas as alterações não surtem efeito?
Se os eventos de reconciliação de um AlbConfig não forem processados, a causa mais comum é o IngressClass referenciar o AlbConfig errado. Verifique o campo parameters no IngressClass:
kubectl get ingressclass <ingressclass-name> -o yamlConfirme se o campo parameters aponta para o AlbConfig correto. Para a configuração adequada, consulte Usar um AlbConfig para configurar uma instância ALB.
Por que alguns listeners são excluídos após executar kubectl apply para atualizar meu AlbConfig?
O comando kubectl apply atualiza um AlbConfig substituindo toda a sua especificação. Se o YAML aplicado não incluir todas as configurações de listeners existentes, esses listeners serão excluídos.
Sempre execute kubectl diff antes de kubectl apply para visualizar exatamente o que será alterado. Utilize kubectl edit para mudanças pontuais e evitar o risco de omitir listeners existentes.
kubectl diff -f <your-albconfig.yaml>Para restaurar listeners excluídos, adicione novamente as configurações ausentes usando kubectl edit:
kubectl -n <namespace> edit AlbConfig <albconfig-name>Como reduzir o tempo de reconciliação de servidores durante o dimensionamento de pods?
O tempo de reconciliação aumenta conforme a quantidade de Ingresses associados a cada Service. Duas abordagens ajudam a mitigar isso:
Limite de Ingresses por Service: Mantenha no máximo 30 Ingresses associados a um único Service.
Consolidação de regras de Ingress: Associe múltiplos Services ao mesmo Ingress e defina as regras de roteamento nele, em vez de criar um Ingress separado para cada Service.
Como ativar a atribuição automática de peso de nós com o plugin Flannel e modo Local?
Este recurso exige a versão 2.13.1-aliyun.1 ou superior do controlador do ALB Ingress. Atualize o controlador antes de ativar essa funcionalidade.
Quando o plugin de rede Flannel está instalado e o modo Local está ativado para um Service, o controlador do ALB Ingress calcula automaticamente os pesos dos nós com base na distribuição dos pods:
|
Pods por Service |
Cálculo de peso |
|
Até 100 pods |
Peso = número de pods em cada nó. Por exemplo, nós com 1, 2 e 3 pods recebem pesos de 1, 2 e 3, distribuindo o tráfego na proporção de 1:2:3. |
|
Mais de 100 pods |
Peso = porcentagem de pods em cada nó (arredondada). Por exemplo, nós com 100, 200 e 300 pods de um total de 600 recebem pesos de 16, 33 e 50. |
O tráfego é distribuído proporcionalmente à quantidade de pods, garantindo carga equilibrada para todos, independentemente do nó em que estejam executando.