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

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 diminuir ou escalonar o número de cargas de trabalho nas instâncias do Compute Engine, começando por um tamanho mínimo de MIG de zero, consulte Como escalonar grupos de instâncias automaticamente.

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, verifique os pré-requisitos a seguir.

Clusters

Nesta página, você verá a opção para instalar o Anthos Service Mesh como parte das etapas ou atualizar um cluster que já tenha o Anthos Service Mesh instalado. Em ambos os casos, essas etapas exigem o Anthos Service Mesh 1.9 e um cluster que atenda a estes requisitos. Além disso, o suporte da VM do Anthos Service Mesh tem outros requisitos:

  • O plano de controle precisa ser instalado em um cluster que você controla. Os planos de controle gerenciados pelo Google não são compatíveis. Para mais informações, consulte Planos de controle gerenciados pelo Google.
  • Usar a Mesh CA como a autoridade de certificação.
  • Usar o Stackdriver para telemetria.
  • Ter a implantação de Serviço canônico ativada, que o processo de instalação do Anthos Service Mesh ativa automaticamente.

O cluster precisa estar registrado em uma frota. No entanto, se ele ainda não estiver registrado, o processo de instalação da VM poderá registrá-lo para você no projeto especificado.

Se você for assinante do GKE Enterprise, ative a API GKE Enterprise.

Ativar a API

Ferramentas da CLI

O processo de instalação requer as ferramentas a seguir, que já estão instaladas se você usa o Google Cloud Shell:

  • gcloud
  • kubectl
  • kpt
  • curl
  • jq
  • awk
  • printf
  • tr
  • grep
  • tail

Como fazer o download do script

Nesta seção, descrevemos como fazer o download do script para integração da VM.

  1. Faça o download do script de VM para o Anthos Service Mesh 1.9.8 no diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm

  2. Faça o download do SHA-256 do arquivo para o diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256

  3. Com os dois arquivos no mesmo diretório, verifique o download:

    sha256sum -c --ignore-missing asm_vm.sha256

    Quando a verificação acabar, o comando gerará: asm_vm: OK

    Para compatibilidade, o arquivo asm_vm.sha256 inclui a soma de verificação duas vezes para permitir que qualquer versão do script seja renomeada como asm_vm. Se você receber um erro informando que --ignore-missing não existe, execute novamente o comando anterior sem a sinalização --ignore-missing.

  4. Torne o script executável:

    chmod +x asm_vm

Como começar

Nesta seção, explicamos as etapas para adicionar instâncias do Compute Engine ao Anthos Service Mesh.

Configure o ambiente

  1. Use gcloud para configurar a ferramenta kubectl para apontar para o cluster especificado, porque algumas das etapas abaixo exigem que você faça alterações diretamente no cluster.

    gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID

Preparar o cluster

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

Escolha a próxima etapa dependendo se o Anthos Service Mesh 1.9 ou posterior já estiver instalado no cluster.

Não instalado

Se o Anthos Service Mesh 1.9 ou posterior não tiver sido instalado no cluster, o exemplo a seguir mostra como adicionar as opções vm e hub-meshca para modificar as etapas típicas da instalação do Anthos Service Mesh fornecidas em Instalação, migração e upgrade do GKE. Você também aprenderá a fazer o download do script install_asm usado no exemplo a seguir.

Depois de fazer o download do script install_asm, instale o Anthos Service Mesh no cluster incluindo as sinalizações --option hub-meshca, --option vm e --enable_all. Para mais informações, consulte ativar a CA da malha com frotas e Sinalizações de ativação.

./install_asm --project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install --option vm --option hub-meshca \
--enable_all

Instalado

Se o Anthos Service Mesh 1.9 ou posterior já tiver sido instalado no cluster e a Mesh CA com frota estiver ativada, atualize o plano de controle do Anthos Service Mesh para aceitar cargas de trabalho baseadas em VM. O script também ajuda a verificar se a instalação do Anthos Service Mesh no cluster está pronta para as cargas de trabalho da VM. Especificamente, o subcomando prepare_cluster atualiza todas as revisões no Anthos Service Mesh 1.9 ou posterior para que fiquem prontas para as cargas de trabalho da VM.

Se a Mesh CA com frota não estiver ativada na instalação do Anthos Service Mesh 1.9 ou posterior; reinstale ou faça upgrade da instalação do Anthos Service Mesh 1.9 ou posterior incluindo as sinalizações --option hub-meshca e --option vm no script install_asm.

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

