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.