Como implantar a Entrada em clusters

Autopilot Padrão

---

Nesta página, mostraremos como implantar um Ingress que exibe um aplicativo em vários clusters do GKE. Para saber mais sobre a entrada de vários clusters, consulte entrada de vários clusters.

Para uma comparação detalhada entre Ingress de vários clusters (MCI), Gateway de vários clusters (MCG) e balanceador de carga com grupos de endpoints de rede independentes (LB e NEGs independentes), consulte Escolher sua API de balanceamento de carga de vários clusters para o GKE.

Tutorial de implantação

Nas tarefas a seguir, você implantará um aplicativo fictício chamado whereami e um MultiClusterIngress em dois clusters. O Ingress fornece um endereço IP virtual (VIP, na sigla em inglês) compartilhado para as implantações do aplicativo.

Esta página baseia-se no trabalho feito em Como configurar a entrada de vários clusters, onde você criou e registrou dois clusters. Confirme se você tem dois clusters que também estão registrados em uma frota:

gcloud container clusters list

A saída será assim:

NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-b  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-b   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

Como criar o namespace

Como as frotas têm a propriedade de semelhança de namespace, recomendamos coordenar a criação e o gerenciamento de namespaces em clusters para que os namespaces idênticos sejam de propriedade e gerenciados pelo mesmo grupo. É possível criar namespaces por equipe, por ambiente, por aplicativo ou por componente do aplicativo. Os namespaces podem ser tão granulares quanto necessário, desde que um namespace ns1 em um cluster tenha o mesmo significado e uso de ns1 em outro cluster.

Neste exemplo, você cria um namespace whereami para cada aplicativo em cada cluster.

1. Crie um arquivo chamado namespace.yaml que tenha o seguinte conteúdo:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: whereami
   

   Observação: é possível usar kubectl config use-context para alternar entre clusters ao implantar recursos. Use kubectl config get-contexts para ver quais estão disponíveis. Use kubectl config rename-context para renomear contextos para nomes mais humanos.

2. Alterne para o contexto do gke-us:

   kubectl config use-context gke-us
   

3. Crie o namespace:

   kubectl apply -f namespace.yaml
   

4. Alterne para o contexto do gke-eu:

   kubectl config use-context gke-eu
   

5. Crie o namespace:

   kubectl apply -f namespace.yaml
   

   A saída será assim:

   namespace/whereami created
   

Como implantar o app

1. Crie um arquivo chamado deploy.yaml que tenha o seguinte conteúdo:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-deployment
     namespace: whereami
     labels:
       app: whereami
   spec:
     selector:
       matchLabels:
         app: whereami
     template:
       metadata:
         labels:
           app: whereami
       spec:
         containers:
         - name: frontend
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
           - containerPort: 8080
   

2. Alterne para o contexto do gke-us:

   kubectl config use-context gke-us
   

3. Implante o aplicativo whereami:

   kubectl apply -f deploy.yaml
   

4. Alterne para o contexto do gke-eu:

   kubectl config use-context gke-eu
   

5. Implante o aplicativo whereami:

   kubectl apply -f deploy.yaml
   

6. Verifique se o aplicativo whereami foi implantado com sucesso em cada cluster:

   kubectl get deployment --namespace whereami
   

   A saída será semelhante a esta nos dois clusters:

   NAME           READY   UP-TO-DATE   AVAILABLE   AGE
   whereami-deployment   1/1     1            1           12m
   

Como implantar com o cluster de configuração

Agora que o aplicativo foi implantado em gke-us e gke-eu, você implantará um balanceador de carga implantando os recursos MultiClusterIngress e MultiClusterService no cluster de configuração. Eles são os equivalentes de vários clusters dos recursos de entrada e serviço.

No guia de configuração, você configurou gke-us como o cluster de configuração. O cluster de configuração é usado para implantar e configurar o Ingress em todos os clusters.

1. Defina o contexto como o cluster de configuração.

   kubectl config use-context gke-us
   

   Observação: só pode haver um cluster de configuração ativo por vez. É possível implantar recursos MultiClusterIngress e MultiClusterService em outros clusters, mas eles não serão vistos nem processados pelo controlador do Ingress de vários clusters.

MultiClusterService

1. Crie um arquivo chamado mcs.yaml que tenha o seguinte conteúdo:

   apiVersion: networking.gke.io/v1
   kind: MultiClusterService
   metadata:
     name: whereami-mcs
     namespace: whereami
   spec:
     template:
       spec:
         selector:
           app: whereami
         ports:
         - name: web
           protocol: TCP
           port: 8080
           targetPort: 8080
   

2. Implante o recurso MultiClusterService que corresponde ao aplicativo whereami:

   kubectl apply -f mcs.yaml
   

