Container Compute Service:Expor um aplicativo com um balanceador de carga existente

Pré-requisitos

Você deve ter uma instância de SLB criada no console do SLB na mesma região do cluster ACS. Este tópico usa como exemplo uma instância de Classic Load Balancer (CLB) voltada para a internet. Se você não tiver uma instância de CLB, consulte Criar e gerenciar instâncias de CLB.

Considerações

Limites de reutilização do SLB

• A instância de SLB a ser reutilizada deve atender aos seguintes requisitos:

  • Somente instâncias de SLB criadas manualmente no console do SLB podem ser reutilizadas. Não é possível reutilizar instâncias criadas automaticamente pelo cloud controller manager (CCM) ou usadas pelo servidor de API do cluster.

  • Para reutilizar uma instância de SLB de rede interna em um cluster ACS, a instância e o cluster devem estar na mesma Virtual Private Cloud (VPC).

  • O tipo de endereço da instância de SLB deve corresponder ao tipo de acesso do Service:

    • Se o Service fornecer Public Access (definido pela anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), o Address Type da instância de SLB deve ser Public Network.

    • Se o Service fornecer acesso interno (definido pela anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), o Address Type da instância de SLB deve ser Internal Network.

  • Vários Services não podem usar a mesma porta de listener na mesma instância de SLB.

  • Ao reutilizar uma instância de SLB entre clusters, garanta que a combinação de namespace e nome do Service seja exclusiva em cada cluster.

• O CCM configura uma instância de SLB apenas para Services do tipo type: LoadBalancer.

  Importante

  Se você alterar um Service type: LoadBalancer para outro tipo, o CCM excluirá as configurações adicionadas à instância de SLB. Consequentemente, o Service ficará inacessível por meio dessa instância.

• O CCM usa uma API declarativa e reconcilia automaticamente a configuração do SLB com base na configuração do Service sob condições específicas. Se a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" estiver definida, quaisquer configurações modificadas manualmente no console do SLB poderão ser sobrescritas.

  Importante

  Não modifique manualmente no console do SLB nenhuma configuração de uma instância gerenciada pelo ACS. Caso contrário, as configurações poderão ser perdidas e o Service poderá ficar inacessível.

• Não é possível alterar a instância de SLB de um Service LoadBalancer existente. Para trocar a instância de SLB, crie um novo Service.

Limites de cota do SLB

• 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, faça login no 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 back-end do SLB conforme a configuração do Service, criando um grupo de servidores separado por targetPort. Limites de cota:

  • Quantidade de servidores de back-end: Uma instância de CLB suporta até 200 servidores; uma instância de NLB suporta até 400 servidores baseados em ECS, ENI ou IP. Fórmula da cota: servidores de back-end × targetPorts. Para aumentar a cota, faça login no console do Quota Center e envie uma solicitação antecipadamente.

  • Anexos de grupos de servidores por instância: Uma instância de ECS ou ENI pode ser anexada a até 50 grupos de servidores de back-end de CLB e 200 de NLB. Para aumentar esse limite, faça login no console do Quota Center e envie uma solicitação.

  • Cota extra durante atualizações contínuas: Novos pods são criados antes da exclusão dos antigos, consumindo cota adicional 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, faça login no console do Quota Center e envie uma solicitação.

• Consulte Limites do CLB e Limites do NLB.

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

Etapa 1: Implantar um aplicativo de exemplo

Os passos a seguir demonstram como implantar o aplicativo usando kubectl.

1. Use o kubectl no Cloud Shell para conectar-se ao seu cluster.

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

   Visualize o conteúdo YAML

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-nginx                 # The name of the sample application.
     labels:
       app: nginx
   spec:
     replicas: 3                    # The number of replicas.
     selector:
       matchLabels:
         app: nginx                 # This value must match the selector in the Service manifest to expose the application.
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
           ports:
           - containerPort: 80        # This port must be exposed in the Service.

3. Execute o comando abaixo para implantar o aplicativo de exemplo my-nginx.

   kubectl apply -f my-nginx.yaml

4. Execute o comando a seguir para verificar se o aplicativo está em execução.

   kubectl get deployment my-nginx

   Saída esperada:

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

Etapa 2: Expor o aplicativo com um Service

Crie um Service LoadBalancer para expor o aplicativo usando o console ou o kubectl.