Container Service for Kubernetes:Exponha serviços com o ALB Ingress

Instale o ALB Ingress Controller

Crie um aplicativo de exemplo

O aplicativo de exemplo implanta um Deployment chamado coffee e um Service correspondente chamado coffee-svc.

Crie um ALB Ingress

Configure o nome de domínio e os mapeamentos de caminho para o ALB Ingress rotear as requisições de ingress-demo.com/coffee para o Service coffee-svc dentro do cluster.

Para usar um ALB Ingress em um cluster dedicado ACK , você deve conceder permissões de acesso ao ALB Ingress Controller .

Por que um Ingress retorna códigos de erro HTTP?

Causas

• Erro 503 (Service Temporarily Unavailable)

  • Nenhuma regra de roteamento correspondente: O caminho da requisição não corresponde a nenhuma regra de roteamento configurada no Ingress.

  • Nenhum pod de backend íntegro: O Service associado não possui pods prontos, o que resulta em um objeto de endpoints vazio.

• Erro 502 (Bad Gateway)

  Após um listener HTTP ou HTTPS receber uma requisição de conexão do cliente, o ALB envia um código de status HTTP 502 Bad Gateway ao cliente porque não consegue encaminhar a requisição para um Pod ou receber uma resposta dele.

• Erro 404 (Not Found)

  Geralmente ocorre quando uma requisição corresponde a uma regra de roteamento do Ingress, mas sua URL não corresponde ao caminho do Service do aplicativo no pod de backend.

• Erro 400 (Bad Request)

  Pode ocorrer por vários motivos, como enviar uma requisição HTTP para um listener HTTPS.

Para mais informações sobre códigos de erro HTTP, consulte Códigos de status do ALB .

Solução

1. Verifique o status do Ingress: Execute o comando kubectl describe ingress <ingress-name> -n <namespace> e inspecione a seção Events em busca de mensagens de erro. Se aparecer um evento como listener is not exist in alb, adicione a configuração de listener necessária ao seu AlbConfig.

   ...
   Events:
     Type     Reason                  Age     From     Message
     ----     ------                  ----    ----     -------
     Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
     Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
   ...

2. Verifique os endpoints de backend: Execute o comando kubectl get endpoints <service-name> -n <namespace> para confirmar que o campo ENDPOINTS lista pelo menos um endereço IP e porta de pod íntegro. Se estiver vazio, verifique se o selector do Service corresponde aos labels dos pods e se os pods estão no estado Running.

3. Verifique o status e os logs do pod: Execute kubectl get pod -l <app=your-app> -n <namespace> para visualizar o status do pod. Em seguida, use o nome do pod para executar kubectl logs <pod-name> -n <namespace> e verifique os logs do aplicativo em busca de falhas de inicialização ou erros de processamento de requisição.

4. Teste a conectividade de rede: De dentro de um pod ou de um nó, use curl para acessar o ClusterIP do Service de backend ou o IP de um pod e verifique se o Service está acessível dentro do cluster.

Por que o HTTPS fica inacessível após a configuração do TLS?

Causas

• A instância ALB não está escutando na porta 443: Você configurou o TLS para o Ingress, mas o listener HTTPS:443 correspondente não foi criado.

• Configuração de certificado incorreta: O tipo do Secret não é kubernetes.io/tls ou IngressTLS, ou o conteúdo de tls.crt e tls.key no campo data está incorreto ou não corresponde.

• Certificado desatualizado: A instância ALB pode estar usando um certificado antigo. Isso acontece se você atualizar um certificado no Alibaba Cloud Certificate Management Service, mas não atualizar o ID do certificado no seu AlbConfig, ou se a descoberta e a reconciliação automáticas não forem acionadas.

Solução

1. Verifique a porta do listener: Execute o comando kubectl describe albconfig <alb-name> -n <namespace> para confirmar que as configurações spec.listeners.port: 443 e spec.listeners.protocol: HTTPS estão presentes.

2. Verifique a configuração do Ingress: Confirme se a configuração do Ingress inclui a annotation alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]. Esta annotation associa o Ingress aos listeners HTTP e HTTPS.

3. Verifique a configuração do Secret: Na configuração do Ingress, verifique o campo secretName de spec.tls para confirmar que o Secret correto está referenciado. Execute o comando kubectl get secret <secret-name> -n <namespace> -o yaml para confirmar o tipo do Secret e a integridade dos dados.

Como configurar a resolução de domínio do Ingress?

1. Registre um nome de domínio.

2. Adicione um registro CNAME.

   Por exemplo, adicione um registro DNS com o tipo de registro CNAME , o registro de host @ (que representa o domínio raiz, como ingress-demo.com ), e o valor do registro como o endereço do endpoint do Ingress .

3. Em um navegador, acesse http://ingress-demo.com/coffee para verificar se a resolução do nome de domínio está funcionando.

   Após o acesso bem-sucedido, uma página de teste do NGINX é retornada, exibindo informações como Server address, Server name, Date e URI (com o valor /coffee) do pod de backend. Isso indica que o Ingress roteou corretamente a requisição para o pod de backend.

   Para verificação, substitua o exemplo pelo seu nome de domínio registrado. Se a resolução do nome de domínio falhar, consulte Solução rápida de problemas para falhas na resolução de nomes de domínio .

Como configuro o HTTPS para um Ingress?

1. Compre um certificado oficial, e solicite um certificado. Certifique-se de que o certificado que você deseja usar esteja no estado Issued.

2. Baixe o certificado SSL.

   Este exemplo mostra como baixar o arquivo de certificado no formato PEM para o domínio ingress-demo.com , com o tipo de servidor definido como Other .

3. Crie um Secret para armazenar o arquivo de certificado.

   1. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Configurations > Secrets.

   2. Na página Secrets, selecione o namespace default e clique em Create à esquerda. Adicione as seguintes configurações e clique em OK.

      • Name: ingress-tls

      • Type: Ingress TLS Certificate

      • Certificates: O conteúdo completo do arquivo de certificado baixado e descompactado (.pem).

      • Key: O conteúdo completo do arquivo de chave privada baixado e descompactado (.key).

4. Atualize o AlbConfig para adicionar um listener HTTPS:443 à instância ALB.

   1. No painel de navegação à esquerda, escolha Workloads > Custom Resources. Na aba Resource Objects, pesquise por AlbConfig e clique no resultado da pesquisa.

   2. Na lista de objetos de recurso AlbConfig, encontre o recurso de destino alb e clique em Edit YAML na coluna Actions.

   3. Adicione os campos spec.listeners.port: 443 e spec.listeners.protocol: HTTPS e clique em OK.

      spec:
          config:
            addressAllocatedMode: Fixed
            addressType: Internet
            zoneMappings:
              - vSwitchId: vsw-xxx
              - vSwitchId: vsw-xxx
          listeners:
            - port: 80
              protocol: HTTP
            - port: 443
              protocol: HTTPS

5. Atualize o Ingress para adicionar uma configuração TLS e associá-la ao listener HTTPS:443.

   1. No painel de navegação à esquerda, escolha Network > Ingresses. Na coluna Actions do Ingress de destino, clique em Update.

   2. Adicione as seguintes configurações e clique em OK.

      • TLS Settings: Enabled

      • Domain Name: ingress-demo.com

      • Secrets: ingress-tls

      • Annotations: alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]

6. Em um navegador, acesse https://ingress-demo.com/coffee para verificar o acesso HTTPS.

   A página exibe o logotipo do NGINX e as informações de resposta do servidor. O Server address, Server name e URI (com o valor /coffee) são retornados conforme o esperado. Isso confirma que o HTTPS está configurado corretamente e que o Ingress roteia as requisições para o pod de backend do coffee.

   Para verificação, substitua o exemplo pelo seu nome de domínio registrado.

Para mais informações sobre como configurar certificados HTTPS, consulte Configure certificados HTTPS para comunicação criptografada.

Como criar manualmente o AlbConfig e o IngressClass?

Crie um AlbConfig

1. Acesse o VPC console e anote os IDs de pelo menos dois vSwitches que estejam em zonas de disponibilidade diferentes dentro da VPC onde o cluster está implantado.

   As zonas de disponibilidade dos vSwitches configurados devem ser suportadas pelo ALB. Para mais informações, consulte Regiões e zonas do ALB .

2. Substitua zoneMappings.vSwitchId no código a seguir pelos IDs dos vSwitches obtidos na etapa anterior. Salve o conteúdo em um arquivo chamado albconfig.yaml e execute kubectl apply -f albconfig.yaml para criar o AlbConfig.

   Para etapas mais detalhadas, consulte Criar um AlbConfig .

   apiVersion: alibabacloud.com/v1
   kind: AlbConfig
   metadata:
     name: alb # Do not create another AlbConfig resource with the same name.
   spec:
     config:
       name: alb-test
       addressType: Internet
       zoneMappings:
       - vSwitchId: vsw-****cg2a9g71hx8go**** # Replace with your actual vSwitch ID.
       - vSwitchId: vsw-****un9tql5t8nh15**** # Replace with your actual vSwitch ID.
     listeners:
       - port: 80
         protocol: HTTP

Crie um IngressClass

O recurso IngressClass associa um AlbConfig aos recursos Ingress. Quando você especifica ingressClassName: alb em um Ingress, ele usa o AlbConfig definido no IngressClass alb.

Salve o seguinte conteúdo em um arquivo chamado IngressClass.yaml e execute kubectl apply -f IngressClass.yaml para criar o IngressClass.

O campo spec.parameters.name deve ser definido com o nome do AlbConfig. O AlbConfig padrão criado ao instalar o componente chama-se alb . Para mais informações, consulte Usar o IngressClass para associar um AlbConfig a um Ingress .

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb # This must match the name of the AlbConfig resource.