Adicionar máquinas virtuais do Compute Engine ao Anthos Service Mesh

Nesta página, descrevemos como adicionar máquinas virtuais (VMs) do Compute Engine ao Mesh Service Mesh no Google Kubernetes Engine (GKE). Nesta página, mostramos como instalar o Anthos Service Mesh 1.10.6 com a opção que prepara o cluster para adicionar uma VM.

  • Se você já tiver o Anthos Service Mesh 1.9 or a 1.10 patch release instalado, esta página mostrará como fazer upgrade para o Anthos Service Mesh 1.10.6 com a opção necessária para adicionar uma VM.

  • Se você tiver o Anthos Service Mesh 1.9 e não quiser fazer upgrade, consulte o guia do Anthos Service Mesh 1.9 para instruções sobre como adicionar VMs ao Anthos Service Mesh 1.9.

  • Se você tiver uma versão anterior do Anthos Service Mesh, primeiro faça upgrade do Anthos Service Mesh para 1.9 ou mais recente.

Nesta página, fornecemos a linha de comando para instalar o plano de controle no cluster.

Introdução

O Anthos Service Mesh permite gerenciar, observar e proteger serviços em execução em grupos de instâncias gerenciadas (MIGs, na sigla em inglês) junto de serviços em execução nos clusters do Google Kubernetes Engine (GKE) na malha. Isso permite fazer o seguinte com as instâncias do Compute Engine na malha:

  • Gerenciar o tráfego
  • Aplicar mTLS
  • Aplicar o controle de acesso ao tráfego do serviço
  • Acessar com segurança os serviços do Google Cloud
  • Coletar métricas, registros e dados de rastreamento
  • Monitorar serviços usando o Console do Google Cloud.

Isso permite que aplicativos legados incompatíveis ou não prontos para contentorização aproveitem os recursos do Anthos Service Mesh e permite a integração dessas cargas de trabalho com o restante dos serviços.

Como funciona

O Anthos Service Mesh (ASM) fornece duas definições de recursos personalizadas (CRDs, na sigla em inglês) relacionadas para representar cargas de trabalho de máquinas virtuais:

  • WorkloadGroup representa um grupo lógico de cargas de trabalho de máquinas virtuais que compartilham propriedades em comum. Isso é semelhante a uma implantação no Kubernetes.
  • WorkloadEntry representa uma única instância de uma carga de trabalho de uma máquina virtual. Isso é semelhante a um pod no Kubernetes.
  • Um Service pode selecionar o WorkloadGroup e direcionar o tráfego do ASM para a instância de VM de maneira semelhante a um Pod. Isso permite que a VM atue como qualquer outra carga de trabalho na malha.

Você cria um modelo de instância do Compute Engine para cada grupo de instâncias do Compute Engine, que especifica um agente de proxy de serviço para cada instância do Compute Engine nesse grupo. Durante a instalação, o agente inicializa o proxy do serviço, configura a interceptação de tráfego e monitora a integridade do proxy de serviço durante o ciclo de vida da instância do Compute Engine. O proxy se conecta ao plano de controle do Anthos Service Mesh e registra automaticamente cada instância do Compute Engine como um WorkloadEntry para os WorkloadGroup (links em inglês) correspondentes. Isso permite que o Anthos Service Mesh trate cada instância como um endpoint de serviço, como os pods do Kubernetes no cluster. Também é possível criar serviços do Kubernetes para cargas de trabalho de VM, como você faria com os pods do Kubernetes.

Para escalonar horizontalmente o número de cargas de trabalho em instâncias do Compute Engine, a partir de um tamanho mínimo de MIG de zero, consulte Como fazer o escalonamento automático de grupos de instâncias.

O agente de proxy de serviço depende do gerenciador de VMs para garantir que o agente seja instalado em cada VM no MIG. Para mais informações sobre grupos de instâncias e gerenciamento de VMs, consulte Grupo de instâncias gerenciadas (MIG, na sigla em inglês) e VM Manager.

Distribuições do Linux compatíveis

Versão do sistema operacional suporte
Debian 10
Debian 9
Centos 8
Centos 7

