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 oWorkloadGroup
e direcionar o tráfego do ASM para a instância de VM de maneira semelhante a umPod
. 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.
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.
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
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
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 comoasm_vm
. Se você receber um erro informando que--ignore-missing
não existe, execute novamente o comando anterior sem a sinalização--ignore-missing
.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
Use
gcloud
para configurar a ferramentakubectl
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:
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 noWorkloadGroup
e as novas respostas automáticasWorkloadEntry
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 cominstall_asm
incluirão isso por padrão.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.Instalação do CRD
IdentityProvider
e registro de uma resposta automática doIdentityProvider
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.Registre o cluster em uma frota e ative a identidade da carga de trabalho se usar
--enable_all
ou--enable_registration
no scriptinstall_asm
.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:
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.
Crie o namespace para as cargas de trabalho da VM, se ainda não houver um:
kubectl create ns WORKLOAD_NAMESPACE
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
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.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 scriptasm_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. 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.
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
.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
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).
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:
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
Na saída, na coluna
LABELS
, observe o valor no rótulo de revisãoistiod
para a nova versão, que segue o prefixoistio.io/rev=
. Neste exemplo, o valor éasm-198-6
.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 doistiod
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 deistiod
édefault
.
Adicione o rótulo de revisão a um namespace e remova o rótulo
istio-injection
, se ele existir. No comando a seguir, altereREVISION
para o valor que corresponda à nova revisão deistiod
.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ótuloistio-injection
anteriormente. Como a injeção automática falha se um namespace tiver oistio-injection
e o rótulo de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do rótuloistio-injection
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
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
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.
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
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
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
.
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.
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ãoistiod
, que segue o prefixoistio.io/rev=
. Neste exemplo, o valor éasm-198-6
.Aplique o rótulo de revisão ao namespace
default
. No comando a seguir,REVISION
é o valor do rótulo de revisãoistiod
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ótuloistio-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 oistio-injection
e o rótulo de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do rótuloistio-injection
.Implante seu aplicativo no namespace padrão usando
kubectl
>kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
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
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
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.
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
Crie um
WorkloadGroup
para a carga de trabalho do MySQLkubectl 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
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
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.
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.
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
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
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
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.Para visualizar a página da Web do BookInfo, insira o seguinte endereço no navegador:
http://EXTERNAL_IP/productpage
Verifique na página inicial do aplicativo Bookinfo que ele mostra cinco estrelas de
Reviewer1
e quatro estrelas deReviewer2
.
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 ratings
do 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.