As etapas anteriores realizaram as seguintes ações:

  1. Ativar o registro automático da VM: isso é feito definindo a variável PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION como verdadeira. 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 ou posterior instalados com install_asm incluirão isso 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 resto da malha de serviços.

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

  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.

Adicionar VMs

Nesta seção, você adiciona instâncias do Compute Engine à malha com base no modelo de instância criado com o script asm_vm. O script gera apenas a configuração necessária para o agente do proxy de serviço. Para incluir mais configurações no modelo de instância, crie um modelo de instância de origem e adicione-o ao script.

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.
    • SOURCE_INSTANCE_TEMPLATE é o nome do modelo que servirá de base para o modelo gerado. Opcional.

  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. Execute o script asm_vm com as opções e sinalizações a seguir para criar um modelo de instância para as instâncias do Compute Engine do Anthos Service Mesh.

    O script 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 você tem um modelo de instância existente no qual quer basear o script, é possível especificar a opção --source_instance_template. Se você quiser adicionar VMs não padrão ao Anthos Service Mesh, crie um modelo de instância com a distribuição do SO pretendida e use esse modelo como o valor para a sinalização --source_instance_template no script asm_vm. Se o modelo de instância atual 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.

    ./asm_vm create_gce_instance_template \
ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

    Opções

    Opção Descrição
    -p|--project_id PROJECT_ID O ID do projeto em que o cluster foi criado.
    -n|--cluster_name CLUSTER_NAME O nome do cluster.
    -l|--cluster_location CLUSTER_LOCATION A zona (nos clusters de zona única) ou a região (nos clusters regionais) em que o cluster foi criado.
    -w|--workload_name WORKLOAD_NAME O nome da carga de trabalho que as instâncias do Compute Engine representam.
    --workload_namespace WORKLOAD_NAMESPACE Opcional. O namespace da carga de trabalho. O padrão é `default`.
    -s|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME Opcional. Um modelo de instância existente para usar como base para o modelo de instância do Compute Engine do Anthos Service Mesh. Se não for especificado, um modelo de instância com valores padrão será criado.

    Sinalizações

    Sinalização Descrição
    -v|--verbose Imprime comandos antes e depois da execução.
    --dry_run Imprime comandos, mas não os executa.
    --only_validate Executa a validação, mas não cria um novo modelo de instância do Compute Engine.
    -h|--help Mostra uma mensagem de ajuda que descreve as opções, sinalizações e saída.

  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 diminuir ou escalonar o número de cargas de trabalho nas instâncias do Compute Engine, começando por um tamanho de MIG regional ou zonal 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.

Upgrade do plano de controle do Anthos Service Mesh

Atualize o plano de controle do Anthos Service Mesh para uma nova versão usando as instruções em Como fazer upgrade do Anthos Service Mesh para a versão mais recente. Depois de instalar uma nova versão do plano de controle do Anthos Service Mesh, reimplante as cargas de trabalho do Kubernetes usando as instruções em Como implantar e reimplantar cargas de trabalho.

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-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,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-198-6.

    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 o script asm_vm. Use um novo nome de modelo de instância e inclua o mesmo modelo de instância de origem, se tiver um para a mesma carga de trabalho.

    ./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

  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 no modelo de instância de origem, 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 o script asm_vm. Certifique-se de usar um novo nome de modelo de instância e inclua o novo modelo de instância de origem, se tiver criado um para a atualização do aplicativo.

    ./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE

  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 de arquivo secundário automática, use o seguinte comando 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-198-6-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
istiod-asm-198-6-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-198-6,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-198-6.

  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.

    export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system 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>"

    Resposta 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. Criar um modelo de instância do Compute Engine que inclua um script de inicialização para instalar o MySQL e adicionar um banco de dados de classificações na 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

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.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image=debian-10-buster-v20201014 \
--image-project=debian-cloud \
--boot-disk-size=10GB

    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

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.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud \
--image-family=centos-8 \
--boot-disk-size=30GB

  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 o script da VM acima para criar um novo modelo de instância que prepara as instâncias para a malha.

    ./asm_vm create_gce_instance_template \
asm-mysql-instance-template \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name mysql \
--source_instance_template mysql-instance-template

  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.

  1. Crie um serviço do Kubernetes 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 istio-system

    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.