Consulte Suporte ao Debian ou Suporte ao CentOS para mais informações sobre distribuições do SO.

Limitações

  • O plano de controle da malha precisa ser o Anthos Service Mesh 1.9 ou superior.
  • Somente grupos de instâncias gerenciadas pelo Compute Engine criados com base em um modelo de instância do Compute Engine são compatíveis.
  • O cluster e as VMs precisam estar na mesma rede, no mesmo projeto e usar uma única interface de rede.
  • É possível usar esse recurso sem uma assinatura do GKE Enterprise, mas alguns elementos e recursos da IU no console do Google Cloud estão disponíveis apenas para assinantes do GKE Enterprise. Para informações sobre o que está disponível para assinantes e não assinantes, consulte Diferenças na IU do GKE Enterprise e do Anthos Service Mesh.

Pré-requisitos

Antes de começar:

Revise o projeto do Cloud, o licenciamento do GKE Enterprise e os requisitos gerais descritos em Pré-requisitos.

Requisitos de cluster

Antes de continuar, verifique se o cluster atende aos requisitos do GKE. Além disso, o suporte à VM do Anthos Service Mesh requer que:

  • Especifique a CA da malha como a autoridade de certificação (CA) ao instalar o Anthos Service Mesh.
  • Você não substitui o Stackdriver por telemetria. O Stackdriver é configurado por padrão quando você instala o Anthos Service Mesh.
  • Seu cluster está registrado em uma frota. No entanto, se o cluster não estiver registrado, o processo de instalação da VM registrará o cluster no projeto especificado.

Como começar

Siga as etapas em Primeiros passos para:

Se você não tiver o Anthos Service Mesh instalado, continue com a próxima seção. Se você já tiver uma instalação do Anthos Service Mesh, siga as etapas em Instalações existentes.

Nova instalação

Para configurar o cluster do Anthos Service Mesh para VMs, prepare o plano de controle do Anthos Service Mesh 1.10.

O comando a seguir mostra como instalar o plano de controle no cluster do Anthos Service Mesh com --option vm que prepara o plano de controle para adicionar VMs.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm
  • --project_id, --cluster_name e --cluster_location Especifique o ID do projeto em que o cluster está, o nome do cluster e a zona ou região do cluster.
  • --output_dir Inclua essa opção para especificar um diretório em que asmcli faz o download do pacote anthos-service-mesh e extrai o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  • --enable_all permite que o script:
    • Conceder as permissões necessárias do IAM.
    • Ative as APIs do Google necessárias.
    • Defina um rótulo no cluster que identifique a malha.
    • Registre o cluster na frota se ele ainda não estiver registrado.

  • --ca mesh_ca Use o Mesh CA como a autoridade de certificação. asmcliconfigura o Mesh CA para usar a identidade da carga de trabalho da frota
  • --option vm prepara o cluster para incluir uma VM na malha de serviço.

Se você tiver cargas de trabalho existentes em execução no cluster, reimplante as cargas de trabalho e volte a esta página para adicionar suas VMS.

Instalações existentes

Se o Anthos Service Mesh já tiver sido instalado no cluster, siga estas etapas:

  1. Registre o cluster na frota, caso ainda não tenha feito isso.

  2. Execute o seguinte comando para preparar e verificar se a instalação do Anthos Service Mesh está pronta para cargas de trabalho de VM.

    ./asmcli experimental vm prepare-cluster \
        --project_id PROJECT_ID \
        --cluster_name CLUSTER_NAME \
        --cluster_location CLUSTER_LOCATION
    

    Se for bem-sucedido, o comando gerará o seguinte:

    The cluster is ready for adding VM workloads.
    Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
    Compute Engine VMs to your mesh.
    

O comando faz o seguinte:

  1. Ativação do registro automático da VM: isso é feito definindo as variáveis PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION e PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY como verdadeiras. Quando esse recurso estiver ativado, novas instâncias de VM serão registradas no WorkloadGroup e as novas respostas automáticas WorkloadEntry serão criadas para rotear o tráfego para as VMs. Todos os planos de controle do Anthos Service Mesh 1.9+ instalados com asmcli terão o registro automático de VM ativado por padrão.

  2. Instalação um gateway de expansão: esse gateway é chamado de gateway eastwest e é definido no pacote de configuração do Anthos Service Mesh. Isso também irá expor o plano de controle às VMs.

  3. Instalação do CRD IdentityProvider e registro de uma resposta automática do IdentityProvider do Google para permitir que as VMs sejam autenticadas no plano de controle do Anthos Service Mesh e se comuniquem com segurança com o restante da malha de serviço.

  4. Registre o cluster em uma frota e ative a identidade da carga de trabalho se usar --enable_all ou --enable_registration no script asmcli.

  5. Ative o recurso Service Mesh na frota. Esse recurso gerenciará as políticas necessárias para permitir que as VMs se comuniquem com segurança com a malha.

Instalar gateways de entrada

O Anthos Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha.

  1. Crie um namespace para o gateway de entrada, se você ainda não tiver um. Os gateways são cargas de trabalho de usuários. Como prática recomendada, não implante-os no namespace do plano de controle. Substitua GATEWAY_NAMESPACE pelo nome do namespace.

    kubectl create namespace GATEWAY_NAMESPACE
    
  2. Ative a injeção automática no gateway aplicando um rótulo de revisão no namespace do gateway. O rótulo de revisão é usado pelo webhook do injetor do arquivo secundário para associar os proxies injetados a uma revisão específica do plano de controle. O rótulo de revisão usado depende se você implantou o Anthos Service Mesh gerenciado ou o plano de controle no cluster.

    1. Use o seguinte comando para localizar o rótulo de revisão em istiod:

      kubectl -n istio-system get pods -l app=istiod --show-labels
      

      A resposta será semelhante a:

      NAME                                READY   STATUS    RESTARTS   AGE   LABELS
      istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
      istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

      Na saída, na coluna LABELS, anote o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1106-2.

    2. Aplique o rótulo de revisão ao namespace. No comando a seguir, REVISION é o valor do rótulo de revisão istiod que você anotou na etapa anterior.

      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
      

    Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, que é esperado em novas instalações do Anthos Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

  3. Altere para o diretório especificado em --output_dir.

  4. É possível implantar a configuração de exemplo do gateway de entrada localizado no diretório samples/gateways/istio-ingressgateway/ como está ou modificá-lo conforme necessário.

    kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
    

Saiba mais sobre as práticas recomendadas para gateways.

Adicionar VMs

Nesta seção, você adiciona instâncias do Compute Engine à malha com base no modelo de instância criado com o gcloud. gcloud gera apenas a configuração necessária para o agente proxy de serviço. Para incluir mais configurações no modelo de instância, use o guia de referência gcloud para mais informações.

