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 do GKE gerenciados.

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 Cloud Service Mesh e do Envoy. 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

• Criar e configurar 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 do Google 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 Limpar.

Antes de começar

1. No console do Google Cloud , na página do seletor de projetos, selecione ou crie um projeto do Google Cloud .

   Papéis necessários para selecionar ou criar um projeto

   • Selecionar um projeto: não é necessário um papel específico do IAM para selecionar um projeto. Você pode escolher qualquer projeto em que tenha recebido um papel.
   • Criar um projeto: para criar um projeto, é necessário ter o papel de Criador de projetos (roles/resourcemanager.projectCreator), que contém a permissão resourcemanager.projects.create. Saiba como conceder papéis.
   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

2. Verifique se o faturamento está ativado para o projeto do Google Cloud .

3. Ative as APIs do Cloud Shell e do Cloud Service Mesh, se alguma delas ainda não estiver ativada.

   Funções necessárias para ativar APIs

   Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

   Ativar as APIs

4. No console do Google Cloud , ative o Cloud Shell.

   Ativar o Cloud Shell

Se você estiver executando em um ambiente de nuvem privada virtual (VPC) compartilhada, siga 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. Use o cluster do GKE para conter e executar os aplicativos do Windows e os proxies do Envoy nessa implantação.

1. No Cloud Shell, execute o seguinte comando da Google Cloud CLI para criar um cluster do GKE regional 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, será possível 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. Ambos os 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 vai mostrar como configurar essas NEGs como back-ends 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 correspondente do Kubernetes 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. Verifique 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 para verificar se os 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 resposta é 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 correspondente do Kubernetes:

   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
   

   Verifique a saída e confirme 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 rota 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 os NEGs que você criou 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 mais dois recursos para concluir a configuração do Cloud Service Mesh.

Primeiro, estas etapas mostram como configurar um recurso de Gateway. Um recurso Gateway é um recurso virtual usado para gerar regras de rota do Cloud Service Mesh. As regras de rota do Cloud Service Mesh são usadas para configurar proxies do 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 defina 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 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. Também é necessário 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 vai usar 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 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 permitem a seguinte arquitetura de gateway:

• Cada aplicativo é veiculado 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 do 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 "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 transmita 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 vai mostrar win-app-1 e win-app-2.

Monitorar gateways do Envoy

Monitore seus gateways do Envoy com o Serviço Gerenciado do Google Cloud para Prometheus.

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 você pode 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 liberar espaço, envie mais algumas solicitações de teste para os 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: a exclusão de 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 incluirá a exclusão de quaisquer outros trabalhos feitos nele.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um ID do 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. No console Google Cloud , acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

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