Implantar aplicativos Windows em Kubernetes gerenciados

Last reviewed 2024-08-14 UTC

Este documento descreve 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 usada 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 as rotas de tráfego para os pods do Windows.

Objetivos

  • Crie e configure um cluster do GKE para executar aplicativos Windows e proxies do Envoy.
  • Implante e verifique os aplicativos do Windows.
  • Configure o Cloud Service Mesh como o plano de controle dos 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:

Ao concluir a implantação, exclua os recursos criados para evitar o faturamento contínuo. Saiba mais em Limpeza.

Antes de começar

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

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

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

    Enable the APIs

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

    Activate Cloud Shell

Se estiver em execução em um ambiente de nuvem privada virtual (VPC) compartilhado, também será necessário seguir as instruções para criar manualmente a regra de firewall e a sub-rede somente proxy 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 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.

  3. Armazene o ID do projeto do 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 nó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ê implanta 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 por meio de grupos de endpoints de rede independentes (NEGs, na sigla em inglês).

Quando você implanta um aplicativo baseado no Windows e um serviço do Kubernetes em um cluster regional, ele cria um NEG para cada zona em que o aplicativo é executado. Mais adiante, este guia de implantação discute como configurar esses 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 o exponha 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 as NEGs foram criadas:

    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

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

  10. Verifique se o serviço do Kubernetes e 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 dos gateways do Envoy.

Especifique o parâmetro scope_name para mapear os gateways do Envoy à configuração de roteamento relevante do Cloud Service Mesh. O parâmetro scope_name permite configurar regras de roteamento diferentes 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 da 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 da 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 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 mais 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.

    Use 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 do 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 de pods horizontais. 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 do Envoy Admin chamado /stats. Ele também é usado para as seguintes finalidades:

    • Como um endpoint de capacidade de resposta do balanceador de carga interno do aplicativo.
    • Como uma maneira de consumir as métricas do Google Cloud Managed Service para Prometheus no 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 do back-end com uma verificação de responsividade 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. Acesse 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 exibir os gateways do Envoy.

Antes de criar esse recurso, você precisa criar dois certificados de amostra autoassinados e, em seguida, importá-los para o cluster do GKE como segredos 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 Kubernetes Gateway.
  • 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 Kubernetes Gateway:

    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 transmite todas as solicitações recebidas 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

    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 Host HTTP.

  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 que executam 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 os gateways do Envoy com o Google Cloud Managed Service para Prometheus.

O Google Cloud Managed Service para Prometheus precisa 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 do 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 acessar o painel.

Agora você pode conferir as métricas mais importantes dos seus gateways Envoy. Também é possível configurar alertas com base nos seus critérios. Antes de limpar, 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 na 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: