Implantar aplicativos Windows em Kubernetes gerenciados

Last reviewed 2024-08-14 UTC

Neste documento, descrevemos como implantar a arquitetura de referência em Gerenciar e dimensionar a rede de aplicativos Windows executados em Kubernetes gerenciados.

Estas instruções são destinadas a arquitetos de nuvem, administradores de rede e profissionais de TI responsáveis pelo design e gerenciamento de aplicativos Windows executados em clusters do Google Kubernetes Engine (GKE).

Arquitetura

O diagrama a seguir mostra a arquitetura de referência que você usa ao implantar aplicativos Windows executados em clusters gerenciados do GKE.

Conforme mostrado no diagrama anterior, uma seta representa o fluxo de trabalho para gerenciar a rede de aplicativos Windows executados no GKE usando gateways do Envoy e do Cloud Service Mesh. O cluster regional do GKE inclui pools de nós do Windows e do Linux. O Cloud Service Mesh cria e gerencia rotas de tráfego para os pods do Windows.

Objetivos

• Crie e configure um cluster do GKE para executar aplicativos do Windows e proxies do Envoy.
• Implante e verifique os aplicativos do Windows.
• Configure o Cloud Service Mesh como o plano de controle para os gateways do Envoy.
• Use a API Kubernetes Gateway para provisionar o balanceador de carga de aplicativo interno e expor os gateways do Envoy.
• Entenda as operações de implantação contínua que você criou.

Custos

A implantação dessa arquitetura usa os seguintes componentes faturáveis doGoogle Cloud:

• Cloud Load Balancing
• Google Kubernetes Engine
• Cloud Service Mesh

Ao concluir a implantação, exclua os recursos criados para evitar a continuidade do faturamento. Para mais informações, consulte Limpeza.

Antes de começar

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

3. Enable the Cloud Shell, and Cloud Service Mesh APIs.

   Enable the APIs

4. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   Se você estiver executando em um ambiente de nuvem privada virtual (VPC) compartilhada, também precisará seguir as instruções para criar manualmente a sub-rede somente proxy e a regra de firewall para as verificações de capacidade de resposta do Cloud Load Balancing.

   Criar um cluster do GKE

   Siga as etapas abaixo para criar um cluster do GKE. Você usa o cluster do GKE para conter e executar os aplicativos do Windows e os proxies do Envoy nesta implantação.

   1. No Cloud Shell, execute o seguinte comando da Google Cloud CLI para criar um cluster regional do GKE com um nó em cada uma das três regiões:

      gcloud container clusters create my-cluster
          --enable-ip-alias \
          --num-nodes=1 \
          --release-channel stable \
          --enable-dataplane-v2 \
          --region us-central1 \
          --scopes=cloud-platform \
          --gateway-api=standard
      

   2. Adicione o pool de nós do Windows ao cluster do GKE:

      gcloud container node-pools create win-pool \
          --cluster=my-cluster \
          --image-type=windows_ltsc_containerd \
          --no-enable-autoupgrade \
          --region=us-central1 \
          --num-nodes=1 \
          --machine-type=n1-standard-2 \
          --windows-os-version=ltsc2019
      

      Essa operação pode levar cerca de 20 minutos para ser concluída.

   3. Armazene o ID do projeto Google Cloud em uma variável de ambiente:

      export PROJECT_ID=$(gcloud config get project)
      

   4. Conecte-se ao cluster do GKE:

      gcloud container clusters get-credentials my-cluster --region us-central1
      

   5. Liste todos os nós no cluster do GKE:

      kubectl get nodes
      

      A saída vai mostrar três nós do Linux e três do Windows.

      Depois que o cluster do GKE estiver pronto, você poderá implantar dois aplicativos de teste baseados no Windows.

   Implantar dois aplicativos de teste

   Nesta seção, você vai implantar dois aplicativos de teste baseados no Windows. Os dois aplicativos de teste imprimem o nome do host em que o aplicativo é executado. Você também cria um serviço do Kubernetes para expor o aplicativo usando grupos de endpoints de rede (NEGs) autônomos.

   Ao implantar um aplicativo baseado no Windows e um serviço do Kubernetes em um cluster regional, um NEG é criado para cada zona em que o aplicativo é executado. Mais adiante, este guia de implantação explica como configurar essas NEGs como backends para serviços do Cloud Service Mesh.

   1. No Cloud Shell, aplique o seguinte arquivo YAML com kubectl para implantar o primeiro aplicativo de teste. Esse comando implanta três instâncias do aplicativo de teste, uma em cada zona regional.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: win-webserver-1
        name: win-webserver-1
      spec:
        replicas: 3
        selector:
          matchLabels:
            app: win-webserver-1
        template:
          metadata:
            labels:
              app: win-webserver-1
            name: win-webserver-1
          spec:
           containers:
            - name: windowswebserver
              image: k8s.gcr.io/e2e-test-images/agnhost:2.36
              command: ["/agnhost"]
              args: ["netexec", "--http-port", "80"]
           topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: kubernetes.io/hostname
              whenUnsatisfiable: DoNotSchedule
              labelSelector:
                matchLabels:
                  app: win-webserver-1
           nodeSelector:
            kubernetes.io/os: windows
      

   2. Aplique o serviço do Kubernetes correspondente e exponha-o com um NEG:

      apiVersion: v1
      kind: Service
      metadata:
        name: win-webserver-1
        annotations:
          cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}'
      spec:
        type: ClusterIP
        selector:
          app: win-webserver-1
        ports:
        - name: http
          protocol: TCP
          port: 80
          targetPort: 80
      

   3. Verificar a implantação:

      kubectl get pods
      

      A saída mostra que o aplicativo tem três pods do Windows em execução.

      NAME                               READY   STATUS    RESTARTS   AGE
      win-webserver-1-7bb4c57f6d-hnpgd   1/1     Running   0          5m58s
      win-webserver-1-7bb4c57f6d-rgqsb   1/1     Running   0          5m58s
      win-webserver-1-7bb4c57f6d-xp7ww   1/1     Running   0          5m58s
      

   4. Verifique se o serviço do Kubernetes foi criado:

      $ kubectl get svc
      

      A saída será assim:

      NAME              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
      kubernetes        ClusterIP   10.64.0.1            443/TCP   58m
      win-webserver-1   ClusterIP   10.64.6.20           80/TCP    3m35s
      

   5. Execute o comando describe para kubectl e verifique se NEGs correspondentes foram criados para o serviço do Kubernetes em cada uma das zonas em que o aplicativo é executado:

      $ kubectl describe service win-webserver-1
      

      A saída será assim:

      Name:              win-webserver-1
      Namespace:         default
      Labels:            
      Annotations:       cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}}
                         cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}
      Selector:          app=win-webserver-1
      Type:              ClusterIP
      IP Family Policy:  SingleStack
      IP Families:       IPv4
      IP:                10.64.6.20
      IPs:               10.64.6.20
      Port:              http  80/TCP
      TargetPort:        80/TCP
      Endpoints:         10.60.3.5:80,10.60.4.5:80,10.60.5.5:80
      Session Affinity:  None
      Events:
        Type    Reason  Age    From            Message
        ----    ------  ----   ----            -------
        Normal  Create  4m25s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a".
        Normal  Create  4m18s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b".
        Normal  Create  4m11s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c".
        Normal  Attach  4m9s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a")
        Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c")
        Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b")
      

      A saída do comando anterior mostra que um NEG foi criado para cada zona.

   6. Opcional: use a CLI gcloud para verificar se os NEGs foram criados:

      gcloud compute network-endpoint-groups list
      

      A saída é a seguinte:

      NAME                                                        LOCATION            ENDPOINT_TYPE     SIZE
      win-webserver-1                                us-central1-a  GCE_VM_IP_PORT  1
      win-webserver-1                                us-central1-b  GCE_VM_IP_PORT  1
      win-webserver-1                                us-central1-c  GCE_VM_IP_PORT  1
      

   7. Para implantar o segundo aplicativo de teste, aplique o seguinte arquivo YAML:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: win-webserver-2
        name: win-webserver-2
      spec:
        replicas: 3
        selector:
          matchLabels:
            app: win-webserver-2
        template:
          metadata:
            labels:
              app: win-webserver-2
            name: win-webserver-2
          spec:
           containers:
            - name: windowswebserver
              image: k8s.gcr.io/e2e-test-images/agnhost:2.36
              command: ["/agnhost"]
              args: ["netexec", "--http-port", "80"]
           topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: kubernetes.io/hostname
              whenUnsatisfiable: DoNotSchedule
              labelSelector:
                matchLabels:
                  app: win-webserver-2
           nodeSelector:
            kubernetes.io/os: windows
      

   8. Crie o serviço do Kubernetes correspondente:

      apiVersion: v1
      kind: Service
      metadata:
        name: win-webserver-2
        annotations:
          cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}'
      spec:
        type: ClusterIP
        selector:
          app: win-webserver-2
        ports:
        - name: http
          protocol: TCP
          port: 80
          targetPort: 80
      

   9. Verifique a implantação do aplicativo:

      kubectl get pods
      

      Confira a saída e verifique se há três pods em execução.

   10. Verifique se o serviço do Kubernetes e as três NEGs foram criados:

       kubectl describe service win-webserver-2
       

   Configurar o Cloud Service Mesh

   Nesta seção, o Cloud Service Mesh é configurado como o plano de controle para os gateways do Envoy.

   Mapeie os gateways do Envoy para a configuração de roteamento relevante do Cloud Service Mesh especificando o parâmetro scope_name. O parâmetro scope_name permite configurar diferentes regras de roteamento para os diferentes gateways do Envoy.

   1. No Cloud Shell, crie uma regra de firewall que permita o tráfego de entrada dos serviços do Google que estão verificando a capacidade de resposta do aplicativo:

      gcloud compute firewall-rules create allow-health-checks \
        --network=default \
        --direction=INGRESS \
        --action=ALLOW \
        --rules=tcp \
        --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"
      

   2. Verifique a capacidade de resposta do primeiro aplicativo:

      gcloud compute health-checks create http win-app-1-health-check \
        --enable-logging \
        --request-path="/healthz" \
        --use-serving-port
      

   3. Verifique a capacidade de resposta do segundo aplicativo:

      gcloud compute health-checks create http win-app-2-health-check \
        --enable-logging \
        --request-path="/healthz" \
        --use-serving-port
      

   4. Crie um serviço de back-end do Cloud Service Mesh para o primeiro aplicativo:

      gcloud compute backend-services create win-app-1-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --port-name=http \
       --health-checks win-app-1-health-check
      

   5. Crie um serviço de back-end do Cloud Service Mesh para o segundo aplicativo:

      gcloud compute backend-services create win-app-2-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --port-name=http \
       --health-checks win-app-2-health-check
      

   6. Adicione as NEGs criadas anteriormente. Esses NEGs estão associados ao primeiro aplicativo que você criou como um back-end para o serviço de back-end do Cloud Service Mesh. Este exemplo de código adiciona um NEG para cada zona no cluster regional que você criou.

      BACKEND_SERVICE=win-app-1-service
      APP1_NEG_NAME=win-webserver-1
      MAX_RATE_PER_ENDPOINT=10
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP1_NEG_NAME \
        --network-endpoint-group-zone us-central1-b \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP1_NEG_NAME \
        --network-endpoint-group-zone us-central1-a \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP1_NEG_NAME \
        --network-endpoint-group-zone us-central1-c \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      

   7. Adicione outros NEGs. Esses NEGs estão associados ao segundo aplicativo que você criou como um back-end para o serviço de back-end do Cloud Service Mesh. Este exemplo de código adiciona um NEG para cada zona no cluster regional que você criou.

      BACKEND_SERVICE=win-app-2-service
      APP2_NEG_NAME=win-webserver-2
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP2_NEG_NAME \
        --network-endpoint-group-zone us-central1-b \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP2_NEG_NAME \
        --network-endpoint-group-zone us-central1-a \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      
      gcloud compute backend-services add-backend $BACKEND_SERVICE \
        --global \
        --network-endpoint-group $APP2_NEG_NAME \
        --network-endpoint-group-zone us-central1-c \
        --balancing-mode RATE \
        --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
      

   Configurar outros recursos do Cloud Service Mesh

   Agora que você configurou os serviços do Cloud Service Mesh, é necessário configurar dois recursos adicionais para concluir a configuração do Cloud Service Mesh.

   Primeiro, estas etapas mostram como configurar um recurso Gateway. Um recurso Gateway é um recurso virtual usado para gerar regras de roteamento do Cloud Service Mesh. As regras de roteamento do Cloud Service Mesh são usadas para configurar proxies Envoy como gateways.

   Em seguida, as etapas mostram como configurar um recurso HTTPRoute para cada um dos serviços de back-end. O recurso HTTPRoute mapeia solicitações HTTP para o serviço de back-end relevante.

   1. No Cloud Shell, crie um arquivo YAML chamado gateway.yaml que define o recurso Gateway:

      cat <<EOF> gateway.yaml
      name: gateway80
      scope: gateway-proxy
      ports:
      - 8080
      type: OPEN_MESH
      EOF
      

   2. Crie o recurso Gateway invocando o arquivo gateway.yaml:

      gcloud network-services gateways import gateway80 \
        --source=gateway.yaml \
        --location=global
      

      O nome Gateway será projects/$PROJECT_ID/locations/global/gateways/gateway80.

      Você usa esse nome Gateway ao criar HTTPRoutes para cada serviço de back-end.

   Crie o HTTPRoutes para cada serviço de back-end:

   1. No Cloud Shell, armazene o ID do projeto Google Cloud em uma variável de ambiente:

      export PROJECT_ID=$(gcloud config get project)
      

   2. Crie o arquivo YAML HTTPRoute para o primeiro aplicativo:

      cat <<EOF> win-app-1-route.yaml
      name: win-app-1-http-route
      hostnames:
      - win-app-1
      gateways:
      - projects/$PROJECT_ID/locations/global/gateways/gateway80
      rules:
      - action:
         destinations:
         - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service"
      EOF
      

   3. Crie o recurso HTTPRoute para o primeiro aplicativo:

      gcloud network-services http-routes import win-app-1-http-route \
        --source=win-app-1-route.yaml \
        --location=global
      

   4. Crie o arquivo YAML HTTPRoute para o segundo aplicativo:

      cat <<EOF> win-app-2-route.yaml
      name: win-app-2-http-route
      hostnames:
      - win-app-2
      gateways:
      - projects/$PROJECT_ID/locations/global/gateways/gateway80
      rules:
      - action:
         destinations:
       - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service"
      EOF
      

   5. Crie o recurso HTTPRoute para o segundo aplicativo:

      gcloud network-services http-routes import win-app-2-http-route \
        --source=win-app-2-route.yaml \
        --location=global
      

   Implantar e expor os gateways do Envoy

   Depois de criar os dois aplicativos de teste baseados no Windows e o Cloud Service Mesh, implante os gateways do Envoy criando um arquivo YAML de implantação. O arquivo YAML de implantação realiza as seguintes tarefas:

   • Inicializa os gateways do Envoy.
   • Configura os gateways do Envoy para usar o Cloud Service Mesh como plano de controle.
   • Configura os gateways do Envoy para usar HTTPRoutes no gateway chamado Gateway80.

   Implante dois gateways do Envoy de réplica. Essa abordagem ajuda a tornar os gateways tolerantes a falhas e oferece redundância. Para escalonar automaticamente os gateways do Envoy com base na carga, configure um escalonador automático horizontal de pods. Se você decidir configurar um escalonador automático horizontal de pods, siga as instruções em Como configurar o escalonamento automático horizontal de pods.

   1. No Cloud Shell, crie um arquivo YAML:

      apiVersion: apps/v1
      kind: Deployment
          metadata:
        creationTimestamp: null
        labels:
          app: td-envoy-gateway
        name: td-envoy-gateway
      spec:
        replicas: 2
        selector:
          matchLabels:
            app: td-envoy-gateway
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: td-envoy-gateway
          spec:
            containers:
            - name: envoy
              image: envoyproxy/envoy:v1.21.6
              imagePullPolicy: Always
              resources:
                limits:
                  cpu: "2"
                  memory: 1Gi
                requests:
                  cpu: 100m
                  memory: 128Mi
              env:
              - name: ENVOY_UID
                value: "1337"
              volumeMounts:
                - mountPath: /etc/envoy
                  name: envoy-bootstrap
            initContainers:
            - name: td-bootstrap-writer
              image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator
              imagePullPolicy: Always
              args:
                - --project_number='my_project_number'
                - --scope_name='gateway-proxy'
                - --envoy_port=8080
                - --bootstrap_file_output_path=/var/lib/data/envoy.yaml
                - --traffic_director_url=trafficdirector.googleapis.com:443
                - --expose_stats_port=15005
              volumeMounts:
                - mountPath: /var/lib/data
                  name: envoy-bootstrap
            volumes:
              - name: envoy-bootstrap
                emptyDir: {}
      

      • Substitua my_project_number pelo número do projeto.

        • Para encontrar o número do projeto, execute o seguinte comando:

        gcloud projects describe $(gcloud config get project)
         --format="value(projectNumber)"
        

      A porta 15005 é usada para expor o endpoint de administrador do Envoy chamado /stats. Ele também é usado para as seguintes finalidades:

      • Como um endpoint de capacidade de resposta do balanceador de carga de aplicativo interno.
      • Como uma forma de consumir métricas do Google Cloud Managed Service para Prometheus do Envoy.

      Quando os dois pods do Envoy Gateway estiverem em execução, crie um serviço do tipo ClusterIP para expô-los. Você também precisa criar um arquivo YAML chamado BackendConfig. BackendConfig define uma verificação de capacidade de resposta não padrão. Essa verificação é usada para verificar a capacidade de resposta dos gateways do Envoy.

   2. Para criar a configuração de back-end com uma verificação de capacidade de resposta não padrão, crie um arquivo YAML chamado envoy-backendconfig:

      apiVersion: cloud.google.com/v1
      kind: BackendConfig
      metadata:
        name: envoy-backendconfig
      spec:
        healthCheck:
          checkIntervalSec: 5
          timeoutSec: 5
          healthyThreshold: 2
          unhealthyThreshold: 3
          type: HTTP
          requestPath: /stats
          port: 15005
      

      A verificação de capacidade de resposta usa o endpoint /stats na porta 15005 para verificar continuamente a capacidade de resposta dos gateways do Envoy.

   3. Crie o serviço de gateways do Envoy:

      apiVersion: v1
      kind: Service
      metadata:
        name: td-envoy-gateway
        annotations:
          cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}'
      spec:
        type: ClusterIP
        selector:
          app: td-envoy-gateway
        ports:
        - name: http
          protocol: TCP
          port: 8080
          targetPort: 8080
        - name: stats
          protocol: TCP
          port: 15005
          targetPort: 15005
      

   4. Confira o serviço de gateways do Envoy que você criou:

      kubectl get svc td-envoy-gateway
      

   Criar o recurso de gateway do Kubernetes

   A criação do recurso de gateway do Kubernetes provisiona o balanceador de carga de aplicativo interno para expor os gateways do Envoy.

   Antes de criar esse recurso, crie dois certificados autoassinados de amostra e importe-os para o cluster do GKE como Secrets do Kubernetes. Os certificados ativam a seguinte arquitetura de gateway:

   • Cada aplicativo é exibido por HTTPS.
   • Cada aplicativo usa um certificado dedicado.

   Ao usar certificados autogerenciados, o balanceador de carga de aplicativo interno pode usar até o limite máximo de certificados para expor aplicativos com diferentes nomes de domínio totalmente qualificados.

   Para criar os certificados, use openssl.

   1. No Cloud Shell, gere um arquivo de configuração para o primeiro certificado:

      cat <<EOF >CONFIG_FILE
      [req]
      default_bits              = 2048
      req_extensions            = extension_requirements
      distinguished_name        = dn_requirements
      prompt                    = no
      [extension_requirements]
      basicConstraints          = CA:FALSE
      keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
      subjectAltName            = @sans_list
      [dn_requirements]
      0.organizationName        = example
      commonName                = win-webserver-1.example.com
      [sans_list]
      DNS.1                     = win-webserver-1.example.com
      EOF
      

   2. Gere uma chave privada para o primeiro certificado:

      openssl genrsa -out sample_private_key 2048
      

   3. Gere uma solicitação de certificado:

      openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE
      

   4. Assine e gere o primeiro certificado:

      openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt     -extfile CONFIG_FILE -extensions extension_requirements -days 90
      

   5. Gere um arquivo de configuração para o segundo certificado:

      cat <<EOF >CONFIG_FILE2
      [req]
      default_bits              = 2048
      req_extensions            = extension_requirements
      distinguished_name        = dn_requirements
      prompt                    = no
      [extension_requirements]
      basicConstraints          = CA:FALSE
      keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
      subjectAltName            = @sans_list
      [dn_requirements]
      0.organizationName        = example
      commonName                = win-webserver-2.example.com
      [sans_list]
      DNS.1                     = win-webserver-2.example.com
      EOF
      

   6. Gere uma chave privada para o segundo certificado:

      openssl genrsa -out sample_private_key2 2048
      

   7. Gere uma solicitação de certificado:

      openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2
      

   8. Assine e gere o segundo certificado:

      openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt     -extfile CONFIG_FILE2 -extensions extension_requirements -days 90
      

   Importar certificados como secrets do Kubernetes

   Nesta seção, você vai realizar as seguintes tarefas:

   • Importe os certificados autoassinados para o cluster do GKE como secrets do Kubernetes.
   • Crie um endereço IP estático para uma VPC interna.
   • Crie o recurso da API Gateway do Kubernetes.
   • Verifique se os certificados funcionam.

   1. No Cloud Shell, importe o primeiro certificado como um secret do Kubernetes:

      kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key
      

   2. Importe o segundo certificado como um secret do Kubernetes:

      kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2
      

   3. Para ativar o balanceador de carga de aplicativo interno, crie um endereço IP estático na VPC interna:

      gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default
      

   4. Crie o arquivo YAML de recurso da API Gateway do Kubernetes:

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1beta1
      metadata:
        name: internal-https
      spec:
        gatewayClassName: gke-l7-rilb
        addresses:
          - type: NamedAddress
            value: sample-ingress-ip
        listeners:
        - name: https
          protocol: HTTPS
          port: 443
          tls:
            mode: Terminate
            certificateRefs:
            - name: sample-cert
            - name: sample-cert-2
      

      Por padrão, um gateway do Kubernetes não tem rotas padrão. O gateway retorna um erro de página não encontrada (404) quando as solicitações são enviadas a ele.

   5. Configure um arquivo YAML route padrão para o gateway do Kubernetes que transfere todas as solicitações recebidas para os gateways do Envoy:

        kind: HTTPRoute
        apiVersion: gateway.networking.k8s.io/v1beta1
        metadata:
          name: envoy-default-backend
        spec:
          parentRefs:
          - kind: Gateway
            name: internal-https
          rules:
          - backendRefs:
            - name: td-envoy-gateway
              port: 8080
      

      Verifique o fluxo completo enviando solicitações HTTP para os dois aplicativos. Para verificar se os gateways do Envoy roteiam o tráfego para os pods de aplicativo corretos, inspecione o cabeçalho HTTP Host.

   6. Encontre e armazene o endereço IP do gateway do Kubernetes em uma variável de ambiente:

      export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)
      

   7. Envie uma solicitação para o primeiro aplicativo:

      curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName
      

   8. Envie uma solicitação para o segundo aplicativo:

      curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName
      

   9. Verifique se o nome do host retornado da solicitação corresponde aos pods em execução win-app-1 e win-app-2:

      kubectl get pods
      

      A saída precisa mostrar win-app-1 e win-app-2.

   Monitorar gateways do Envoy

   Monitore seus gateways do Envoy com o Google Cloud Managed Service para Prometheus.

   O Google Cloud Managed Service para Prometheus deve estar ativado por padrão no cluster que você criou anteriormente.

   1. No Cloud Shell, crie um recurso PodMonitoring aplicando o seguinte arquivo YAML:

      apiVersion: monitoring.googleapis.com/v1
      kind: PodMonitoring
      metadata:
        name: prom-envoy
      spec:
        selector:
          matchLabels:
            app: td-envoy-gateway
        endpoints:
        - port: 15005
          interval: 30s
          path: /stats/prometheus
      

      Depois de aplicar o arquivo YAML, o sistema começa a coletar métricas do Google Cloud Managed Service para Prometheus em um painel.

   2. Para criar o painel de métricas do Google Cloud Managed Service para Prometheus, siga estas instruções:

      1. Faça login no console Google Cloud .
      2. Abra o menu .
      3. Clique em Operações > Monitoramento > Painéis.

   3. Para importar o painel, siga estas instruções:

      1. Na tela "Painéis", clique em Biblioteca de amostra.
      2. Digite "envoy" na caixa de filtro.
      3. Clique em Visão geral do Istio Envoy Prometheus.
      4. Marque a caixa de seleção.
      5. Clique em Importar e em Confirmar para importar o painel.

   4. Para acessar o painel, siga estas instruções:

      1. Clique em Lista de painéis.
      2. Selecione Integrações.
      3. Clique em Visão geral do Istio Envoy Prometheus para ver o painel.

   Agora é possível conferir as métricas mais importantes dos seus gateways do Envoy. Também é possível configurar alertas com base nos seus critérios. Antes de limpar, envie mais algumas solicitações de teste aos aplicativos e veja como o painel é atualizado com as métricas mais recentes.

   Limpar

   Para evitar cobranças na sua conta do Google Cloud pelos recursos usados nesta implantação, exclua o projeto que contém os recursos ou mantenha o projeto e exclua os recursos individuais.

   Excluir o projeto

   Cuidado: excluir um projeto tem os seguintes efeitos:

   • Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele vai resultar na exclusão de outros trabalhos feitos nele.
   • Os IDs do projeto personalizados são perdidos. É possível que, ao criar o projeto, você tenha criado um ID de projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

   Se você planeja explorar várias arquiteturas, tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda limites da cota.

   1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

   2. In the project list, select the project that you want to delete, and then click Delete.
   3. In the dialog, type the project ID, and then click Shut down to delete the project.

   A seguir

   • Saiba mais sobre os produtos do Google Cloud usados neste guia de implantação:
     • Práticas recomendadas de rede do GKE
     • Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE
     • Observabilidade do plano de controle do Cloud Service Mesh
     • Como usar certificados SSL autogerenciados com balanceadores de carga
   • Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

   Colaboradores

   Autor: Eitan Eibschutz | Consultor de soluções técnicas da equipe

   Outros colaboradores:

   • John Laham | Arquiteto de soluções
   • Kaslin Fields | Mediadora de desenvolvedores
   • Maridi (Raju) Makaraju | Líder de tecnologia de suporte
   • Valavan Rajakumar | Arquiteto corporativo fundamental
   • Victor Moreno | Gerente de produtos, Cloud Networking