3. Verifique se o recurso whereami-mcs foi implantado no cluster de configuração:

   kubectl get mcs -n whereami
   

   A saída será assim:

   NAME       AGE
   whereami-mcs   9m26s
   

   Esse MultiClusterService cria um serviço sem comando derivado em cada cluster que corresponde a pods com app: whereami. É possível ver que existe um no cluster gke-us kubectl get service -n whereami.

   A saída será assim:

   NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
   mci-whereami-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s
   

Um serviço sem comando semelhante também existirá em gke-eu. Esses serviços locais são usados para selecionar dinamicamente os endpoints do pod para programar o balanceador de carga global do Ingress com back-ends.

MultiClusterIngress

1. Crie um arquivo chamado mci.yaml que tenha o seguinte conteúdo:

   apiVersion: networking.gke.io/v1
   kind: MultiClusterIngress
   metadata:
     name: whereami-ingress
     namespace: whereami
   spec:
     template:
       spec:
         backend:
           serviceName: whereami-mcs
           servicePort: 8080
   

   Essa configuração encaminha todo o tráfego para o MultiClusterService chamado whereami-mcs que existe no namespace whereami.

2. Implante o recurso MultiClusterIngress que se refere ao whereami-mcs como um back-end:

   kubectl apply -f mci.yaml
   

   A saída será assim:

   multiclusteringress.networking.gke.io/whereami-ingress created
   

   Observe que MultiClusterIngress tem o mesmo esquema que do Kubernetes Ingress. A semântica de recursos do Ingress também é a mesma, com exceção do campo backend.serviceName.

O campo backend.serviceName em um MultiClusterIngress que se refere a um MultiClusterService na API Fleet em vez de um serviço em um cluster do Kubernetes. Isso significa que qualquer uma das configurações do Ingress, como o encerramento do TLS, pode ser definida da mesma maneira.

Como validar um status de implantação bem-sucedido

A implantação de novos balanceadores de carga do Google Cloud pode levar vários minutos. A atualização dos balanceadores de carga que já existem é concluída mais rapidamente porque novos recursos não precisam ser implantados. O recurso MultiClusterIngress detalha os recursos básicos do Compute Engine que foram criados em nome do MultiClusterIngress.

1. Verifique se a implantação foi bem-sucedida:

   kubectl describe mci whereami-ingress -n whereami
   

   A saída será assim:

   Name:         whereami-ingress
   Namespace:    whereami
   Labels:       <none>
   Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"whereami-ingress","namespace":"whe...
   API Version:  networking.gke.io/v1
   Kind:         MultiClusterIngress
   Metadata:
     Creation Timestamp:  2020-04-10T23:35:10Z
     Finalizers:
       mci.finalizer.networking.gke.io
     Generation:        2
     Resource Version:  26458887
     Self Link:         /apis/networking.gke.io/v1/namespaces/whereami/multiclusteringresses/whereami-ingress
     UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
   Spec:
     Template:
       Spec:
         Backend:
           Service Name:  whereami-mcs
           Service Port:  8080
   Status:
     Cloud Resources:
       Backend Services:
         mci-8se3df-8080-whereami-whereami-mcs
       Firewalls:
         mci-8se3df-default-l7
       Forwarding Rules:
         mci-8se3df-fw-whereami-whereami-ingress
       Health Checks:
         mci-8se3df-8080-whereami-whereami-mcs
       Network Endpoint Groups:
         zones/europe-west1-b/networkEndpointGroups/k8s1-e4adffe6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-88670678
         zones/us-central1-b/networkEndpointGroups/k8s1-a6b112b6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-609ab6c6
       Target Proxies:
         mci-8se3df-whereami-whereami-ingress
       URL Map:  mci-8se3df-whereami-whereami-ingress
     VIP:        34.98.102.37
   Events:
     Type    Reason  Age                    From                              Message
     ----    ------  ----                   ----                              -------
     Normal  ADD     3m35s                  multi-cluster-ingress-controller  whereami/whereami-ingress
     Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  whereami/whereami-ingress
   

   Há vários campos que indicam o status dessa implantação do Ingress:

   • Events é o primeiro lugar para procurar. Se ocorrer um erro, ele será listado aqui.

   • Cloud Resource lista os recursos do Compute Engine, como regras de encaminhamento, serviços de back-end e regras de firewall que foram criados pelo Multi Cluster Ingress Console. Se eles não estiverem listados, significa que ainda não foram criados. Inspecione recursos individuais do Compute Engine com o console ou o comando gcloud para receber o status.

   • VIP lista um endereço IP quando ele é alocado. Observe que o balanceador de carga ainda não está processando o tráfego, embora o VIP exista. Se você não vir um VIP após alguns minutos ou se o balanceador de carga não disponibilizar uma resposta 200 em 10 minutos, consulte Solução de problemas e operações.

   Se os eventos de saída forem Normal, a implantação do MultiClusterIngress provavelmente será bem-sucedida, mas a única maneira de determinar se o caminho de tráfego completo é funcional é testá-lo.

