Implementar a entrada em vários clusters

Esta página mostra como implementar um Ingress que publica uma aplicação em vários clusters do GKE. Para saber mais sobre a entrada em vários clusters, consulte o artigo Entrada em vários clusters.

Para uma comparação detalhada entre o Multi Cluster Ingress (MCI), o Multi-cluster Gateway (MCG) e o balanceador de carga com grupos de pontos finais de rede autónomos (LB e NEGs autónomos), consulte o artigo Escolha a sua API de balanceamento de carga de vários clusters para o GKE.

Tutorial de implementação

Nas tarefas seguintes, vai implementar uma app fictícia denominada whereami e um MultiClusterIngress em dois clusters. O Ingress fornece um endereço IP virtual (VIP) partilhado para as implementações de apps.

Esta página baseia-se no trabalho realizado em Configurar a entrada em vários clusters, onde criou e registou dois clusters. Confirme que tem dois clusters que também estão registados numa frota:

gcloud container clusters list

O resultado é semelhante ao seguinte:

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

Criar o espaço de nomes

Uma vez que as frotas têm a propriedade de igualdade de namespace, recomendamos que coordene a criação e a gestão de namespaces em todos os clusters para que os namespaces idênticos sejam detidos e geridos pelo mesmo grupo. Pode criar namespaces por equipa, por ambiente, por aplicação ou por componente da aplicação. Os espaços de nomes podem ser tão detalhados quanto necessário, desde que um espaço de nomes ns1 num cluster tenha o mesmo significado e utilização que ns1 noutro cluster.

Neste exemplo, cria um whereami espaço de nomes para cada aplicação em cada cluster.

  1. Crie um ficheiro denominado namespace.yaml com o seguinte conteúdo:

    apiVersion: v1
kind: Namespace
metadata:
  name: whereami

  2. Mude para o contexto gke-us:

    kubectl config use-context gke-us

  3. Crie o espaço de nomes:

    kubectl apply -f namespace.yaml

  4. Mude para o contexto gke-eu:

    kubectl config use-context gke-eu

  5. Crie o espaço de nomes:

    kubectl apply -f namespace.yaml

    O resultado é semelhante ao seguinte:

    namespace/whereami created

Implementar a app

  1. Crie um ficheiro denominado deploy.yaml com 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
        ports:
        - containerPort: 8080

  2. Mude para o contexto gke-us:

    kubectl config use-context gke-us

  3. Implemente a app whereami:

    kubectl apply -f deploy.yaml

  4. Mude para o contexto gke-eu:

    kubectl config use-context gke-eu

  5. Implemente a app whereami:

    kubectl apply -f deploy.yaml

  6. Verifique se a app whereami foi implementada com êxito em cada cluster:

    kubectl get deployment --namespace whereami

    O resultado deve ser semelhante ao seguinte em ambos os clusters:

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

Implementação através do cluster de configuração

Agora que a aplicação está implementada no gke-us e no gke-eu, vai implementar um equilibrador de carga através da implementação de recursos MultiClusterIngress e MultiClusterService no cluster de configuração. Estes são os equivalentes de vários clusters dos recursos Ingress e Service.

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

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

    kubectl config use-context gke-us

MultiClusterService

  1. Crie um ficheiro denominado mcs.yaml com 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. Implemente o recurso MultiClusterService que corresponde à app whereami:

    kubectl apply -f mcs.yaml

  3. Verifique se o recurso whereami-mcs foi implementado com êxito no cluster de configuração:

    kubectl get mcs -n whereami

    O resultado é semelhante ao seguinte:

    NAME       AGE
whereami-mcs   9m26s

    Isto MultiClusterService cria um serviço sem cabeçalho derivado em todos os clusters que correspondem aos pods com app: whereami. Pode ver que existe um no gke-usclusterkubectl get service -n whereami.

    O resultado é semelhante ao seguinte:

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

Também vai existir um serviço sem interface semelhante no gke-eu. Estes serviços locais são usados para selecionar dinamicamente pontos finais de pods para programar o balanceador de carga de entrada global com back-ends.

MultiClusterIngress

  1. Crie um ficheiro denominado mci.yaml com 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

    Tenha em atenção que esta configuração encaminha todo o tráfego para o MultiClusterService denominado whereami-mcs que existe no espaço de nomes whereami.

  2. Implemente o recurso MultiClusterIngress que referencia whereami-mcs como um back-end:

    kubectl apply -f mci.yaml

    O resultado é semelhante ao seguinte:

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

    Tenha em atenção que MultiClusterIngress tem o mesmo esquema que o Kubernetes Ingress. A semântica do recurso Ingress também é a mesma, com exceção do campo backend.serviceName.

O campo backend.serviceName num MultiClusterIngress faz referência a um MultiClusterService na API Fleet, em vez de um serviço num cluster do Kubernetes. Isto significa que qualquer uma das definições do Ingress, como a terminação TLS, pode ser configurada da mesma forma.

Validar um estado de implementação bem-sucedido

Google Cloud A implementação do equilibrador de carga pode demorar vários minutos para novos equilibradores de carga. A atualização dos balanceadores de carga existentes é concluída mais rapidamente porque não é necessário implementar novos recursos. Os MultiClusterIngress detalham os recursos subjacentes do Compute Engine que foram criados em nome do MultiClusterIngress.

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

    kubectl describe mci whereami-ingress -n whereami

    O resultado é semelhante ao seguinte:

    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

    Existem vários campos que indicam o estado desta implementação do Ingress:

    • Events é o primeiro lugar a procurar. Se tiver ocorrido um erro, este é apresentado aqui.

    • Cloud Resourceapresenta os recursos do Compute Engine, como regras de encaminhamento, serviços de back-end e regras de firewall, que foram criados pelo controlador de entrada de vários clusters. Se não forem apresentados, significa que ainda não foram criados. Pode inspecionar recursos individuais do Compute Engine com a consola ou o comando gcloud para obter o respetivo estado.

    • VIP apresenta um endereço IP quando um foi atribuído. Tenha em atenção que o equilibrador de carga pode ainda não estar a processar tráfego, mesmo que o VIP exista. Se não vir um VIP após alguns minutos ou se o balanceador de carga não estiver a fornecer uma resposta 200 no prazo de 10 minutos, consulte a secção Resolução de problemas e operações.

    Se os eventos de saída forem Normal, é provável que a implementação de MultiClusterIngress seja bem-sucedida, mas a única forma de determinar se o caminho de tráfego completo está funcional é testá-lo.

  2. Valide se a aplicação está a ser publicada no VIP com o ponto final /ping:

    curl INGRESS_VIP/ping

    Substitua INGRESS_VIP pelo endereço IP virtual (VIP).

    O resultado é semelhante ao seguinte:

    {
"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"
}

    O resultado deve indicar a região e o back-end da aplicação.

  3. Também pode aceder ao http://INGRESS_VIPURL no seu navegador para ver uma versão gráfica da aplicação que mostra a região a partir da qual está a ser publicada.

    O cluster para o qual o tráfego é encaminhado depende da sua localização. O GCLB foi concebido para encaminhar o tráfego do cliente para o back-end disponível mais próximo com capacidade.

Especificações dos recursos

Especificação MultiClusterService

A definição MultiClusterService é composta por duas partes:

  1. Uma secção template que define o serviço a ser criado nos clusters do Kubernetes. Tenha em atenção que, embora a secção template contenha campos suportados num serviço típico, existem apenas dois campos suportados num MultiClusterService: selector e ports. Os outros campos são ignorados.

  2. Uma secção clusters opcional que define que clusters recebem tráfego e as propriedades de equilíbrio de carga para cada cluster. Se não for especificada nenhuma secção clusters ou se não forem indicados clusters, todos os clusters são usados por predefinição.

O manifesto seguinte 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 o seguinte:

  • NAME: o nome do MultiClusterService. Este nome é referenciado pelo campo serviceName nos recursos MultiClusterIngress.
  • NAMESPACE: o namespace do Kubernetes no qual o MultiClusterService está implementado. Tem de corresponder ao mesmo espaço de nomes que o MultiClusterIngress e os pods em todos os clusters na frota.
  • POD_LABEL: a etiqueta que determina que pods são selecionados como back-ends para este MultiClusterService em todos os clusters na frota.
  • PORT: tem de corresponder à porta referenciada pelo elemento MultiClusterIngress que faz referência a este MultiClusterService.
  • TARGET_PORT: a porta usada para enviar tráfego para o pod a partir do GCLB. É criado um NEG em cada cluster com esta porta como porta de publicação.

Especificação MultiClusterIngress

A seguinte mci.yaml descreve a interface 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 o seguinte:

  • NAME: o nome do recurso MultiClusterIngress.
  • NAMESPACE: o namespace do Kubernetes no qual o MultiClusterIngress está implementado. Tem de estar no mesmo espaço de nomes que o MultiClusterService e os pods em todos os clusters da frota.
  • DEFAULT_SERVICE: atua como o back-end predefinido para todo o tráfego que não corresponda a nenhuma regra de anfitrião ou caminho. Este é um campo obrigatório e tem de especificar um back-end predefinido no MultiClusterIngress, mesmo que existam outras correspondências de anfitrião ou caminho configuradas.
  • PORT: qualquer número de porta válido. Tem de corresponder ao campo port dos recursos MultiClusterService.
  • HOST_HEADER: corresponde ao tráfego pelo campo de cabeçalho do anfitrião 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 implementado no mesmo espaço de nomes e cluster de configuração que este MultiClusterIngress.

Funcionalidades da entrada em vários clusters

Esta secção mostra como configurar funcionalidades adicionais do Multi Cluster Ingress.

Seleção de clusters

Por predefinição, os serviços derivados da entrada em vários clusters são agendados em todos os clusters membros. No entanto, pode querer aplicar regras de entrada a clusters específicos. Seguem-se alguns exemplos de utilização:

  • Aplicar a entrada em vários clusters a todos os clusters, exceto ao cluster de configuração, para isolar o cluster de configuração.
  • Migrar cargas de trabalho entre clusters de forma azul-verde.
  • Encaminhamento para backends de aplicações que só existem num subconjunto de clusters.
  • Usar um único VIP de nível 7 para o encaminhamento de anfitriões ou caminhos para back-ends que residem em clusters diferentes.

A seleção de clusters permite-lhe selecionar clusters por região ou nome no objeto MultiClusterService. Isto controla a que clusters o seu MultiClusterIngress está a apontar e onde os serviços derivados estão agendados. Os clusters na mesma frota e região não devem ter o mesmo nome para que seja possível fazer referência aos clusters de forma exclusiva.

  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

    Esta especificação cria serviços derivados em todos os clusters, o comportamento predefinido.

  2. Acrescente as seguintes linhas na secçã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ço derivado apenas nos clusters gke-us e gke-eu. Tem de selecionar clusters para aplicar seletivamente regras de entrada. Se a secção "clusters" do elemento MultiClusterService não for especificada ou não forem apresentados clusters, é interpretada como os clusters "todos" predefinidos.

Suporte de HTTPS

O Kubernetes Secret suporta HTTPS. Antes de ativar o suporte de HTTPS, tem de criar um endereço IP estático. Este IP estático permite que o HTTP e o HTTPS partilhem o mesmo endereço IP. Para mais informações, consulte o artigo Criar um IP estático.

Depois de criar um endereço IP estático, pode criar um segredo.

  1. Crie um Secret:

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

    Substitua o seguinte:

    • SECRET_NAME com o nome do seu segredo.
    • PATH_TO_KEYFILE com o caminho para o ficheiro de chave TLS.
    • PATH_TO_CERTFILE com o caminho para o ficheiro do certificado TLS.

  2. Atualize o ficheiro mci.yaml com o nome do segredo:

    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 segredo. O STATIC_IP_ADDRESS é o endereço IP ou o URL completo do endereço que atribuiu na secção Criar um IP estático.

  3. Volte a implementar o recurso MultiClusterIngress:

    kubectl apply -f mci.yaml

    O resultado é semelhante ao seguinte:

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

Suporte de BackendConfig

O CRD BackendConfig seguinte permite-lhe personalizar as definiçõ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 o artigo Associar uma porta de serviço a um BackendConfig.

Compatibilidade com gRPC

A configuração de aplicações gRPC no Multi Cluster Ingress requer uma configuração muito específica. Seguem-se algumas sugestões para se certificar de que o balanceador de carga está configurado corretamente:

  1. Certifique-se de que o tráfego do balanceador de carga para a sua aplicação é HTTP/2. Use protocolos de aplicação para configurar esta opção.
  2. Certifique-se de que a sua aplicação está configurada corretamente para SSL, uma vez que este é um requisito do HTTP/2. Tenha em atenção que a utilização de certificados autoassinados é aceitável.
  3. Tem de desativar o mTLS na sua aplicação porque o mTLS não é suportado para equilibradores de carga externos de nível 7.

Ciclo de vida dos recursos

Alterações de configuração

Os recursos MultiClusterIngress e MultiClusterService comportam-se como objetos Kubernetes padrão, pelo que as alterações aos objetos são refletidas de forma assíncrona no sistema. Todas as alterações que resultem numa configuração inválida fazem com que os objetos Google Cloud associados permaneçam inalterados e gerem um erro na stream de eventos de objetos. Os erros associados à configuração são comunicados como eventos.

Gerir recursos do Kubernetes

A eliminação do objeto Ingress desativa o balanceador de carga HTTP(S), pelo que o tráfego deixa de ser encaminhado para qualquer MultiClusterService definido.

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

Gerir clusters

Pode alterar o conjunto de clusters segmentados pelo equilibrador de carga adicionando ou removendo clusters da frota.

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

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

Substitua o seguinte:

  • 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

Pode saber mais sobre as opções de registo de clusters em Registe um cluster do GKE.

Tenha em atenção que o registo ou a anulação do registo de um cluster altera o respetivo estado como back-end para todos os Ingresses. A anulação do registo do cluster gke-eu remove-o como um back-end disponível para todos os Ingresses que criar. O inverso é verdadeiro para o registo de um novo cluster.

Desativar a entrada em vários clusters

Antes de desativar o Multi Cluster Ingress, tem de garantir que elimina primeiro os recursos MultiClusterIngress e MultiClusterService e verificar se os recursos de rede associados foram eliminados.

Em seguida, para desativar o Multi Cluster Ingress, use o seguinte comando:

gcloud container fleet ingress disable

Se não eliminar os recursos MultiClusterIngress e MultiClusterService antes de desativar o Multi Cluster Ingress, pode ocorrer um erro semelhante ao seguinte:

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

Se quiser forçar a desativação do Multi Cluster Ingress, use o seguinte comando:

gcloud container fleet ingress disable --force

Notas

As seguintes anotações são suportadas nos recursos MultiClusterIngress e MultiClusterService.

Anotações MultiClusterIngress

Anotação Descrição
networking.gke.io/frontend-config Referencia um recurso FrontendConfig no mesmo espaço de nomes 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 esta anotação para definir o protocolo de comunicação entre o equilibrador de carga e a aplicação. Os protocolos possíveis são HTTP, HTTPS e HTTP/2. Consulte os artigos HTTPS entre o balanceador de carga e a sua aplicação e HTTP/2 para balanceamento de carga com a entrada.
cloud.google.com/backend-config Use esta anotação para configurar o serviço de back-end associado a um servicePort. Para mais informações, consulte o artigo Configuração de entrada.

Políticas de SSL e redirecionamentos HTTPS

Pode usar o recurso FrontendConfig para configurar políticas SSL e redirecionamentos HTTPS. As políticas SSL permitem-lhe especificar os conjuntos de cifras e as versões TLS aceites pelo equilibrador de carga. Os redirecionamentos HTTPS permitem-lhe aplicar o redirecionamento de HTTP ou da porta 80 para HTTPS ou para a porta 443. Os passos seguintes configuram uma política SSL e um redirecionamento HTTPS em conjunto. Tenha em atenção que também podem ser configuradas de forma independente.

  1. Crie uma política SSL que rejeite pedidos que usem uma versão inferior à 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 onde os seus clusters do GKE estão a ser executados.

  2. Veja a sua política para garantir que foi criada.

    gcloud compute ssl-policies list --project=PROJECT_ID

    O resultado é semelhante ao seguinte:

    NAME           PROFILE  MIN_TLS_VERSION
tls-12-policy  MODERN   TLS_1_2

  3. Crie um certificado para foo.example.com, como no exemplo. Depois de ter o key.peme o cert.pem, armazene estas credenciais como um segredo que será referenciado pelo recurso MultiClusterIngress.

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

  4. Guarde o seguinte recurso FrontendConfig como frontendconfig.yaml. Consulte o artigo Configurar recursos FrontendConfig para ver mais informações sobre os campos suportados num FrontendConfig.

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

    Esta FrontendConfig vai ativar os redirecionamentos HTTPS e uma política SSL que aplica uma versão mínima do TLS de 1.2.

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

    kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER

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

  6. Guarde o MultiClusterIngress seguinte 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 já tenha aprovisionado.
    • Substitua SECRET_NAME pelo Secret onde o seu certificado foo.example.com está armazenado.

    Existem dois requisitos quando ativa os redirecionamentos HTTPS:

    • O TLS tem de estar ativado através do campo spec.tls ou da anotação de certificado partilhado previamente networking.gke.io/pre-shared-certs. O MultiClusterIngress não é implementado se os redirecionamentos HTTPS estiverem ativados, mas o HTTPS não estiver.
    • Tem de fazer referência a um IP estático através da anotação networking.gke.io/static-ip. Os IPs estáticos são necessários quando ativa o HTTPS num MultiClusterIngress.

  7. Implemente 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

    Um resultado bem-sucedido é semelhante ao seguinte:

    • O estado Cloud Resources é preenchido com nomes de recursos
    • O campo VIP é preenchido com o endereço IP do equilibrador 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 um pedido HTTP através de curl.

    curl VIP

    Substitua VIP pelo endereço IP do MultiClusterIngress.

    O resultado deve mostrar que o pedido foi redirecionado para a porta HTTPS, o que indica que os redirecionamentos estão a funcionar corretamente.

  10. Verifique se a política de TLS funciona corretamente enviando um pedido HTTPS com a versão 1.1 do TLS. Uma vez que o DNS não está configurado para este domínio, use a opção --resolve para indicar ao curl que resolva o endereço IP diretamente.

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

    Este passo requer o ficheiro PEM do certificado usado para proteger o MultiClusterIngress. Um resultado bem-sucedido é semelhante ao seguinte:

    ...
* 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 está a ser usado o TLSv1.2, o que indica que tudo está a funcionar corretamente.

    Em seguida, pode verificar se a política SSL aplica a versão TLS correta tentando estabelecer ligação com o TLS 1.1. A sua política SSL tem de estar configurada para uma versão mínima de 1.2 para que este passo funcione.

  11. Envie o mesmo pedido do passo 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

    Um resultado bem-sucedido é semelhante ao seguinte:

    * 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 SSL bloqueou o TLS 1.1 com êxito.

Criar um IP estático

  1. Atribua um IP estático:

    gcloud compute addresses create ADDRESS_NAME --global

    Substitua ADDRESS_NAME pelo nome do IP estático a atribuir.

    A saída contém o URL completo da morada que 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 acabou de criar:

    gcloud compute addresses list

    O resultado é semelhante ao seguinte:

    NAME          ADDRESS/RANGE  TYPE      STATUS
ADDRESS_NAME  STATIC_IP_ADDRESS  EXTERNAL  RESERVED

    Este resultado inclui:

    • O ADDRESS_NAME que definiu.
    • O campo STATIC_IP_ADDRESS foi atribuído.

  3. Atualize o ficheiro 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 atribuído, semelhante a: 34.102.201.47
    • O URL completo do endereço que criou, semelhante a: "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"

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

  4. Volte a implementar o recurso MultiClusterIngress:

    kubectl apply -f mci.yaml

    O resultado é semelhante ao seguinte:

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

  5. Siga os passos em Validar um estado de implementação bem-sucedido para verificar se a implementação está a ser publicada no STATIC_IP_ADDRESS.

Certificados pré-partilhados

Os certificados partilhados previamente são certificados carregados para o Google Cloud que podem ser usados pelo balanceador de carga para a terminação TLS em vez de certificados armazenados em segredos do Kubernetes. Estes certificados são carregados fora da banda a partir do GKE para o Google Cloud e são referenciados por um recurso MultiClusterIngress. Também são suportados vários certificados, quer através de certificados pré-partilhados ou segredos do Kubernetes.

A utilização dos certificados na entrada em vários clusters requer a anotação networking.gke.io/pre-shared-certs e os nomes dos certificados. Quando são especificados vários certificados para um determinado MultiClusterIngress, uma ordem predeterminada rege o certificado apresentado ao cliente.

Pode listar os certificados SSL disponíveis executando o seguinte comando:

gcloud compute ssl-certificates list

O exemplo seguinte descreve o tráfego de clientes para um dos anfitriões especificados que corresponde ao nome comum dos certificados pré-partilhados, pelo que o respetivo certificado que corresponde ao nome do domínio é 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 geridos pela Google

Os certificados geridos pela Google são suportados em recursos MultiClusterIngress através da anotação networking.gke.io/pre-shared-certs. A entrada de vários clusters suporta a associação de certificados geridos pela 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 em recursos MultiClusterIngress. A criação original do certificado gerido pela Google tem de ser feita diretamente através da API compute ssl-certificates create antes de o poder anexar a um MultiClusterIngress. Pode fazê-lo seguindo estes passos:

  1. Crie um certificado gerido pela Google, conforme descrito no passo 1 aqui. Não avance para o passo 2, uma vez que a entrada em vários clusters anexa este certificado por si.

    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 seu 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 seu MultiClusterIngress para que possa terminar o tráfego para os seus clusters GKE de back-end. OGoogle Cloud renova automaticamente o seu certificado antes da expiração do certificado. As renovações ocorrem de forma transparente e não requerem atualizações ao Multi Cluster Ingress.

Protocolos de aplicação

A ligação do proxy do equilibrador de carga à sua aplicação usa HTTP por predefinição. Com a anotação networking.gke.io/app-protocols, pode configurar o balanceador de carga para usar HTTPS ou HTTP/2 quando encaminha pedidos para a sua aplicação. No campo annotation do exemplo seguinte, http2 refere-se ao nome da porta e HTTP2 refere-se ao protocolo que o equilibrador de carga usa.MultiClusterService

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 secção acima sobre como configurar a anotação.

O que se segue?