Para adicionar VMs à malha, siga as seguintes etapas:

  1. Defina as seguintes variáveis de ambiente a serem usadas em etapas posteriores. Defina estas variáveis para cada carga de trabalho da VM:

    • WORKLOAD_NAME é o nome da carga de trabalho de que a VM faz parte, que precisa ser um subdomínio DNS-1123 (em inglês) composto de caracteres alfanuméricos minúsculos.
    • WORKLOAD_VERSION é a versão da carga de trabalho de que a VM faz parte. Opcional.
    • WORKLOAD_SERVICE_ACCOUNT é a conta de serviço do GCP executada como a VM.
    • WORKLOAD_NAMESPACE é o namespace da carga de trabalho.
    • ASM_INSTANCE_TEMPLATE é o nome do modelo de instância a ser criado. O nome do modelo da instância do Compute Engine não permite sublinhados.
  2. Crie o namespace para as cargas de trabalho da VM, se ainda não houver um:

    kubectl create ns WORKLOAD_NAMESPACE
    
  3. Rotule o namespace com a revisão do plano de controle.

    Para um exemplo de como encontrar a revisão do plano de controle mostrada como REVISION no exemplo a seguir, consulte Como implantar e reimplantar cargas de trabalho.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
    
  4. Crie o WorkloadGroup para que as VMs sejam registradas:

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: WorkloadGroup
    metadata:
      name: WORKLOAD_NAME
      namespace: WORKLOAD_NAMESPACE
    spec:
      metadata:
        labels:
          app.kubernetes.io/name: WORKLOAD_NAME
          app.kubernetes.io/version: WORKLOAD_VERSION
        annotations:
          security.cloud.google.com/IdentityProvider: google
      template:
        serviceAccount: WORKLOAD_SERVICE_ACCOUNT
    EOF
    
    Field Descrição
    name O nome da carga de trabalho de que a VM faz parte.
    namespace O namespace de que a carga de trabalho faz parte.
    app.kubernetes.io/name Os rótulos recomendados para aplicativos do Kubernetes. É possível usar rótulos próprios para as cargas de trabalho da VM.
    app.kubernetes.io/version Os rótulos recomendados para aplicativos do Kubernetes. É possível usar rótulos próprios para as cargas de trabalho da VM.
    serviceAccount A identidade da conta de serviço usada pela VM e pelo projeto, que será usada como parte da identidade da carga de trabalho no formato SPIFFE. Para mais informações, consulte Contas de serviço.
    security.cloud.google.com/IdentityProvider O provedor de identidade que a VM usará, que já precisa estar registrado no cluster. Para VMs do Compute Engine, ele precisa ser definido como google. O IdentityProvider informa ao plano de controle como autenticar a credencial da VM e onde extrair a conta de serviço da VM.
  5. Use o comando gcloud beta compute instance-templates create com a sinalização --mesh para criar um modelo de instância para suas instâncias do Compute Engine do Anthos Service Mesh.

    gcloud verifica os pré-requisitos do cluster, adiciona rótulos de VM para o Anthos Service Mesh, gera a configuração de metadados personalizados para o agente do proxy de serviço e cria um novo modelo de instância.

    Se o modelo de instância incluir um script de inicialização que exija conectividade de rede, ele precisará ser resiliente a problemas temporários de conectividade de rede. Consulte o aplicativo de demonstração para ver um exemplo de como adicionar resiliência contra interrupções temporárias de rede.

    Para mais informações sobre como criar modelos de instância, consulte Como criar modelos de instância.

    gcloud beta compute instance-templates create \
    ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  6. Defina as seguintes variáveis de ambiente para cada MIG que você criar:

    • INSTANCE_GROUP_NAME é o nome do grupo de instâncias do Compute Engine a ser criado.
    • ASM_INSTANCE_TEMPLATE é o nome do modelo de instância a ser criado. O nome do modelo da instância do Compute Engine não permite sublinhados.
    • INSTANCE_GROUP_ZONE é a zona do grupo de instâncias do Compute Engine a ser criado.
    • PROJECT_ID é ID do projeto em que o cluster foi criado.
    • SIZE é o tamanho do grupo de instâncias a ser criado. É possível alterá-lo após a criação do grupo de instâncias.
    • WORKLOAD_NAME é o nome da carga de trabalho da VM.
    • WORKLOAD_NAMESPACE é o namespace da carga de trabalho.
  7. Crie um grupo gerenciado de instâncias para as cargas de trabalho da VM usando as variáveis criadas nas etapas anteriores:

    gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
    --template ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE \
    --project=PROJECT_ID \
    --size=SIZE
    

    Para escalonar horizontalmente o número de cargas de trabalho em instâncias do Compute Engine, a partir de um tamanho de MIG zonal ou regional de zero, consulte Como escalonar grupos de instâncias automaticamente. Para mais informações sobre como criar grupos, consulte gcloud compute instance-groups managed create.

    Quando a instância for iniciada, ela será autenticada automaticamente com o plano de controle do Anthos Service Mesh no cluster e o plano de controle registrará cada VM como um WorkloadEntry.

  8. Quando a instância de VM no MIG terminar de iniciar, será possível visualizar as VMs registradas no namespace da carga de trabalho usando o seguinte comando:

    kubectl get workloadentry -n WORKLOAD_NAMESPACE
    
  9. Adicione um serviço do Kubernetes para expor as cargas de trabalho da VM adicionadas acima. Certifique-se de que o serviço selecione o rótulo correspondente na VM WorkloadGroup registrada acima para o roteamento de tráfego correto.

    O exemplo a seguir cria um serviço do Kubernetes chamado WORKLOAD_NAME no namespace WORKLOAD_NAMESPACE que expõe cargas de trabalho da VM com o rótulo app.kubernetes.io/name: WORKLOAD_NAME na porta HTTP 80.

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: WORKLOAD_NAME
      namespace: WORKLOAD_NAMESPACE
      labels:
        asm_resource_type: VM
    spec:
      ports:
      - port: 80
        name: http
      selector:
        app.kubernetes.io/name: WORKLOAD_NAME
    EOF
    

    Para mais detalhes sobre como criar um serviço do Kubernetes, consulte https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service (em inglês).

  10. Para usar um aplicativo de amostra na VM, consulte Implantar um aplicativo de amostra.