2. Valide se o aplicativo está sendo exibido no VIP com o endpoint /ping:

   curl INGRESS_VIP/ping
   

   Substitua INGRESS_VIP pelo endereço IP virtual (VIP, na sigla em inglês).

   A saída será assim:

   {
   "cluster_name": "gke-us",
   "host_header": "34.120.175.141",
   "pod_name": "whereami-deployment-954cbf78-mtlpf",
   "pod_name_emoji": "😎",
   "project_id": "my-project",
   "timestamp": "2021-11-29T17:01:59",
   "zone": "us-central1-b"
   }
   

   A saída deve indicar a região e o back-end do aplicativo.

3. Também é possível acessar o URL http://INGRESS_VIP no seu navegador para ver uma versão gráfica do aplicativo que mostra a região de origem.

   O cluster que recebe o tráfego encaminhado depende do seu local. O GCLB foi projetado para encaminhar o tráfego do cliente para o back-end mais próximo disponível com capacidade.

Especificações de recursos

Especificação MultiClusterService

A definição MultiClusterService consiste em duas partes:

1. Uma seção template que define o serviço a ser criado nos clusters do Kubernetes. Embora a seção template contenha campos aceitos em um serviço típico, há apenas dois campos compatíveis em MultiClusterService: selector e ports. Os outros campos serão ignorados.

2. Uma seção clusters opcional que define quais clusters recebem tráfego e as propriedades de balanceamento de carga de cada cluster. Se nenhuma seção clusters for especificada ou se nenhum cluster estiver listado, todos os clusters serão usados por padrão.

O manifesto a seguir descreve um MultiClusterService padrão:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      selector:
        app: POD_LABEL
      ports:
      - name: web
        protocol: TCP
        port: PORT
        targetPort: TARGET_PORT

Substitua:

• NAME: o nome do MultiClusterService. Esse nome é indicado pelo campo serviceName nos recursos MultiClusterIngress;
• NAMESPACE: o namespace do Kubernetes em que o MultiClusterService está implantado. Ele precisa corresponder ao mesmo namespace que o MultiClusterIngress e os pods em todos os clusters na frota;
• POD_LABEL: o rótulo que determina quais pods são selecionados como back-ends para esse MultiClusterService em todos os clusters da frota;
• PORT: precisa corresponder à porta referenciada pelo MultiClusterIngress que referencia esse MultiClusterService.
• TARGET_PORT: a porta usada para enviar tráfego do GCLB para o pod. Um NEG é criado em cada cluster com essa porta como porta de veiculação.

Especificação MultiClusterIngress

O mci.yaml a seguir descreve o front-end do balanceador de carga:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      backend:
       serviceName: DEFAULT_SERVICE
       servicePort: PORT
      rules:
        - host: HOST_HEADER
          http:
            paths:
            - path: PATH
              backend:
                serviceName: SERVICE
                servicePort: PORT

Substitua:

• NAME: o nome do recurso ;MultiClusterIngress
• NAMESPACE: o namespace do Kubernetes em que o MultiClusterIngress está implantado. Ele precisa estar no mesmo namespace que o MultiClusterService e os pods em todos os clusters na frota;
• DEFAULT_SERVICE: atua como o back-end padrão de todo o tráfego que não corresponde a nenhuma regra de host ou caminho. Esse é um campo obrigatório, e um back-end padrão precisa ser especificado no MultiClusterIngress, mesmo que haja outras correspondências de host ou caminho configuradas;
• PORT: qualquer número de porta válido. Ele precisa corresponder ao campo port dos recursos do MultiClusterService;
• HOST_HEADER: corresponde ao tráfego pelo campo de cabeçalho do host HTTP. O campo host é opcional;
• PATH: corresponde ao tráfego pelo caminho do URL HTTP. O campo path é opcional;
• SERVICE: o nome de um MultiClusterService implantado no mesmo namespace e cluster de configuração que o MultiClusterIngress.

Recursos de entrada de vários clusters

Nesta seção, mostramos como configurar recursos adicionais de entrada de vários clusters.

Seleção de cluster

Por padrão, os serviços derivados da entrada de vários clusters são programados em cada cluster membro. No entanto, convém aplicar regras de entrada a clusters específicos. Alguns casos de uso incluem:

