Implantar aplicativos Windows em Kubernetes gerenciados

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.

Os dados fluem por um balanceador de carga de aplicativo interno e um gateway do Envoy.

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 Gateway do Kubernetes 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:

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.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    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.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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

    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

    Colaboradores

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

    Outros colaboradores: