Configurar um balanceador de carga de aplicativo externo com o Ingress

Como implantar um aplicativo da Web

No manifesto a seguir, você encontra uma implantação que executa a imagem do contêiner do aplicativo da Web de amostra em um servidor HTTP na porta 8080:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

Aplique o recurso ao cluster:

kubectl apply -f web-deployment.yaml

Como expor a implantação dentro do cluster

O manifesto a seguir descreve um Serviço que torna a implantação web acessível no cluster de contêiner:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort

1. Aplique o recurso ao cluster:

   kubectl apply -f web-service.yaml
   

   Quando você cria um serviço do tipo NodePort com esse comando, o GKE o disponibiliza em um número de porta alto selecionado aleatoriamente (por exemplo, 32640) em todos os nós do cluster.

2. Verifique se o serviço foi criado e se uma porta do nó está alocada:

   kubectl get service web
   

   Saída:

   NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   web       NodePort   10.35.245.219   <none>        8080:32640/TCP   5m
   

   Na saída de exemplo, a porta do nó para o serviço do web é 32640. Além disso, não há IP externo alocado para esse Serviço. Como os nós do GKE não podem ser acessados externamente por padrão, criar esse serviço não faz com que o aplicativo possa ser acessado pela Internet.

Para que o aplicativo de servidor da Web HTTP(S) possa ser acessado publicamente, crie um recurso de entrada.

Como criar um recurso de entrada

A entrada é um recurso do Kubernetes que encapsula um conjunto de regras e configurações para encaminhar tráfego HTTP(S) externo aos serviços internos.

No GKE, o Ingress é implementado usando o Cloud Load Balancing. Quando você cria uma entrada no cluster, o GKE cria um balanceador de carga HTTP(S) e o configura para encaminhar tráfego para o aplicativo.

O manifesto a seguir descreve um recurso de entrada que direciona o tráfego para seu serviço web:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  defaultBackend:
    service:
      name: web
      port:
        number: 8080

Aplique o recurso ao cluster:

kubectl apply -f basic-ingress.yaml

Depois que você implantar esse manifesto, o Kubernetes criará um recurso de entrada no cluster. O controlador de entrada do GKE cria e configura um balanceador de carga HTTP(S) de acordo com as informações na entrada, roteando todo o tráfego HTTP externo (na porta 80) para o serviço NodePort web que você expôs.

Visitar seu aplicativo

Para descobrir o endereço IP externo do balanceador de carga que disponibiliza o aplicativo, execute:

kubectl get ingress basic-ingress

NAME            HOSTS     ADDRESS         PORTS     AGE
basic-ingress   *         203.0.113.12    80        2m

Abra o endereço IP externo do aplicativo em um navegador e veja uma resposta HTTP de texto simples como esta:

Hello, world!
Version: 1.0.0
Hostname: web-6498765b79-fq5q5

Acesse Balanceamento de carga no console do Google Cloud e verifique os recursos de rede criados pelo controlador da entrada do GKE.

(Opcional) Como configurar um endereço IP estático

Quando você publica um servidor da Web em um nome de domínio, precisa que o endereço IP externo de um aplicativo seja um IP estático que não seja alterado.

Por padrão, o GKE aloca endereços IP externos temporários de aplicativos HTTP expostos por meio de um Ingress. Endereços temporários estão sujeitos a alterações. Se você planeja executar seu aplicativo por muito tempo, use um endereço IP externo estático.

Depois de configurar um IP estático para o recurso de entrada, a exclusão da entrada não exclui o endereço IP estático associado a ela. Certifique-se de limpar os endereços IP estáticos configurados quando não planejar usá-los novamente.

Para configurar um endereço IP estático, conclua as etapas a seguir:

1. Reserve um endereço IP externo estático nomeado web-static-ip.

   gcloud

   gcloud compute addresses create web-static-ip --global
   

   Config Connector

   Observação: esta etapa requer o Config Connector. Siga estas instruções para instalar o Config Connector no cluster.

   apiVersion: compute.cnrm.cloud.google.com/v1beta1
   kind: ComputeAddress
   metadata:
     name: web-static-ip
   spec:
     location: global

   Para implantar esse manifesto, faça o download dele para sua máquina como compute-address.yaml e execute:

   kubectl apply -f compute-address.yaml

2. O manifesto basic-ingress-static.yaml adiciona uma anotação à entrada para usar o recurso de IP estático chamado web-static-ip:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: basic-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "web-static-ip"
   spec:
     defaultBackend:
       service:
         name: web
         port:
           number: 8080

   Veja o manifesto:

   cat basic-ingress-static.yaml
   

3. Aplique o recurso ao cluster:

   kubectl apply -f basic-ingress-static.yaml
   

4. Verifique o endereço IP externo:

   kubectl get ingress basic-ingress
   

   Aguarde até que o endereço IP do seu aplicativo seja alterado para usar o endereço IP reservado do recurso web-static-ip.

   A atualização do recurso de entrada atual, a reconfiguração do balanceador de carga e a propagação das regras de balanceamento de carga em todo o mundo podem demorar alguns minutos. Após a conclusão da operação, o GKE libera o endereço IP temporário anteriormente alocado ao aplicativo.

(Opcional) Como processar vários aplicativos em um balanceador de carga

Execute vários serviços em um único balanceador de carga e IP público configurando regras de encaminhamento na entrada. Com a hospedagem de vários serviços na mesma entrada, você evita a criação de mais balanceadores de carga, que são recursos faturáveis, para cada serviço publicado na Internet.