• aplicar a entrada de vários clusters a todos os clusters, menos ao cluster de configuração, para isolá-lo.
• migrar cargas de trabalho entre clusters de uma forma "azul/verde";
• rotear para back-ends de aplicativos que existem apenas em um subconjunto de clusters;
• usar um único VIP L7 para roteamento de host ou caminho para back-ends que residem em clusters diferentes.

A seleção de cluster permite selecionar clusters por região ou nome no objeto MultiClusterService. Isso controla quais clusters o MultiClusterIngress aponta e onde os Serviços derivados são programados. Os clusters na mesma frota e região não podem ter o mesmo nome para que eles possam ter referências exclusivas.

1. Abrir mcs.yaml

   apiVersion: networking.gke.io/v1
   kind: MultiClusterService
   metadata:
     name: whereami-mcs
     namespace: whereami
   spec:
     template:
       spec:
         selector:
           app: whereami
         ports:
         - name: web
           protocol: TCP
           port: 8080
           targetPort: 8080
   

   Essa especificação cria Serviços derivados em todos os clusters, o comportamento padrão.

2. Anexe as seguintes linhas na seção de clusters:

   apiVersion: networking.gke.io/v1
   kind: MultiClusterService
   metadata:
     name: whereami-mcs
     namespace: whereami
   spec:
     template:
       spec:
         selector:
           app: whereami
         ports:
         - name: web
           protocol: TCP
           port: 8080
           targetPort: 8080
     clusters:
     - link: "us-central1-b/gke-us"
     - link: "europe-west1-b/gke-eu"
   

   Este exemplo cria recursos de Serviços derivados apenas nos clusters gke-us e gke-eu. Você precisa selecionar clusters para aplicar seletivamente as regras de entrada. Se a seção "clusters" do MultiClusterService não for especificada ou se nenhum cluster estiver listado, ele será interpretado como o padrão "todos".

Suporte a HTTPS

O secret do Kubernetes é compatível com HTTPS. Antes de ativar o suporte a HTTPS, crie um endereço IP estático. Esse IP estático permite que HTTP e HTTPS compartilhem o mesmo endereço IP. Para mais informações, consulte Como criar um IP estático.

Depois de criar um endereço IP estático, crie um secret.

Observação: o certificado de chave pública precisa ser codificado em .PEM e corresponder à chave privada fornecida.

1. Crie um secret:

   kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE
   

   Substitua:

   • SECRET_NAME: pelo nome do secret;
   • PATH_TO_KEYFILE: pelo caminho do arquivo de chave TLS;
   • PATH_TO_CERTFILE: pelo caminho para o arquivo de certificado TLS.

2. Atualize o arquivo mci.yaml com o nome do secret:

   apiVersion: networking.gke.io/v1
   kind: MultiClusterIngress
   metadata:
     name: whereami-ingress
     namespace: whereami
     annotations:
       networking.gke.io/static-ip: STATIC_IP_ADDRESS
   spec:
     template:
       spec:
         backend:
           serviceName: whereami-mcs
           servicePort: 8080
         tls:
         - secretName: SECRET_NAME
   

   Substitua SECRET_NAME pelo nome do seu secret. O STATIC_IP_ADDRESS é o endereço IP ou o URL completo do endereço alocado na seção Como criar um IP estático.

3. Reimplante o recurso MultiClusterIngress:

   kubectl apply -f mci.yaml
   

   A saída será assim:

   multiclusteringress.networking.gke.io/whereami-ingress configured
   

Suporte a BackendConfig

A CRD BackendConfig a seguir permite personalizar configurações no recurso BackendService do Compute Engine:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: whereami-health-check-cfg
  namespace: whereami
spec:
  healthCheck:
    checkIntervalSec: [int]
    timeoutSec: [int]
    healthyThreshold: [int]
    unhealthyThreshold: [int]
    type: [HTTP | HTTPS | HTTP2 | TCP]
    port: [int]
    requestPath: [string]
  timeoutSec: [int]
  connectionDraining:
    drainingTimeoutSec: [int]
  sessionAffinity:
    affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
    affinityCookieTtlSec: [int]
  cdn:
    enabled: [bool]
    cachePolicy:
      includeHost: [bool]
      includeQueryString: [bool]
      includeProtocol: [bool]
      queryStringBlacklist: [string list]
      queryStringWhitelist: [string list]
  securityPolicy:
    name: ca-how-to-security-policy
  logging:
    enable: [bool]
    sampleRate: [float]
  iap:
    enabled: [bool]
    oauthclientCredentials:
      secretName: [string]

Para usar o BackendConfig, anexe-o ao recurso MultiClusterService usando uma anotação:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
  annotations:
    cloud.google.com/backend-config: '{"ports": {"8080":"whereami-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: whereami
     ports:
     - name: web
       protocol: TCP
       port: 8080
       targetPort: 8080

Para mais informações sobre a semântica do BackendConfig, consulte Como associar uma porta de serviço a um BackendConfig.

Suporte ao gRPC

A configuração de aplicativos gRPC na Entrada de vários clusters requer uma configuração muito específica. Veja algumas dicas para garantir que seu balanceador de carga esteja configurado corretamente:

1. Verifique se o tráfego do balanceador de carga para o aplicativo é HTTP/2. Use protocolos de aplicativo para configurar isso.
2. Verifique se o aplicativo está configurado corretamente no SSL, já que esse é um requisito de HTTP/2. É permitido o uso de certificados autoassinados.
3. Desative o mTLS no aplicativo, já que o mTLS não é compatível com os balanceadores de carga externos L7.

Ciclo de vida dos recursos

Alterações de configuração

Os recursos MultiClusterIngress e MultiClusterService se comportam como objetos padrão do Kubernetes. Por isso, as alterações feitas nos objetos são refletidas de maneira assíncrona no sistema. Qualquer alteração que resulte em uma configuração inválida faz com que os objetos associados do Google Cloud permaneçam inalterados e gerem um erro no stream de eventos do objeto. Os erros associados à configuração serão informados como eventos.

Como gerenciar recursos do Kubernetes

A exclusão do objeto do Ingress desativa o balanceador de carga HTTP(S) para que o tráfego não seja mais encaminhado para qualquer MultiClusterService definido.

A exclusão de MultiClusterService remove os serviços derivados associados em cada um dos clusters.

Como gerenciar clusters

O conjunto de clusters segmentados pelo balanceador de carga pode ser alterado adicionando ou removendo clusters da frota.

Por exemplo, para remover o cluster gke-eu como back-end de uma entrada, execute:

gcloud container fleet memberships unregister CLUSTER_NAME \
  --gke-uri=URI

Substitua:

• CLUSTER_NAME: o nome do cluster.
• URI: o URI do cluster do GKE.

Para adicionar um cluster na Europa, execute:

gcloud container fleet memberships register europe-cluster \
  --context=europe-cluster --enable-workload-identity

Saiba mais sobre as opções de registro de cluster em Registrar um cluster do GKE.

Registrar ou cancelar o registro de um cluster altera o status dele como um back-end para todas as entradas. Cancelar o registro do cluster gke-eu o remove como um back-end disponível para todos os Ingresses criados. O inverso é verdadeiro para registrar um novo cluster.

Observação: se você quiser excluir um cluster de membro da frota, cancele o registro do cluster antes de excluí-lo. Se isso não for feito, é possível resultar em um comportamento inesperado.

Como desativar a entrada de vários clusters

Antes de desativar a Entrada de vários clusters, primeiro exclua os recursos MultiClusterIngress e MultiClusterService e verifique se os recursos de rede associados foram excluídos.

Em seguida, para desativar a Entrada de vários clusters, use o seguinte comando:

gcloud container fleet ingress disable

Se você não excluir os recursos MultiClusterIngress e MultiClusterService antes de desativar o Ingress de vários clusters, talvez encontre um erro semelhante a este:

Feature has associated resources that should be cleaned up before deletion.

Se você quiser forçar a desativação da Entrada de vários clusters, use o seguinte comando:

gcloud container fleet ingress disable --force

Observação: a desativação forçada pode resultar em um comportamento inesperado. Não é recomendável forçar a desativação em ambientes de produção.

Anotações

As anotações a seguir são compatíveis com os recursos MultiClusterIngress e MultiClusterService.

Anotações MultiClusterIngress

Anotação	Descrição
networking.gke.io/frontend-config	Referencia um recurso BackendConfig no mesmo namespace que o recurso MultiClusterIngress.
networking.gke.io/static-ip	Refere-se ao endereço IP literal de um IP estático global.
networking.gke.io/pre-shared-certs	Refere-se a um recurso SSLCertificate global.

Anotações MultiClusterService

Anotação	Descrição
networking.gke.io/app-protocols	Use essa anotação para definir o protocolo de comunicação entre o balanceador de carga e o aplicativo. Os protocolos possíveis são HTTP, HTTPS e HTTP/2. Consulte HTTPS entre o balanceador de carga e o aplicativo e HTTP/2 para balanceamento de carga com Entrada.
cloud.google.com/backend-config	Use essa anotação para configurar o serviço de back-end associado a um servicePort. Para mais informações, consulte Configuração de entrada.

Políticas de SSL e redirecionamentos HTTPS

É possível usar o recurso FrontendConfig para configurar políticas de SSL e redirecionamentos HTTPS. As políticas de SSL permitem especificar quais conjuntos de criptografia e versões de TLS são aceitos pelo balanceador de carga. Os redirecionamentos HTTPS permitem aplicar o redirecionamento de HTTP ou da porta 80 para HTTPS ou para a porta 443. As etapas a seguir configuram uma política de SSL e o redirecionamento HTTPS juntos. Observe que eles também podem ser configurados de forma independente.

1. Crie uma política de SSL que recuse solicitações usando uma versão anterior à TLS v1.2.

   gcloud compute ssl-policies create tls-12-policy \
    --profile MODERN \
    --min-tls-version 1.2 \
    --project=PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto em que os clusters do GKE estiverem em execução.

2. Visualize sua política para garantir que ela foi criada.

   gcloud compute ssl-policies list --project=PROJECT_ID
   

   O resultado será assim:

   NAME           PROFILE  MIN_TLS_VERSION
   tls-12-policy  MODERN   TLS_1_2
   

3. Crie um certificado para foo.example.com como no exemplo. Quando você tiver o key.pem e o cert.pem, armazene essas credenciais como um secret que será referenciado pelo recurso MultiClusterIngress.

   kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem
   

4. Salve o seguinte recurso FrontendConfig como frontendconfig.yaml. Consulte Como configurar recursos do front-end para mais informações sobre os campos compatíveis em um FrontendConfig.

   apiVersion: networking.gke.io/v1beta1
   kind: FrontendConfig
   metadata:
     name: frontend-redirect-tls-policy
     namespace: whereami
   spec:
     sslPolicy: tls-12-policy
     redirectToHttps:
       enabled: true
   

   Esse FrontendConfig ativará redirecionamentos HTTPS e uma política de SSL que impõe uma versão mínima do TLS de 1.2.

5. Implantar o frontendconfig.yaml no cluster de configuração.

   kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER
   

   Substitua MCI_CONFIG_CLUSTER pelo nome do cluster de configuração.

6. Salve o seguinte MultiClusterIngress como mci-frontendconfig.yaml.

   apiVersion: networking.gke.io/v1
   kind: MultiClusterIngress
   metadata:
     name: foo-ingress
     namespace: whereami
     annotations:
       networking.gke.io/frontend-config: frontend-redirect-tls-policy
       networking.gke.io/static-ip: STATIC_IP_ADDRESS
   spec:
     template:
       spec:
         backend:
           serviceName: default-backend
           servicePort: 8080
         rules:
         - host: foo.example.com
           http:
             paths:
               - backend:
                   serviceName: whereami-mcs
                   servicePort: 8080
         tls:
         - secretName: SECRET_NAME
   

   • Substitua STATIC_IP_ADDRESS por um endereço IP global estático que você já tenha provisionado.
   • Substitua SECRET_NAME pelo secret em que o certificado foo.example.com está armazenado.

   Há dois requisitos ao ativar redirecionamentos HTTPS:

   • O TLS precisa estar ativado, seja por meio do campo spec.tls ou da anotação de certificado pré-compartilhada networking.gke.io/pre-shared-certs. O MultiClusterIngress não será implantado se os redirecionamentos HTTPS estiverem ativados, mas o HTTPS não estiver.
   • Um IP estático precisa ser referenciado por meio da anotação networking.gke.io/static-ip. Os IPs estáticos são necessários ao ativar HTTPS em um MultiClusterIngress.
   Observação: a implantação do aplicativo ou do MultiClusterService não é mostrada neste exemplo, mas também precisam ser criadas para que isso funcione.

7. Implante o MultiClusterIngress no cluster de configuração.

   kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
   

8. Aguarde um ou dois minutos e inspecione foo-ingress.

   kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER
   

   Uma saída bem-sucedida será parecida com esta:

   • O status Cloud Resources é preenchido com nomes de recursos.
   • O campo VIP é preenchido com o endereço IP do balanceador de carga

   Name:         foobar-ingress
   Namespace:    whereami
   
   ...
   
   Status:
     Cloud Resources:
       Backend Services:
         mci-otn9zt-8080-whereami-bar
         mci-otn9zt-8080-whereami-default-backend
         mci-otn9zt-8080-whereami-foo
       Firewalls:
         mci-otn9zt-default-l7
       Forwarding Rules:
         mci-otn9zt-fw-whereami-foobar-ingress
         mci-otn9zt-fws-whereami-foobar-ingress
       Health Checks:
         mci-otn9zt-8080-whereami-bar
         mci-otn9zt-8080-whereami-default-backend
         mci-otn9zt-8080-whereami-foo
       Network Endpoint Groups:
         zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d
         zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515
         zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de
         zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75
         zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739
         zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579
       Target Proxies:
         mci-otn9zt-whereami-foobar-ingress
         mci-otn9zt-whereami-foobar-ingress
       URL Map:  mci-otn9zt-rm-whereami-foobar-ingress
     VIP:        34.149.29.76
   Events:
     Type     Reason  Age                From                              Message
     ----     ------  ----               ----                              -------
     Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  whereami/foobar-ingress
   

