Container Service for Kubernetes:Service FAQ

Quais instâncias de CLB um cluster ACK cria por padrão?

Se o add-on Nginx Ingress Controller for instalado durante a criação do cluster, duas instâncias de CLB serão criadas:

• CLB do API server: Endpoint do API server. Todas as requisições do cluster passam por esta instância na porta TCP 6443. Os backends são pods do API server ou instâncias ECS master.

• CLB do Nginx Ingress Controller: Associado ao Service nginx-ingress-controller no namespace kube-system. Associa-se dinamicamente aos pods do Ingress Controller para balancear requisições externas. Escuta nas portas TCP 80 e 443.

Como escolher entre as políticas de tráfego externo Local e Cluster?

As políticas de tráfego externo Local e Cluster diferem conforme o plugin de rede. Consulte External traffic policies: Local and Cluster.

Por que minha configuração de CLB foi modificada?

O CCM utiliza uma API declarativa e atualiza automaticamente a configuração do CLB com base na definição do Service. Alterações feitas diretamente no console de CLB podem ser substituídas.

Como os pesos dos nós são calculados no modo Local?

O exemplo a seguir considera um pod de aplicação (app=nginx) implantado em três instâncias ECS e exposto por meio de um Service.

Como habilitar connection draining para um Service do tipo LoadBalancer?

Adicione as seguintes annotations ao Service. Após a remoção de um servidor backend, a instância de CLB continua processando as conexões existentes durante a duração do tempo limite de drenagem.

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout

Consulte Enable connection draining for a listener.

Como listar todas as instâncias de CLB em um cluster?

1. Connect to the cluster using kubectl.

2. Obtenha o nome, namespace, endereço IP e tipo de endereço de cada Service do tipo LoadBalancer. Exemplo de saída:

      kubectl get services -A -ojson | jq '.items[] | select(.spec.type == "LoadBalancer") | {name: .metadata.name, namespace: .metadata.namespace, ip: .status.loadBalancer.ingress[0].ip, lb_type: .metadata.annotations."service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type"}'

      {
        "name": "test",
        "namespace": "default",
        "ip": "192.168.*.*",
        "lb_type": "intranet"
      }
      {
        "name": "nginx-ingress-lb",
        "namespace": "kube-system",
        "ip": "47.97.*.*",
        "lb_type": "null"
      }

Como habilitar a renomeação de CLB para versões antigas do CCM?

O CCM v1.9.3.10 e posteriores adicionam tags automaticamente às instâncias de CLB para permitir a renomeação. Para instâncias de CLB criadas por versões anteriores do CCM, adicione a tag manualmente.

Este procedimento aplica-se apenas a instâncias de CLB criadas pelo CCM v1.9.3.10 ou anterior. O tipo de Service deve ser LoadBalancer.

1. Conecte-se ao nó master do cluster. Consulte Connect to an ACK cluster using kubectl.

2. Visualize o tipo de Service e o endereço IP. Substitua ${namespace} e ${service} pelo namespace e nome do Service reais.

      kubectl get svc -n ${namespace} ${service}

   # kubectl get svc -n ${namespace} ${service}
   nginx-local   LoadBalancer   172.19.xxx.xxx   47.111.xxx.xxx   8900:31598/TCP   33d

3. Gere a tag para a instância de CLB:

      kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'

   # kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "ku
   kubernetes.do.not.delete: xxx

4. Faça login no console de CLB. Use o endereço IP da etapa 2 para pesquisar a instância de CLB na região correspondente.

5. Adicione uma tag à instância de CLB usando a chave e o valor da etapa 3 (itens 1 e 2 na figura anterior). Consulte Create and manage a CLB instance.

Por que um endereço IP de CLB está inacessível de dentro do cluster?

Dois cenários podem causar isso.

Cenário 1: CLB privado não criado por um Service

Quando um pod acessa uma instância de CLB privada não criada por um Service, o acesso falha se o pod e um servidor backend estiverem no mesmo nó. Trata-se de uma limitação da camada 4: uma instância ECS não pode ser simultaneamente servidor backend e cliente da mesma instância de CLB.

Para resolver:

• Altere o endereço IP do CLB para um endereço IP público.

• Crie a instância de CLB por meio de um Service e defina a política de tráfego externo como Cluster. O Kube-proxy então intercepta o tráfego destinado ao CLB de dentro do cluster, contornando a limitação.

**Cenário 2: externalTrafficPolicy: Local bloqueia o acesso interno**

Quando um Service usa externalTrafficPolicy: Local, o acesso interno ao IP do CLB falha a partir de nós sem um pod backend. O endereço do CLB destina-se ao uso externo. O tráfego interno é interceptado pelo kube-proxy e roteado localmente (iptables ou IPVS). Se o nó não tiver um pod backend local, a conexão falhará.

Consulte kube-proxy adds external-lb address to local node iptables rules.

Soluções (listadas por ordem de recomendação):

1. Acesse Services internamente por ClusterIP ou nome do Service. Por exemplo, o nome do Service de Ingress é nginx-ingress-lb.kube-system. Esta é a abordagem recomendada.

2. **Altere externalTrafficPolicy para Cluster.** Isso encaminha o tráfego para todos os nós, mas ativa o SNAT, impedindo que o backend obtenha o IP real do cliente.

      kubectl edit svc nginx-ingress-lb -n kube-system

3. Use passthrough de elastic network interface (ENI) em clusters Terway. Defina externalTrafficPolicy como Cluster e adicione a annotation service.beta.kubernetes.io/backend-type: "eni". Isso preserva o IP de origem e permite o acesso interno. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          service.beta.kubernetes.io/backend-type: eni
        labels:
          app: nginx-ingress-lb
        name: nginx-ingress-lb
        namespace: kube-system
      spec:
        externalTrafficPolicy: Cluster

Quando as instâncias de CLB são excluídas?

O comportamento de exclusão depende se o CCM criou a instância de CLB e como ela foi associada ao Service.

Se o Service reutilizar uma instância de CLB existente (com a annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id}), a exclusão do Service não excluirá a instância de CLB. Caso contrário, a exclusão do Service também excluirá a instância de CLB.

O que fazer se eu excluir acidentalmente uma instância de CLB?

Cenário 1: CLB do Ingress excluído

As etapas a seguir usam o Nginx Ingress como exemplo.

1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, localize o cluster desejado e clique em seu nome. No painel de navegação à esquerda, escolha Network > Services.

3. Selecione kube-system na lista suspensa Namespace.

   • Se nginx-ingress-lb aparecer na lista, clique em Edit YAML na coluna Actions. Remova o campo status.loadBalancer e seu conteúdo, depois clique em OK. O CCM reconstruirá a instância de CLB.

   • Se nginx-ingress-lb não aparecer, clique em Create from YAML e use o seguinte modelo: ``yaml apiVersion: v1 kind: Service metadata: labels: app: nginx-ingress-lb name: nginx-ingress-lb namespace: kube-system spec: externalTrafficPolicy: Local ports: selector: app: ingress-nginx type: LoadBalancer ``

     • name: http port: 80 protocol: TCP targetPort: 80

     • name: https port: 443 protocol: TCP targetPort: 443

Cenário 2: CLB específico de aplicação excluído

• Se o Service não for mais necessário, exclua-o.

• Se o Service ainda estiver em uso:

  1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, localize o cluster desejado e clique em seu nome. No painel de navegação à esquerda, escolha Network > Services.

  3. Na lista suspensa Namespace, clique em All Namespaces e localize o Service desejado.

  4. Na coluna Actions, clique em Edit YAML. Exclua o conteúdo de status.loadBalancer e clique em OK. O CCM reconstruirá a instância de CLB.

Por que a reutilização de uma instância de CLB existente falha?

Verifique os itens a seguir nesta ordem:

1. Versão do CCM: Versões anteriores a v1.9.3.105-gfd4e547-aliyun não suportam a reutilização de instâncias de CLB. Para instruções de atualização, consulte Upgrade the CCM component.

2. Origem da instância: Instâncias de CLB criadas pelo cluster não podem ser reutilizadas.

3. CLB do API server: A instância de CLB do API server não pode ser reutilizada.

4. Incompatibilidade de VPC: Uma instância de CLB privada deve estar na mesma virtual private cloud (VPC) do cluster. A reutilização entre VPCs diferentes não é suportada.

Por que os listeners não são criados ao reutilizar uma instância de CLB existente?

Verifique se a annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners está definida como "true". Sem ela, os listeners não serão criados.

Por padrão, o CCM não substitui listeners em instâncias de CLB existentes:

Substituir listeners ativos pode causar interrupções no serviço.

O CCM suporta configurações de backend limitadas. Para configurações complexas, crie listeners no console de CLB. Force a substituição de listeners apenas quando suas portas não estiverem mais em uso.

O que fazer se uma instância de CLB permanecer no estado Pending?

1. Execute kubectl -n {your-namespace} describe svc {your-svc-name} para verificar as mensagens de evento.

2. Resolva os erros relatados nos eventos. Consulte Service error messages and solutions para obter orientações.

Se nenhum evento aparecer, consulte Why are no events displayed for Service and LoadBalancer synchronization?

O que fazer se um vServer group não for atualizado?

1. Execute kubectl -n {your-namespace} describe svc {your-svc-name} para verificar as mensagens de evento.

2. Resolva os erros relatados nos eventos. Consulte Service error messages and solutions para obter orientações.

Se nenhum evento aparecer, consulte Why are no events displayed for Service and LoadBalancer synchronization?

O que fazer se uma annotation de Service não entrar em vigor?

1. Execute kubectl -n {your-namespace} describe svc {your-svc-name} para verificar se há eventos de erro. Se houver erros, consulte Service error messages and solutions.

2. Se nenhum erro aparecer, verifique o seguinte:

   • Versão do CCM: Verifique se a versão do CCM suporta a annotation. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

   • Presença da annotation: Faça login no console ACK. Na página Services, clique no nome do Service e confirme se a annotation existe. Se estiver ausente, adicione-a. Consulte Use annotations to configure a Classic Load Balancer (CLB) instance.

   • Sintaxe da annotation: Verifique se a chave e o valor da annotation estão corretos.

Para visualizar a lista de Services, consulte Manage services.

Por que nenhum evento é exibido para a sincronização de Service e LoadBalancer?

Se kubectl -n {your-namespace} describe svc {your-svc-name} não mostrar eventos, verifique a versão do CCM:

• Anterior a v1.9.3.276-g372aa98-aliyun: Eventos não são suportados. Atualize o CCM. Para instruções de atualização, consulte Upgrade the CCM component.

• v1.9.3.276-g372aa98-aliyun e posteriores: Abra um ticket para investigação adicional.

Erros de cota e recursos

Erros de configuração

Erros de rede

Erros de reutilização de CLB

Erros de faturamento

Como acessar um Service do tipo NodePort?

• De dentro do cluster (em um nó do cluster): Use ClusterIP + porta ou IP do nó + NodePort do Service. O NodePort padrão é maior que 30000.

• De fora do cluster (dentro da mesma VPC): Use o endereço IP do nó e o NodePort do Service.

• De fora da VPC (de outra VPC ou da internet): Exponha o Service como tipo LoadBalancer e acesse-o por meio de seu endpoint externo.

Se a política de tráfego externo for Local, verifique se o nó acessado hospeda um pod backend do Service. Consulte External traffic policies: Local and Cluster .

Como configurar um listener para um Service do tipo NodePort?

O CCM suporta configuração de listener apenas para Services do tipo LoadBalancer. Altere o tipo de Service de NodePort para LoadBalancer.

Como configurar o intervalo de NodePort?

O parâmetro --service-node-port-range do API server (ServiceNodePortRange) controla o intervalo de portas para Services do tipo NodePort e LoadBalancer. O intervalo padrão é de 30000 a 32767. Em clusters ACK Pro, personalize os parâmetros do plano de controle para ajustar esse intervalo. Consulte Customize the parameters of the control plane for an ACK Pro cluster.

Tenha em mente o seguinte:

• Evite conflitos de intervalo de portas. O intervalo de NodePort não deve se sobrepor ao parâmetro de kernel net.ipv4.ip_local_port_range, que controla os números de porta locais disponíveis para aplicações no nó. O valor padrão de ip_local_port_range é de 32768 a 60999.

• Os intervalos padrão são seguros. Com as configurações padrão do ACK, o ServiceNodePortRange (30000-32767) e o ip_local_port_range (32768-60999) não se sobrepõem. Se algum dos intervalos tiver sido estendido e agora houver sobreposição, poderão ocorrer exceções de rede esporádicas. Em casos graves, as verificações de integridade falham e os nós ficam offline. Restaure os valores padrão ou ajuste ambos os intervalos para eliminar a sobreposição.

• Reconfigure Services existentes após alterações. Após ajustar o intervalo de portas, alguns Services do tipo NodePort ou LoadBalancer ainda podem usar portas dentro do intervalo ip_local_port_range. Execute kubectl edit <service-name> e altere o campo spec.ports.nodePort para um NodePort não utilizado.

O que fazer se uma atualização do CCM falhar?

Consulte Falha na verificação de atualização do Cloud Controller Manager (CCM).

Como adicionar permissões necessárias para uma atualização do CCM em um cluster ACK dedicado?

Versões mais recentes do CCM introduzem APIs da Alibaba Cloud que exigem permissões adicionais do Resource Access Management (RAM). Por exemplo, a v2.11.2 adiciona gerenciamento de rotas para redes Flannel, e a v2.12.1 adiciona gerenciamento em lote para Network Load Balancer (NLB).

Antes de atualizar para a v2.11.2 ou posterior em um cluster ACK dedicado, conceda as permissões necessárias à função RAM do cluster:

1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, localize o cluster desejado e clique em seu nome. No painel de navegação à esquerda, clique em Cluster Information.

3. Clique na aba Basic Information e clique no nome da função em Master RAM Role.

4. No console RAM, clique em Permissions > Policies no painel de navegação à esquerda. Localize a política personalizada que começa com k8sMasterRolePolicy-Ccm- e clique no nome da política.

   Para clusters mais antigos, essa política pode não existir. Selecione uma política personalizada cujo nome comece com k8sMasterRolePolicy- .

5. Clique em Edit Policy Document e adicione a permissão nlb:ListAsynJobs às permissões do NLB. Para clusters Flannel, adicione também as permissões vpc:CreateRouteEntries e vpc:DeleteRouteEntries às permissões da VPC.

   "nlb:ListServerGroupServers",
           "nlb:GetJobStatus",
           "nlb:LoadBalancerLeaveSecurityGroup",
           "nlb:LoadBalancerJoinSecurityGroup",
           "nlb:ListAsynJobs"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },

   },
   {
     "Action": [
       "vpc:Describe*",
       "vpc:DeleteRouteEntry",
       "vpc:CreateRouteEntry",
       "vpc:CreateRouteEntries",
       "vpc:DeleteRouteEntries"
     ],
     "Resource": "*",
     "Effect": "Allow"
   }
   ]
   }

6. Envie as alterações e prossiga com a atualização do CCM.