O manifesto a seguir descreve uma implantação com a versão 2.0 do mesmo aplicativo da Web:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web2
  namespace: default
spec:
  selector:
    matchLabels:
      run: web2
  template:
    metadata:
      labels:
        run: web2
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
        imagePullPolicy: IfNotPresent
        name: web2
        ports:
        - containerPort: 8080
          protocol: TCP

Aplique o recurso ao cluster:

kubectl apply -f web-deployment-v2.yaml

O manifesto a seguir descreve um serviço que expõe web2 internamente ao cluster em um serviço NodePort chamado web2:

apiVersion: v1
kind: Service
metadata:
  name: web2
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web2
  type: NodePort

Aplique o recurso ao cluster:

kubectl apply -f web-service-v2.yaml

O manifesto a seguir descreve um recurso de entrada que:

• roteia as solicitações com o caminho começando com /v2/ para o serviço web2
• encaminha todas as outras solicitações para o serviço web

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fanout-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web
            port:
              number: 8080
      - path: /v2/*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web2
            port:
              number: 8080

Aplique o recurso ao cluster:

kubectl create -f fanout-ingress.yaml

Depois que a entrada for implantada, execute kubectl get ingress fanout-ingress para descobrir o endereço IP público do cluster.

Em seguida, acesse o endereço IP para ver se os dois aplicativos podem ser acessados no mesmo balanceador de carga:

• Acesse http://<IP_ADDRESS>/ e observe que a resposta contém Version: 1.0.0 (já que a solicitação é encaminhada para o serviço web)
• Acesse http://<IP_ADDRESS>/v2/ e observe que a resposta contém Version: 2.0.0 (já que a solicitação é encaminhada para o serviço web2)

O único caractere curinga aceito no campo path de uma entrada é *. O caractere * precisa vir depois de uma barra (/) e ser o último caractere no padrão. Por exemplo, /*, /foo/* e /foo/bar/* são padrões válidos, ao contrário de *, /foo/bar* e /foo/*/bar.

Um padrão mais específico tem precedência sobre um menos específico. Se você tiver os padrões /foo/* e /foo/bar/*, /foo/bar/bat será usado na correspondência com /foo/bar/*.

Para mais informações sobre limitações de caminho e correspondência de padrões, consulte a documentação dos mapas de URL.

(Opcional) Como monitorar a disponibilidade e a latência do serviço

As verificações de tempo de atividade do Google Cloud realizam o monitoramento de aplicativos do Blackbox do ponto de vista do usuário, determinando a latência e a disponibilidade de vários IPs externos para o endereço IP do balanceador de carga. Em comparação, as verificações de integridade do Google Cloud realizam uma verificação interna em relação aos IPs do pod, determinando a disponibilidade no nível da instância. As verificações são complementares e fornecem uma visão holística da integridade do aplicativo.

É possível criar uma verificação de tempo de atividade usando o Console do Google Cloud, a API Cloud Monitoring ou as bibliotecas de cliente do Cloud Monitoring. Para mais informações, consulte Como gerenciar verificações de tempo de atividade. Se você quiser criar uma verificação de tempo de atividade usando o Console do Google Cloud, faça o seguinte:

1. Acesse a página Serviços e entradas no console do Google Cloud.

   Acesse "Serviços e Entrada"

2. Clique no nome do serviço para o qual você quer criar uma verificação de tempo de atividade.

3. Clique em Criar verificação de tempo de atividade.

4. No painel Criar verificação de tempo de atividade, insira um título para a verificação e clique em Próximo para acessar as configurações de Destino.

   Os campos Destino da verificação de tempo de atividade são preenchidos automaticamente com as informações do balanceador de carga do serviço.

   Para ter acesso à documentação completa de todos os campos em uma verificação de tempo de atividade, consulte Como criar uma verificação de tempo de atividade.

5. Clique em Próximo para acessar as configurações de Validação de resposta.

6. Clique em Próximo para acessar a seção Alerta e notificação.

   Para monitorar uma verificação de tempo de atividade, você pode criar uma política de alertas ou ver o painel de verificação de tempo de atividade. Uma política de alertas pode notificar você por e-mail ou por meio de um canal diferente se a verificação de tempo de atividade falhar. Para informações gerais sobre políticas de alertas, consulte Introdução a alertas.

7. Clique em Criar.

Comentários

Por padrão, a entrada executa uma verificação de integridade periódica. Para fazer isso, realiza uma solicitação GET no caminho / para determinar a integridade do aplicativo. A resposta esperada é HTTP 200. Se você quiser verificar um caminho diferente ou esperar um código de resposta diferente, poderá usar um caminho de verificação de integridade personalizado.

A entrada é compatível com casos de uso mais avançados, como os abaixo:

• Hospedagem virtual baseada em nome: use a Entrada para reaproveitar o balanceador de carga em vários nomes de domínio, subdomínios e para expor diversos serviços em um único endereço IP e balanceador de carga. Confira os exemplos de fanout simples e hospedagem virtual baseada em nome para saber como configurar a entrada para essas tarefas.

• Encerramento HTTPS: é possível configurar a entrada para encerrar o tráfego HTTPS usando o Cloud Load Balancer.

Quando uma entrada é excluída, os recursos associados são limpos automaticamente pelo controlador de entrada do GKE, com exceção dos endereços IP estáticos reservados.