9. Verifique se os redirecionamentos HTTPS funcionam corretamente enviando uma solicitação HTTP por meio de curl.

   curl VIP
   

   Substitua VIP pelo endereço IP do MultiClusterIngress.

   A saída deve mostrar que a solicitação foi redirecionada para a porta HTTPS, o que indica que os redirecionamentos estão funcionando corretamente.

10. Verifique se a política de TLS funciona corretamente enviando uma solicitação HTTPS usando a versão 1.1 do TLS. Como o DNS não está configurado para esse domínio, use a opção --resolve para instruir o curl a resolver o endereço IP diretamente.

    curl https://foo.example.com --resolve foo.example.com:443:VIP --cacert CERT_FILE -v
    

    Nesta etapa, é necessário o arquivo PEM de certificado usado para proteger o MultiClusterIngress. Uma saída bem-sucedida será semelhante a esta:

    ...
    * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: O=example; CN=foo.example.com
    *  start date: Sep  1 10:32:03 2021 GMT
    *  expire date: Aug 27 10:32:03 2022 GMT
    *  common name: foo.example.com (matched)
    *  issuer: O=example; CN=foo.example.com
    *  SSL certificate verify ok.
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x7fa10f00e400)
    > GET / HTTP/2
    > Host: foo.example.com
    > User-Agent: curl/7.64.1
    > Accept: */*
    >
    * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
    < HTTP/2 200
    < content-type: application/json
    < content-length: 308
    < access-control-allow-origin: *
    < server: Werkzeug/1.0.1 Python/3.8.6
    < date: Wed, 01 Sep 2021 11:39:06 GMT
    < via: 1.1 google
    < alt-svc: clear
    <
    {"cluster_name":"gke-us","host_header":"foo.example.com","metadata":"foo","node_name":"gke-gke-us-default-pool-22cb07b1-r5r0.c.mark-church-project.internal","pod_name":"foo-75ccd9c96d-dkg8t","pod_name_emoji":"👞","project_id":"mark-church-project","timestamp":"2021-09-01T11:39:06","zone":"us-central1-b"}
    * Connection #0 to host foo.example.com left intact
    * Closing connection 0
    

    O código de resposta é 200 e o TLSv1.2 está sendo usado, o que indica que tudo está funcionando corretamente.

    Em seguida, tente verificar se a política de SSL aplica a versão correta do TLS tentando se conectar com o TLS 1.1. Sua política de SSL precisa ser configurada para uma versão mínima de 1.2 para que esta etapa funcione.

11. Envie a mesma solicitação da etapa anterior, mas aplique uma versão TLS de 1.1.

    curl https://foo.example.com --resolve foo.example.com:443:VIP -v \
      --cacert CERT_FILE \
      --tls-max 1.1
    

    Uma saída bem-sucedida será semelhante a esta:

    * Added foo.example.com:443:34.149.29.76 to DNS cache
    * Hostname foo.example.com was found in DNS cache
    *   Trying 34.149.29.76...
    * TCP_NODELAY set
    * Connected to foo.example.com (34.149.29.76) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: cert.pem
      CApath: none
    * TLSv1.1 (OUT), TLS handshake, Client hello (1):
    * TLSv1.1 (IN), TLS alert, protocol version (582):
    * error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
    * Closing connection 0
    curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
    

    A falha na conclusão do handshake TLS indica que a política de SSL bloqueou o TLS 1.1.

Como criar um IP estático

1. Aloque um IP estático:

   gcloud compute addresses create ADDRESS_NAME --global
   

   Substitua ADDRESS_NAME pelo nome do IP estático a ser alocado.

   A saída contém o URL completo do endereço que você criou, semelhante ao seguinte:

   Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME].
   

2. Veja o endereço IP que você acabou de criar:

   gcloud compute addresses list
   

   A saída será assim:

   NAME          ADDRESS/RANGE  TYPE      STATUS
   ADDRESS_NAME  STATIC_IP_ADDRESS  EXTERNAL  RESERVED
   

   Esta saída inclui:

   • O ADDRESS_NAME que você definiu.
   • O STATIC_IP_ADDRESS alocado.

3. Atualize o arquivo mci.yaml com o IP estático:

   apiVersion: networking.gke.io/v1
   kind: MultiClusterIngress
   metadata:
     name: whereami-ingress
     namespace: whereami
     annotations:
       networking.gke.io/static-ip: STATIC_IP_ADDRESS
   spec:
     template:
       spec:
         backend:
           serviceName: whereami-mcs
           servicePort: 8080
   

   Substitua STATIC_IP_ADDRESS por:

   • O endereço IP alocado, semelhante a: 34.102.201.47
   • O URL completo do endereço que você criou, semelhante a: "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"

   STATIC_IP_ADDRESS não é o nome do recurso (ADDRESS_NAME).

4. Reimplante o recurso MultiClusterIngress:

   kubectl apply -f mci.yaml
   

   A saída será assim:

   multiclusteringress.networking.gke.io/whereami-ingress configured
   

5. Siga as etapas em Como validar um status de implantação bem-sucedido para verificar se a implantação está sendo veiculada no STATIC_IP_ADDRESS.

Certificados pré-compartilhados

Os certificados pré-compartilhados são enviados ao Google Cloud e podem ser usados pelo balanceador de carga para o encerramento de TLS em vez de certificados armazenados em secrets do Kubernetes. Esses certificados são enviados do GKE para o Google Cloud fora de banda e referenciados por um recurso MultiClusterIngress. Vários certificados, seja por certificados pré-compartilhados ou secrets do Kubernetes, também são compatíveis.

Usar os certificados na entrada de vários clusters requer a anotação networking.gke.io/pre-shared-certs e os nomes dos certificados. Quando vários certificados são especificados para um determinado MultiClusterIngress, um pedido predeterminado define qual certificado é apresentado ao cliente.

Liste os certificados SSL disponíveis executando:

gcloud compute ssl-certificates list

O exemplo a seguir descreve o tráfego de clientes para um dos hosts especificados que corresponde ao nome comum dos certificados pré-compartilhados. Assim, o certificado que corresponde ao nome de domínio será apresentado.

kind: MultiClusterIngress
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
  template:
    spec:
      rules:
      - host: my-domain1.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain1-svc
              servicePort: 443
      - host: my-domain2.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain2-svc
              servicePort: 443

Certificados gerenciados pelo Google

Os certificados gerenciados pelo Google são compatíveis com os recursos MultiClusterIngress pela anotação networking.gke.io/pre-shared-certs. A entrada de vários clusters suporta o anexo de certificados gerenciados pelo Google a um recurso MultiClusterIngress. No entanto, ao contrário da entrada de cluster único, a geração declarativa de um recurso ManagedCertificate do Kubernetes não é suportada nos recursos MultiClusterIngress. A criação original do certificado gerenciado pelo Google precisa ser feita diretamente na API compute ssl-certificates create antes de anexá-lo a uma MultiClusterIngress. Isso pode ser feito seguindo estas etapas:

1. Crie um certificado gerenciado pelo Google como na etapa 1 aqui. Não passe para a etapa 2, porque o Ingress de vários clusters anexará esse certificado para você.

   gcloud compute ssl-certificates create my-google-managed-cert \
       --domains=my-domain.gcp.com \
       --global
   

2. Faça referência ao nome do certificado no MultiClusterIngress usando a anotação networking.gke.io/pre-shared-certs.

   kind: MultiClusterIngress
   metadata:
   name: shopping-service
   namespace: whereami
   annotations:
     networking.gke.io/pre-shared-certs: "my-google-managed-cert"
   spec:
   template:
     spec:
       rules:
       - host: my-domain.gcp.com
         http:
           paths:
           - backend:
               serviceName: my-domain-svc
               servicePort: 8080
   

O manifesto anterior anexa o certificado ao MultiClusterIngress para que ele possa encerrar o tráfego dos clusters de back-end do GKE. O Google Cloud renovará automaticamente seu certificado antes da expiração. As renovações ocorrem de forma transparente e não exigem atualizações para a Entrada de vários clusters.

Protocolos de aplicativo

A conexão entre o proxy do balanceador de carga e seu aplicativo usa HTTP por padrão. Ao usar a anotação networking.gke.io/app-protocols, é possível configurar o balanceador de carga para usar HTTPS ou HTTP/2 ao encaminhar solicitações para o aplicativo. No campo annotation do exemplo a seguir, http2 refere-se ao nome da porta MultiClusterService e HTTP2 refere-se ao protocolo que o balanceador de carga usa.

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
  template:
    spec:
      ports:
      - port: 443
        name: http2

BackendConfig

Consulte a seção acima sobre como configurar a anotação.

A seguir

• Leia a visão geral da rede GKE.
• Saiba mais sobre como configurar o balanceamento de carga HTTP com a Entrada.
• Implemente a entrada em vários clusters com HTTPS de ponta a ponta.