Reimplantar as cargas de trabalho após o upgrade do plano de controle no cluster

Se você fez upgrade do Anthos Service Mesh na seção anterior e tem cargas de trabalho em execução no cluster, alterne-as para o novo plano de controle.

Para cargas de trabalho da VM, crie um novo modelo de instância e execute uma atualização gradual nas VMs no MIG:

  1. Use o seguinte comando para localizar o rótulo de revisão em istiod:

    kubectl -n istio-system get pods -l app=istiod --show-labels
    

    A saída deste comando é semelhante a: Observe que a saída para migrações é um pouco diferente dos upgrades. A saída de exemplo a seguir é de uma migração.

    NAME                                         READY   STATUS    RESTARTS   AGE   LABELS
    istiod-7744bc8dd7-qhlss                      1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
    istiod-asm-1106-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-1106-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7
    1. Na saída, na coluna LABELS, observe o valor no rótulo de revisão istiod para a nova versão, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1106-2.

    2. Observe também o valor no rótulo de revisão da versão istiod antiga. Você precisará dele para excluir a versão antiga do istiod ao terminar de mover as cargas de trabalho para a nova versão. No exemplo de saída, o valor no rótulo de revisão para a versão antiga de istiod é default.

  2. Adicione o rótulo de revisão a um namespace e remova o rótulo istio-injection, se ele existir. No comando a seguir, altere REVISION para o valor que corresponda à nova revisão de istiod.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

  3. Crie um novo modelo de instância usando gcloud. Certifique-se de incluir a mesma configuração se você tiver um modelo de instância para a mesma carga de trabalho.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  4. Execute uma atualização gradual no MIG existente para a carga de trabalho.

    Para mais informações, consulte Como iniciar uma atualização gradual básica.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE
    
  5. Teste a carga de trabalho da VM para garantir que ela esteja funcionando como esperado.

Fazer upgrade de aplicativos de VM

Se você tiver atualizações no aplicativo, incluindo alterações em WorkloadGroup e/ou na confirguração do modelo de instância, será necessário um novo modelo para atualizar o MIG das cargas de trabalho da VM.

Quando a alteração WorkloadGroup for aplicada e/ou o novo modelo de instância de origem for criado, você criará um novo modelo de instância para o Anthos Service Mesh e executará uma atualização gradual nas VMs do MIG.

  1. Crie um novo modelo de instância usando gcloud.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
    --project PROJECT_ID
    
  2. Execute uma atualização gradual no MIG existente para a carga de trabalho. Para mais informações sobre como usar a atualização gradual do MIG, consulte Como iniciar uma atualização gradual básica.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_ASM_INSTANCE_TEMPLATE \
    --zone=INSTANCE_GROUP_ZONE
    
  3. Teste a carga de trabalho da VM para garantir que ela esteja funcionando conforme o esperado.

Implantar um aplicativo de amostra

Para demonstrar que a nova configuração de malha está funcionando corretamente, instale o aplicativo de amostra Bookinfo. Este exemplo executa um banco de dados MySQL na VM e o serviço de classificação lê os valores de classificação do banco de dados.

Instalar o Bookinfo no cluster

