Implemente aplicações Windows no Kubernetes gerido

Este documento descreve como implementar a arquitetura de referência em Gerir e dimensionar a rede para aplicações Windows executadas no Kubernetes gerido.

Estas instruções destinam-se a arquitetos da nuvem, administradores de rede e profissionais de TI responsáveis pela conceção e gestão de aplicações Windows executadas em clusters do Google Kubernetes Engine (GKE).

Arquitetura

O diagrama seguinte mostra a arquitetura de referência que usa quando implementa aplicações Windows que são executadas em clusters GKE geridos.

Os dados fluem através de um Application Load Balancer interno e de um gateway Envoy.

Conforme mostrado no diagrama anterior, uma seta representa o fluxo de trabalho para gerir a rede para aplicações Windows executadas no GKE através da Cloud Service Mesh e dos gateways Envoy. O cluster do GKE regional inclui pools de nós do Windows e do Linux. O Cloud Service Mesh cria e gere trajetos de tráfego para os pods do Windows.

Objetivos

  • Crie e configure um cluster do GKE para executar aplicações Windows e proxies Envoy.
  • Implemente e valide as aplicações Windows.
  • Configure o Cloud Service Mesh como o plano de controlo para os gateways do Envoy.
  • Use a API Kubernetes Gateway para aprovisionar o Application Load Balancer interno e expor os gateways do Envoy.
  • Compreenda as operações de implementação contínua que criou.

Custos

A implementação desta arquitetura usa os seguintes componentes faturáveis do Google Cloud:

