Expor uma aplicação com um balanceador de carga criado automaticamente - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Se você não tiver um balanceador de carga disponível, o componente cloud-controller-manager (CCM) cria e gerencia automaticamente uma instância de balanceador de carga para um service do tipo type: LoadBalancer. Essa instância pode ser um Classic Load Balancer (CLB) ou um Network Load Balancer (NLB). Este tópico descreve como expor uma aplicação Nginx usando um service que cria automaticamente um balanceador de carga.

Notas de uso

Considerações para instâncias de SLB gerenciadas pelo CCM

O CCM configura o balanceamento de carga apenas para Services do tipo Type=LoadBalancer.

Importante

Se um Service Type=LoadBalancer for alterado para outro tipo, o CCM excluirá as configurações do SLB. O Service ficará inacessível por meio da instância de SLB.

O CCM utiliza uma API declarativa e pode atualizar a configuração do SLB com base em alterações no Service. Modificações manuais no console do SLB podem ser sobrescritas.

Importante

Não modifique as configurações de instâncias de SLB gerenciadas pelo ACK no console do SLB. Suas alterações podem ser perdidas e o Service pode ficar inacessível.

Não exclua nem modifique o finalizer service.k8s.alibaba/resources ou service.k8s.alibaba/nlb. Isso pode impedir a recuperação correta dos recursos do CLB ou NLB.
Para o Cloud Controller Manager v2.5.0 ou posterior, especificar uma instância de CLB ao criar um Service requer inclusão na lista de permissões. Envie uma solicitação no Quota Center.

Server Load Balancer

O CCM cria uma instância de SLB para cada Service Type=LoadBalancer. A cota padrão é de 60 instâncias de CLB e 60 de NLB. Para aumentar essa cota, acesse o console do Quota Center e envie uma solicitação.
O CCM anexa instâncias de ECS ou Elastic Network Interfaces (ENIs) ao grupo de servidores de backend do SLB conforme a configuração do Service, criando um grupo de servidores separado por targetPort. Limites de cota:
- Número de servidores de backend: Uma instância de CLB suporta até 200 servidores de backend; uma instância de NLB suporta até 400 servidores baseados em ECS, ENI ou IP. Fórmula da cota: servidores de backend × targetPorts. Para aumentar a cota, acesse o console do Quota Center e envie uma solicitação com antecedência.
- Anexos de grupo de servidores por instância: Uma instância de ECS ou ENI pode ser anexada a até 50 grupos de servidores de backend de CLB e 200 grupos de servidores de backend de NLB. Para aumentar esse limite, acesse o console do Quota Center e envie uma solicitação.
- Cota extra durante atualizações contínuas: Novos pods são criados antes da destruição dos antigos, consumindo cota extra que pode exceder as expectativas. Reserve cota suficiente com antecedência.
O CCM cria listeners com base nas portas do Service. O limite padrão é de 50 listeners por instância de CLB ou NLB. Para adicionar mais, acesse o console do Quota Center e envie uma solicitação.
Consulte CLB limits e NLB limits.

Verifique as cotas do SLB em Gerenciamento de cotas do Server Load Balancer.

Implantar uma aplicação

Implante uma aplicação NGINX stateless como backend do Service LoadBalancer.

Usar o console do ACK

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel à esquerda, escolha Workloads > Deployments.

Na página Deployments, clique em Create from Image e configure o Deployment:

Na página Basic Information, defina Name como my-nginx e clique em Next.

Na página Container, configure a imagem e a porta:

Parâmetro	Valor
Image Name	Clique em Select images. Na aba Artifact Center, pesquise por `nginx` e selecione openanolis/nginx. Clique em Select Image Tag, defina uma tag e clique em OK.
Port	Nome: `nginx`, Porta do Contêiner: `80`

Na página Advanced, mantenha os padrões e clique em Create.

Usar kubectl

Crie um arquivo chamado my-nginx.yaml com o seguinte conteúdo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx        # Deployment name
  labels:
    app: nginx
spec:
  replicas: 2           # Number of pod replicas
  selector:
    matchLabels:
      app: nginx        # Must match the selector in the Service
  template:
    metadata:
      labels:
        app: nginx
    spec:
    #  nodeSelector:
    #    env: test-team
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80

Implante a aplicação:
```
kubectl apply -f my-nginx.yaml
```

Verifique se o Deployment está pronto:

kubectl get deployment my-nginx

Saída esperada:

NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   2/2     2            2           50s

Etapa 2: Expor a aplicação com um balanceador de carga criado automaticamente

Crie um service do tipo type: LoadBalancer e exponha sua aplicação usando o console do ACK ou o kubectl.

A partir de 11 de setembro de 2025, a criação de um Service do tipo Classic Load Balancer (CLB) por meio do console requer acesso à lista de permissões. Antes de criar um Service do tipo CLB no console, envie uma solicitação de cota privilegiada para "Criação baseada em console de um Service do tipo CLB" no Quota Center (IDs de cota: ack.white_list / ack.create_clb_service). Você só poderá criar um Service do tipo CLB no console após a aprovação da solicitação. Para mais informações, consulte o anúncio de alteração do product.

Console

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Network > Services.

Na página Services, clique em Create. Na caixa de diálogo Create Service, defina os parâmetros do service.

Parâmetro	Descrição	Exemplo
Name	Insira um nome para o service.	my-nginx-svc
service type	Selecione um service type. Um service suporta os seguintes modos de rede para lidar com acessos de diferentes tipos e origens de clientes: Cluster IP Este tipo permite comunicação dentro de um cluster. A descoberta de services entre instâncias de service é suportada apenas quando o tipo de service é definido como ClusterIP. Ao usar um Headless Service, você pode interagir com outros mecanismos de descoberta de services sem depender da descoberta de services e balanceamento de carga padrão baseados em ClusterIP fornecidos pelo Kubernetes. LoadBalancer Ao integrar-se ao Classic Load Balancer (CLB) e Network Load Balancer (NLB) da Alibaba Cloud, você pode expor aplicações dentro do cluster ao tráfego externo. Este método melhora significativamente a disponibilidade e o desempenho da aplicação em comparação ao método NodePort. Node Port Fornece uma maneira conveniente para usuários externos acessarem services no cluster através do endereço IP e de uma porta específica de um nó. Os usuários podem se conectar a um service NodePort acessando `<NodeIP>:<NodePort>`, mas você deve configurar manualmente o balanceamento de carga.	Selecione Server Load Balancer como o tipo de service. Selecione CLB como o tipo de balanceador de carga e selecione Create Resource. Na seção suspensa Create CLB Instance, ajuste as configurações conforme necessário. Defina o Billing Method como Pay-by-specification.
External Traffic Policy	Defina o tipo de service como Node Port ou Server Load Balancer antes de configurar a External Traffic Policy. Para mais informações, consulte Manage services. Local: O tráfego vai apenas para pods no mesmo nó. Cluster: O tráfego pode ser encaminhado para pods em outros nós do cluster.	Local
Backend	Selecione a aplicação de backend para vincular ao service. Se você não associar um deployment, o sistema não criará objetos Endpoints. Para mais informações, consulte services-without-selectors.	Nome: app Valor: nginx
Port Mapping	Adicione uma porta de service (corresponde ao campo `port` no arquivo YAML do Service) e uma porta de contêiner (corresponde ao campo `targetPort` no arquivo YAML do Service). A porta do contêiner deve corresponder à porta exposta pelo pod de backend.	Porta do Service: 80 Porta do Contêiner: 80 Protocolo: TCP
annotations	Adicione uma annotation ao service para configurar parâmetros do balanceador de carga. Para mais parâmetros, consulte Configure CLB using annotations e Configure NLB using annotations. Importante Não reutilize a instância de balanceador de carga do API Server do cluster. Caso contrário, o acesso ao cluster pode ser interrompido.	Neste exemplo, o tráfego de rede pública para o service é faturado com base na largura de banda, com um pico de largura de banda de 2 Mbit/s para controlar o tráfego. As annotations são as seguintes: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: paybybandwidth` `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: 2`
labels	Adicione um rótulo para identificar o service.	Nenhum
Service Deletion Protection	Ative a proteção contra exclusão para services que suportam negócios críticos ou lidam com dados sensíveis. Isso evita exclusões acidentais e reduz custos de manutenção. Após ativar a proteção contra exclusão, você deve desativá-la manualmente antes de excluir o recurso. Nota Para usar este recurso, instale os componentes policy-template-controller e gatekeeper do complemento Container Security Policy. Clique em Install Now para implantar os componentes.	Desativado

Após configurar os parâmetros, clique em OK.

Depois que o service for criado, clique em seu nome para acessar a página de detalhes. Na seção Basic Information, clique no External IP do service, como 39.106.XX.XX:80, para acessar a aplicação de exemplo.

Kubectl

Crie um arquivo chamado my-nginx-svc.yaml com o seguinte conteúdo para o service de exemplo.
Defina o selector com o valor de matchLabels no arquivo da aplicação de exemplo my-nginx.yaml, que é app: nginx neste exemplo. Isso associa o service à aplicação de backend.
```
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: my-nginx-svc
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
```
Aplique o Service:
```
kubectl apply -f my-nginx-svc.yaml
```

Confirme se o Service possui um IP externo:

kubectl get svc my-nginx-svc

Saída esperada:

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
my-nginx-svc   LoadBalancer   172.21.5.82   39.106.XX.XX     80:30471/TCP   5m

Acesse a aplicação:

curl <YOUR-EXTERNAL-IP>    # Replace with the external IP from the previous step

Saída esperada:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
</html>

Classic Load Balancer (CLB)

Create CLB Instance

Ao criar um Classic Load Balancer (CLB), siga as instruções para criar uma instância de CLB. Para mais informações, consulte Create and manage CLB instances.

Nome	Descrição
Name	Insira um nome personalizado para o CLB.
Access Method	Selecione Public Access ou Internal Access.
Billing Method	Selecione Pay-by-specification ou Pay-as-you-go (Pay-by-CU). Para mais informações, consulte CLB billing overview.
IP Version	Selecione IPv4 ou IPv6. Importante Para usar IPv6, certifique-se de que a região do seu cluster ACK suporte instâncias de CLB IPv6. Para regiões que suportam CLB IPv6, consulte CLB supported regions.
Scheduling Algorithm	Os algoritmos suportados são round robin (RR) e weighted round robin (WRR). RR (padrão): Distribui solicitações externas para servidores de backend em sequência. WRR: Servidores de backend com pesos maiores recebem mais solicitações.
Access Control	Fornece controle de acesso no nível do listener. Para mais informações, consulte Access control.
Health Check	Suporta protocolos TCP e HTTP. Após ativar as verificações de integridade, use-as para determinar a disponibilidade dos servidores de backend. Para mais informações, consulte CLB health check.
Others	Configure o CLB usando annotations. Para mais informações, consulte Configure CLB using annotations.

Use Existing Resource

Selecione uma instância existente de Classic Load Balancer (CLB) na lista suspensa. Você também pode selecionar a opção para sobrescrever forçadamente os listeners existentes. Para mais informações, consulte Use existing load balancer and force overwrite existing listeners.

Importante

A reutilização de instâncias de CLB está sujeita a certas limitações e considerações. Para mais informações, consulte Which Server Load Balancers can be reused?.

Configure Resources

Nome	Descrição
Scheduling Algorithm	Suporta duas políticas: round-robin (RR) e weighted round-robin (WRR). RR é o padrão. Com RR, o Server Load Balancer distribui solicitações externas para servidores de backend em sequência. Com WRR, servidores de backend com pesos maiores recebem mais solicitações.
Access Control	Fornece controle de acesso no nível do listener. Para mais informações, consulte Access control.
Health Check	Suporta protocolos TCP e HTTP. Após ativar as verificações de integridade, o Server Load Balancer as utiliza para avaliar a disponibilidade dos seus servidores de backend. Para saber como funcionam as verificações de integridade, consulte How Server Load Balancer health checks work.
Others	Você também pode configurar um Classic Load Balancer usando annotations. Para mais informações, consulte Configure a Classic Load Balancer using annotations.

Network Load Balancer (NLB)

Create NLB Instance

É possível criar um recurso Network Load Balancer (NLB). Para mais informações, consulte Create and manage NLB instances.

Nome	Descrição
Name	Insira um nome personalizado para a instância de NLB. Este parâmetro é obrigatório apenas quando você cria uma nova instância de NLB.
Access Method	Selecione Public Access ou Internal Access conforme necessário.
Billing Method	Pay-as-you-go. Para mais informações, consulte NLB billing.
IP Version	Selecione IPv4 ou DualStack conforme necessário.
Scheduling Algorithm	Selecione um algoritmo de agendamento. Round Robin: Distribui solicitações para servidores de backend em sequência. Weighted Round-robin (Padrão): Distribui solicitações para servidores de backend com base em seus pesos. Servidores de backend com pesos maiores recebem mais solicitações. Source IP Hashing: Usa hash consistente com base em endereços IP de origem. Solicitações do mesmo endereço IP de origem são roteadas para o mesmo servidor de backend. Four-element Hashing: Usa hash consistente com base em quádruplas (IP de origem, IP de destino, porta de origem e porta de destino). Pacotes do mesmo fluxo são roteados para o mesmo servidor de backend. QUIC ID Hashing: Usa hash consistente com base em IDs de conexão QUIC. Solicitações com o mesmo ID QUIC são roteadas para o mesmo servidor de backend. Você pode selecionar o hash de ID QUIC apenas quando o protocolo de backend for UDP. O protocolo QUIC está evoluindo rapidamente. Este algoritmo é implementado com base no draft-ietf-quic-transport-10. A compatibilidade com todas as versões do QUIC não é garantida. Recomendamos que você realize testes suficientes antes de usar este algoritmo em um ambiente de produção. Weighted Least Connections: Este algoritmo considera a carga real (número de conexões) dos servidores de backend além do peso de cada servidor. Se os servidores de backend tiverem o mesmo peso, o servidor com o menor número de conexões ativas será consultado com mais frequência.
Health Check	Ative ou desative as verificações de integridade. TCP (Padrão): Envia mensagens de handshake SYN para verificar se a porta do servidor está ativa. Response Timeout Period: Insira o período de espera por uma resposta de uma verificação de integridade. Se um servidor de backend não responder corretamente dentro do período especificado, a verificação de integridade falhará. Health Check Interval: Insira o intervalo para as verificações de integridade. Healthy Threshold: O número de verificações de integridade bem-sucedidas consecutivas necessárias para alterar o status de verificação de integridade de um servidor de backend de falha para sucesso. Unhealthy Threshold: O número de verificações de integridade com falha consecutivas necessárias para alterar o status de verificação de integridade de um servidor de backend de sucesso para falha. Http : Envia solicitações HEAD ou GET para simular o acesso do navegador e verificar a integridade da aplicação do servidor. Domain Name: Insira o nome de domínio para a verificação de integridade. Backend Server Internal IP (Padrão): Usa o endereço IP privado do servidor de backend como o nome de domínio para a verificação de integridade. Custom Domain Name: Insira um nome de domínio. Health Check Path: Insira a URL da página de verificação de integridade. Health Check Status Codes: Selecione http_2xx (Padrão), http_3xx, http_4xx ou http_5xx.
Others	Você também pode configurar a instância de NLB usando annotations. Para mais informações, consulte Configure an NLB instance using annotations.
VPC	A região e o ID da VPC padrão para o cluster.
vSwitch	Selecione um switch virtual para uma zona suportada na VPC padrão do cluster. Você também pode clicar em Create vSwitch para criar um novo.

Use Existing Resource

Selecione uma instância de NLB existente na lista suspensa. Você também pode selecionar a opção para sobrescrever forçadamente o listener existente. Para mais informações, consulte Use an existing Server Load Balancer instance.

Importante

A reutilização de uma instância de NLB está sujeita a certas limitações. Para mais informações, consulte Which Server Load Balancer instances can be reused?

Configure Resources

Nome	Descrição
Scheduling Algorithm	Selecione um algoritmo de agendamento. Round Robin: Distribui solicitações para servidores de backend em sequência. Weighted Round-robin (Padrão): Distribui solicitações para servidores de backend com base em seus pesos. Servidores de backend com pesos maiores recebem mais solicitações. Source IP Hashing: Usa hash consistente com base em endereços IP de origem. Solicitações do mesmo endereço IP de origem são roteadas para o mesmo servidor de backend. Four-element Hashing: Usa hash consistente com base em quádruplas (IP de origem, IP de destino, porta de origem e porta de destino). Pacotes do mesmo fluxo são roteados para o mesmo servidor de backend. QUIC ID Hashing: Usa hash consistente com base em IDs de conexão QUIC. Solicitações com o mesmo ID QUIC são roteadas para o mesmo servidor de backend. Você pode selecionar o hash de ID QUIC apenas quando o protocolo de backend for UDP. O protocolo QUIC está evoluindo rapidamente. Este algoritmo é implementado com base no draft-ietf-quic-transport-10. A compatibilidade com todas as versões do QUIC não é garantida. Recomendamos que você realize testes suficientes antes de usar este algoritmo em um ambiente de produção. Weighted Least Connections: Este algoritmo considera a carga real (número de conexões) dos servidores de backend além do peso de cada servidor. Se os servidores de backend tiverem o mesmo peso, o servidor com o menor número de conexões ativas será consultado com mais frequência.
Health Check	Ative ou desative as verificações de integridade. TCP (Padrão): Envia mensagens de handshake SYN para verificar se a porta do servidor está ativa. Response Timeout Period: Insira o período de espera por uma resposta de uma verificação de integridade. Se um servidor de backend não responder corretamente dentro do período especificado, a verificação de integridade falhará. Health Check Interval: Insira o intervalo para as verificações de integridade. Healthy Threshold: O número de verificações de integridade bem-sucedidas consecutivas necessárias para alterar o status de verificação de integridade de um servidor de backend de falha para sucesso. Unhealthy Threshold: O número de verificações de integridade com falha consecutivas necessárias para alterar o status de verificação de integridade de um servidor de backend de sucesso para falha. Http : Envia solicitações HEAD ou GET para simular o acesso do navegador e verificar a integridade da aplicação do servidor. Domain Name: Insira o nome de domínio para a verificação de integridade. Backend Server Internal IP (Padrão): Usa o endereço IP privado do servidor de backend como o nome de domínio para a verificação de integridade. Custom Domain Name: Insira um nome de domínio. Health Check Path: Insira a URL da página de verificação de integridade. Health Check Status Codes: Selecione http_2xx (Padrão), http_3xx, http_4xx ou http_5xx.
Others	Você também pode configurar a instância de NLB usando annotations. Para mais informações, consulte Configure an NLB instance using annotations.
VPC	A região e o ID da VPC padrão para o cluster.
vSwitch	Selecione um switch virtual para uma zona suportada na VPC padrão do cluster. Você também pode clicar em Create vSwitch para criar um novo.

Próximas etapas

Se precisar visualizar, atualizar ou excluir um service, ou ativar a proteção contra exclusão de service, execute as operações a seguir. Por exemplo, é possível modificar o balanceador de carga público associado ao service.

Importante

Quando você exclui um Service ou altera seu tipo de LoadBalancer para outro tipo, a instância de balanceador de carga criada automaticamente é liberada automaticamente.

Console

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Network > Services.
Na página Services, localize o service desejado e clique em Update na coluna Actions ou clique no ícone para atualizar, Delete ou Enable Deletion Protection para o service.

Kubectl

Atualizar um service

Método 1: Execute o comando a seguir para atualizar o service.
```
kubectl edit service my-nginx-svc
```
Método 2: Modifique o arquivo YAML e aplique as alterações.
```
kubectl apply -f my-nginx-svc.yaml
```

Visualizar um service

Execute o comando a seguir para visualizar o service.

kubectl get service my-nginx-svc

Saída esperada:

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
my-nginx-svc   LoadBalancer   172.21.XX.XX   192.168.XX.XX     80:31599/TCP   5m

Excluir um service

Execute o comando a seguir para excluir o service.

kubectl delete service my-nginx-svc