Siga as etapas abaixo para implantar os serviços do aplicativo BookInfo com os proxies sidecar injetados junto com cada serviço. O aplicativo BookInfo será implantado no namespace default.

  1. Na linha de comando do computador em que você instalou o Anthos Service Mesh, acesse a raiz do diretório de instalação do Anthos Service Mesh que você criou na etapa Como fazer o download do script.

  2. Para ativar a injeção automática de sidecar, escolha a instrução abaixo com base no tipo de plano de controle do Anthos Service Mesh.

    Use o comando a seguir para localizar o rótulo em istiod, que contém o valor do rótulo de revisão para usar em etapas posteriores.

    kubectl -n istio-system get pods -l app=istiod --show-labels
    

    A resposta será semelhante a:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
    

    Na saída, na coluna LABELS, observe o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1106-2.

  3. Aplique o rótulo de revisão ao namespace default.

    No comando a seguir, REVISION é o valor do rótulo de revisão istiod que você anotou na etapa anterior.

    kubectl label namespace default istio-injection- istio.io/rev=REVISION --overwrite
    

    Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, que é esperado em novas instalações do Anthos Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection.

  4. Implante seu aplicativo no namespace padrão usando kubectl>

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
    
  5. Confirme se o aplicativo foi implantado corretamente executando os seguintes comandos:

    kubectl get services
    

    Resposta esperada:

    NAME                       CLUSTER-IP   EXTERNAL-IP         PORT(S)              AGE
    details                    10.0.0.31    <none>        9080/TCP             6m
    kubernetes                 10.0.0.1     <none>        443/TCP              7d
    productpage                10.0.0.120   <none>        9080/TCP             6m
    ratings                    10.0.0.15    <none>        9080/TCP             6m
    reviews                    10.0.0.170   <none>        9080/TCP             6m

    e

    kubectl get pod
    

    Resposta esperada:

    NAME                                        READY     STATUS    RESTARTS   AGE
    details-v1-1520924117-48z17                 2/2       Running   0          6m
    productpage-v1-560495357-jk1lz              2/2       Running   0          6m
    ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
    reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
    reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
    reviews-v3-1813607990-8ch52                 2/2       Running   0          6m
  6. Finalmente, defina o roteamento do gateway de entrada para o aplicativo:

    kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
    

    Resposta esperada:

    gateway.networking.istio.io/bookinfo-gateway created
    virtualservice.networking.istio.io/bookinfo created
  7. Confirme se a página do produto está acessível. No comando a seguir, GATEWAY_NAMESPACE é o namespace do gateway do Istio.

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
    export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
    curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"
    

    Saída esperada:

    <title>Simple Bookstore App</title>
    

Criar instâncias do Compute Engine e instalar o MySQL

Nesta etapa, você criará um modelo de instância do Compute Engine para a instância do MySQL em execução na VM. Para etapas mais detalhadas, consulte Bookinfo com uma máquina virtual.

  1. Crie um script de inicialização para instalar o MySQL e adicionar um banco de dados de classificações após a inicialização. Observe que, se você estiver usando o CentOS, levará até 10 minutos para que o mariadb-server esteja pronto.

    Debian

    cat << "EOF" > init-mysql
    #!/bin/bash
    
    # Wait until Envoy is ready before installing mysql
    while true; do
      rt=$(curl -s 127.0.0.1:15000/ready)
      if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
        echo "envoy is ready"
        break
      fi
      sleep 1
    done
    
    # Wait until DNS is ready before installing mysql
    while true; do
      curl -I productpage.default.svc:9080
      if [[ $? -eq 0 ]]; then
        echo "dns is ready"
        break
      fi
      sleep 1
    done
    
    sudo apt-get update && sudo apt-get install -y mariadb-server
    
    sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf
    
    cat <<EOD | sudo mysql
    # Grant access to root
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
    
    # Grant root access to other IPs
    CREATE USER 'root'@'%' IDENTIFIED BY 'password';
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
    FLUSH PRIVILEGES;
    quit
    EOD
    
    sudo systemctl restart mysql
    
    curl -LO https://raw.githubusercontent.com/istio/istio/release-1.10/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    

    CentOS

    cat << "EOF" > init-mysql
    #!/bin/bash
    
    # Wait until Envoy is ready before installing mysql
    while true; do
      rt=$(curl -s 127.0.0.1:15000/ready)
      if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
        echo "envoy is ready"
        break
      fi
      sleep 1
    done
    
    # Wait until DNS is ready before installing mysql
    while true; do
      curl -I productpage.default.svc:9080
      if [[ $? -eq 0 ]]; then
        echo "dns is ready"
        break
      fi
      sleep 1
    done
    
    sudo yum update -y && sudo yum install -y mariadb-server
    
    # Wait until mysql is ready
    while true; do
      rt=$(which mysql)
      if [[ ! -z "${rt}" ]]; then
        echo "mysql is ready"
        break
      fi
      sleep 1
    done
    
    sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf
    
    sudo systemctl restart mariadb
    
    cat > grantaccess.sql << EOD
    
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
    
    CREATE USER 'root'@'%' IDENTIFIED BY 'password';
    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
    FLUSH PRIVILEGES;
    EOD
    
    until sudo mysql < grantaccess.sql; do
       sleep 1
    done
    
    sudo systemctl restart mariadb
    
    curl -LO https://raw.githubusercontent.com/istio/istio/release-1.10/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    
  2. Crie um WorkloadGroup para a carga de trabalho do MySQL

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: WorkloadGroup
    metadata:
      name: mysql
      namespace: default
    spec:
      metadata:
        labels:
          app.kubernetes.io/name: mysql
        annotations:
          security.cloud.google.com/IdentityProvider: google
      template:
        serviceAccount: WORKLOAD_SERVICE_ACCOUNT
    EOF
    
  3. Use gcloud para criar um novo modelo de instância a fim de preparar as instâncias para sua malha e incluir o script de inicialização criado acima.

    Debian

    gcloud beta compute instance-templates create asm-mysql-instance-template \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
    --project PROJECT_ID \
    --metadata-from-file=startup-script=init-mysql \
    --image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB
    

    CentOS

    gcloud beta compute instance-templates create asm-mysql-instance-template \
    --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
    --project PROJECT_ID \
    --metadata-from-file=startup-script=init-mysql \
    --image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB
    
  4. Crie um MIG do Compute Engine usando o modelo de instância recém-criado.

    gcloud compute instance-groups managed create mysql-instance \
    --template asm-mysql-instance-template \
    --zone=us-central1-c \
    --project=PROJECT_ID \
    --size=1
    

Criar um serviço

Crie um serviço do Kubernetes para o serviço do MySQL usando o seguinte comando:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: default
  labels:
    asm_resource_type: VM
spec:
  ports:
  - name: mysql
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app.kubernetes.io/name: mysql
EOF

Usar o painel da IU do Anthos

Para ver o novo serviço baseado em VM que você criou, clique em Anthos > Service Mesh na barra de navegação principal à esquerda. Será exibida uma tabela dos serviços em execução na malha. O serviço adicionado aparecerá na tabela com o valor Type de VM e algumas métricas de alto nível. Para ver mais telemetria do serviço baseado em VM, clique no nome do serviço, que exibirá o painel de nível de serviço.

Para mais informações sobre como usar o painel da IU do Anthos, consulte Como explorar o Anthos Service Mesh no Console do Cloud.

Gerenciar o tráfego para as cargas de trabalho da VM

É possível alterar as regras de rede para controlar como o tráfego entra e sai das VMs.

Controlar o tráfego para um novo serviço de classificações (pod para VM)

Crie outro serviço de classificações no Bookinfo que usará a instância do MySQL criada acima como a origem de dados e especifique uma regra de roteamento que force o serviço de análise a usar o novo serviço de classificação.

  1. Crie um novo serviço de classificação para usar a instância do MySQL.

    kubectl apply -f - << EOF
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ratings-v2-mysql-vm
      labels:
        app: ratings
        version: v2-mysql-vm
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ratings
          version: v2-mysql-vm
      template:
        metadata:
          labels:
            app: ratings
            version: v2-mysql-vm
        spec:
          serviceAccountName: bookinfo-ratings
          containers:
          - name: ratings
            image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
            imagePullPolicy: IfNotPresent
            env:
              - name: DB_TYPE
                value: "mysql"
              - name: MYSQL_DB_HOST
                value: mysql.default.svc.cluster.local
              - name: MYSQL_DB_PORT
                value: "3306"
              - name: MYSQL_DB_USER
                value: root
              - name: MYSQL_DB_PASSWORD
                value: password
            ports:
            - containerPort: 9080
    EOF
    
  2. Criar uma regra de roteamento

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - route:
        - destination:
            host: reviews
            subset: v3
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: ratings
    spec:
      hosts:
      - ratings
      http:
      - route:
        - destination:
            host: ratings
            subset: v2-mysql-vm
    EOF
    
  3. Aplique regras de destino para os serviços criados.

    kubectl apply -f - << EOF
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: reviews
    spec:
      host: reviews
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v3
        labels:
          version: v3
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: ratings
    spec:
      host: ratings
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v2-mysql
        labels:
          version: v2-mysql
      - name: v2-mysql-vm
        labels:
          version: v2-mysql-vm
    EOF
    

Como validar a implantação do aplicativo

Para ver se o aplicativo BookInfo está funcionando, envie o tráfego para o gateway de entrada.

  • Se você instalou o Anthos Service Mesh no GKE, acesse o endereço IP externo do gateway de entrada que você criou nas etapas anteriores:

    kubectl get svc istio-ingressgateway -n GATEWAY_NAMESPACE
    

    Saída:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
    istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

    Nesse exemplo, o endereço IP do serviço de entrada é 35.239.7.64.

Como testar o aplicativo

  1. Verifique se o aplicativo BookInfo está sendo executado com curl:

    curl -I http://EXTERNAL_IP/productpage
    

    Se a resposta mostrar 200, significa que o aplicativo está funcionando corretamente com o Anthos Service Mesh.

  2. Para visualizar a página da Web do BookInfo, insira o seguinte endereço no navegador:

    http://EXTERNAL_IP/productpage
    
  3. Verifique na página inicial do aplicativo Bookinfo que ele mostra cinco estrelas de Reviewer1 e quatro estrelas de Reviewer2.

Como impor a segurança nas cargas de trabalho da VM

Reforçar a segurança nas cargas de trabalho da VM é o mesmo que reforçar a segurança nas cargas de trabalho do Kubernetes. Para mais informações, consulte a página Segurança do Istio (em inglês).

Depois de concluir as etapas anteriores, a VM do Compute Engine terá um certificado de carga de trabalho emitido pelo Google. No certificado, o valor SubjectAlternativeName mostra a identidade da carga de trabalho do Anthos da VM no formato spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT.

Para mais informações, consulte Pool de identidade da carga de trabalho.

Ativar o modo rígido do mTLS para a malha

Aplique o YAML a seguir para aplicar a proteção em toda a malha mTLS.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

Autorização para tráfego entre serviços

Use AuthorizationPolicy para controlar o acesso entre os aplicativos na VM do Compute Engine e outras cargas de trabalho de malha (por exemplo, no cluster do GKE).

Exemplo: negar que as cargas de trabalho do Kubernetes acessem as VMs do Compute Engine

A política de autorização a seguir nega uma carga de trabalho ratings do Kubernetes para acessar as cargas de trabalho da VM do Compute Engine que exibem o servidor de ratingsdo MySQL.

  kubectl apply -f - << EOF
  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: mysql-deny
    namespace: default
  spec:
    selector:
      matchLabels:
        app.kubernetes.io/name: mysql
    action: DENY
    rules:
    - from:
      - source:
          principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
  EOF

Depois de aplicar o exemplo AuthorizationPolicy, você verá uma mensagem de erro Ratings service is currently unavailable na seção de classificações de livros na página do produto.

Como instalar o agente do Cloud Monitoring

É possível instalar o agente do Cloud Monitoring para coletar e monitorar as métricas do sistema e do aplicativo nas instâncias de VM. Assim, é possível monitorar as principais métricas, como o uso de CPU e memória no agente.

Para mais informações, consulte a documentação do agente do Cloud Monitoring.

Solução de problemas

Para ver dicas de solução de problemas, consulte Solução de problemas de VM.