Quando terminar esta implementação, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

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 estiver a ser executado num ambiente de nuvem virtual privada (VPC) partilhada, também tem de seguir as instruções para criar manualmente a sub-rede apenas de proxy e a regra da firewall para as verificações de capacidade de resposta do Cloud Load Balancing.

    Crie um cluster do GKE

    Use os passos seguintes para criar um cluster do GKE. Usa o cluster do GKE para conter e executar as aplicações Windows e os proxies Envoy nesta implementação.

    1. No Cloud Shell, execute o seguinte comando da CLI Google Cloud para criar um cluster 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 node pool 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

      Esta operação pode demorar cerca de 20 minutos a ser concluída.

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

      export PROJECT_ID=$(gcloud config get project)

    4. Ligue-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

      O resultado deve apresentar três nós Linux e três nós Windows.

      Depois de o cluster do GKE estar pronto, pode implementar duas aplicações de teste baseadas no Windows.

    Implemente duas aplicações de teste

    Nesta secção, implementa duas aplicações de teste baseadas no Windows. Ambas as aplicações de teste imprimem o nome do anfitrião no qual a aplicação é executada. Também cria um serviço do Kubernetes para expor a aplicação através de grupos de pontos finais de rede (NEGs) autónomos.

    Quando implementa uma aplicação baseada no Windows e um serviço Kubernetes num cluster regional, cria um NEG para cada zona em que a aplicação é executada. Mais tarde, este guia de implementação aborda a forma como pode configurar estes NEGs como back-ends para serviços do Cloud Service Mesh.

    1. No Cloud Shell, aplique o seguinte ficheiro YAML com kubectl para implementar a primeira aplicação de teste. Este comando implementa três instâncias da aplicação 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 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. Valide a implementação:

      kubectl get pods

      O resultado mostra que a aplicação 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 Kubernetes foi criado:

      $ kubectl get svc

      O resultado é semelhante ao seguinte:

      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 foram criados NEGs correspondentes para o serviço Kubernetes em cada uma das zonas em que a aplicação é executada:

      $ kubectl describe service win-webserver-1

      O resultado é semelhante ao seguinte:

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

      O resultado do comando anterior mostra que foi criado um NEG para cada zona.

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

      gcloud compute network-endpoint-groups list

      O resultado é o 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 implementar a segunda aplicação de teste, aplique o seguinte ficheiro 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. Valide a implementação da aplicação:

      kubectl get pods

      Verifique o resultado e confirme que existem três pods em execução.

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

      kubectl describe service win-webserver-2

    Configure o Cloud Service Mesh

    Nesta secção, o Cloud Service Mesh está configurado como o plano de controlo para os gateways do Envoy.

    Mapeia os gateways do Envoy para a configuração de encaminhamento do Cloud Service Mesh relevante especificando o parâmetro scope_name. O parâmetro scope_name permite-lhe configurar diferentes regras de encaminhamento 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 Google que estão a verificar a capacidade de resposta da aplicação:

      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 da primeira aplicação:

      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 da segunda aplicação:

      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 da Cloud Service Mesh para a primeira aplicação:

      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 da malha de serviço na nuvem para a segunda aplicação:

      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 GNEs que criou anteriormente. Estes NEGs estão associados à primeira aplicação que criou como 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 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 NEGs adicionais. Estes NEGs estão associados à segunda aplicação que 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 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

    Configure recursos adicionais do Cloud Service Mesh

    Agora que configurou os serviços do Cloud Service Mesh, tem de configurar dois recursos adicionais para concluir a configuração do Cloud Service Mesh.

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

    Em seguida, os passos mostram como configurar um recurso HTTPRoute para cada um dos serviços de back-end. O recurso HTTPRoute mapeia os pedidos HTTP para o serviço de back-end relevante.

    1. No Cloud Shell, crie um ficheiro YAML denominado 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 ficheiro gateway.yaml:

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

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

      Usa este nome de Gateway quando cria HTTPRoutes para cada serviço de back-end.

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

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

      export PROJECT_ID=$(gcloud config get project)

    2. Crie o ficheiro YAML HTTPRoute para a primeira aplicação:

      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 a primeira aplicação:

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

    4. Crie o ficheiro YAML HTTPRoute para a segunda aplicação:

      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 a segunda aplicação:

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

    Implemente e exponha os gateways do Envoy

    Depois de criar as duas aplicações de teste baseadas no Windows e o Cloud Service Mesh, implementa os gateways do Envoy criando um ficheiro YAML de implementação. O ficheiro YAML de implementação realiza as seguintes tarefas:

    • Inicializa os gateways do Envoy.
    • Configura os gateways do Envoy para usar o Cloud Service Mesh como o respetivo plano de controlo.
    • Configura os gateways do Envoy para usar o HTTPRoutes para o gateway denominado Gateway80.

    Implemente dois gateways Envoy de réplica. Esta abordagem ajuda a tornar os gateways tolerantes a falhas e oferece redundância. Para dimensionar automaticamente os gateways do Envoy com base na carga, pode configurar opcionalmente um redimensionador automático de pods horizontal. Se decidir configurar um Horizontal Pod Autoscaler, tem de seguir as instruções em Configurar a escala automática horizontal de pods.

    1. No Cloud Shell, crie um ficheiro 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 seu projeto.

        • Pode encontrar o número do projeto executando o seguinte comando:
        gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

      A porta 15005 é usada para expor o ponto final de administração do Envoy denominado /stats. Também é usado para os seguintes fins:

      • Como um ponto final de capacidade de resposta do balanceador de carga de aplicações interno.
      • Como forma de consumir métricas do Google Cloud Managed Service for Prometheus a partir do Envoy.

      Quando os dois agrupamentos do gateway Envoy estiverem em execução, crie um serviço do tipo ClusterIP para os expor. Também tem de criar um ficheiro YAML denominado BackendConfig. BackendConfig define uma verificação de capacidade de resposta não padrão. Essa verificação é usada para validar a capacidade de resposta das gateways Envoy.

    2. Para criar a configuração de back-end com uma verificação de capacidade de resposta não padrão, crie um ficheiro YAML denominado 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 da capacidade de resposta usa o ponto final /stats na porta 15005 para verificar continuamente a capacidade de resposta das 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. Veja o serviço de gateways Envoy que criou:

      kubectl get svc td-envoy-gateway

    Crie o recurso de gateway do Kubernetes

    A criação do recurso do gateway do Kubernetes aprovisiona o Application Load Balancer interno para expor os gateways do Envoy.

    Antes de criar esse recurso, tem de criar dois exemplos de certificados autossinados e, em seguida, importá-los para o cluster do GKE como segredos do Kubernetes. Os certificados permitem a seguinte arquitetura de gateway:

    • Cada aplicação é publicada através de HTTPS.
    • Cada aplicação usa um certificado dedicado.

    Quando usa certificados autogeridos, o Application Load Balancer interno pode usar até ao limite máximo de certificados para expor aplicações com diferentes nomes de domínio totalmente qualificados.

    Para criar os certificados, use openssl.

    1. No Cloud Shell, gere um ficheiro 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 um pedido 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 ficheiro 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 um pedido 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

    Importe certificados como secrets do Kubernetes

    Nesta secção, conclui as seguintes tarefas:

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

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

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

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

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

    3. Para ativar o Application Load Balancer 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 ficheiro 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 predefinição, um gateway do Kubernetes não tem rotas predefinidas. O gateway devolve um erro de página não encontrada (404) quando lhe são enviados pedidos.

    5. Configure um routeficheiro YAML predefinido para o Kubernetes Gateway que transmite todos os pedidos recebidos aos 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

      Valide o fluxo completo enviando pedidos HTTP para ambas as aplicações. Para verificar se os gateways do Envoy encaminham o tráfego para os Pods da aplicação corretos, inspecione o cabeçalho HTTP Host.

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

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

    7. Envie um pedido à primeira aplicação:

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

    8. Envie um pedido para a segunda aplicação:

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

    9. Verifique se o nome do anfitrião devolvido do pedido corresponde aos pods que executam win-app-1 e win-app-2:

      kubectl get pods

      O resultado deve apresentar win-app-1 e win-app-2.

    Monitorize gateways Envoy

    Monitorize as suas gateways do Envoy com o Google Cloud Managed Service for Prometheus.

    O Google Cloud Managed Service for Prometheus deve estar ativado por predefinição no cluster que criou anteriormente.

    1. No Cloud Shell, crie um recurso PodMonitoring aplicando o seguinte ficheiro 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

      Após aplicar o ficheiro YAML, o sistema começa a recolher métricas do Google Cloud Managed Service for Prometheus num painel de controlo.

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

      1. Inicie sessão na Google Cloud consola.
      2. Abra o menu .
      3. Clique em Operações > Monitorização > Painéis de controlo.

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

      1. No ecrã Painéis de controlo, clique em Biblioteca de exemplos.
      2. Introduza envoy na caixa de filtro.
      3. Clique em Vista geral do Istio Envoy Prometheus.
      4. Selecione a caixa de verificação.
      5. Clique em Importar e, de seguida, em Confirmar para importar o painel de controlo.

    4. Para ver o painel de controlo, siga estas instruções:

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

    Agora, pode ver as métricas mais importantes das suas gateways do Envoy. Também pode configurar alertas com base nos seus critérios. Antes de limpar, envie mais alguns pedidos de teste às aplicações e veja como o painel de controlo é atualizado com as métricas mais recentes.

    Limpar

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

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

    O que se segue?

    Colaboradores

    Autor: Eitan Eibschutz | Staff Technical Solutions Consultant

    Outros colaboradores: