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 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 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:
- Instale as ferramentas necessárias
- Fazer o download de
asmcli
- Conceder permissões de administrador de cluster
- Validar o projeto e o cluster
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 queasmcli
faz o download do pacoteanthos-service-mesh
e extrai o arquivo de instalação, que contémistioctl
, amostras e manifestos. Caso contrário,asmcli
fará o download dos arquivos para um diretóriotmp
. É 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.asmcli
configura 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:
Registre o cluster na frota, caso ainda não tenha feito isso.
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:
Ativação do registro automático da VM: isso é feito definindo as variáveis
PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION
ePILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY
como verdadeiras. 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+ instalados comasmcli
terão o registro automático de VM ativado 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 restante da malha de serviço.Registre o cluster em uma frota e ative a identidade da carga de trabalho se usar
--enable_all
ou--enable_registration
no scriptasmcli
.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.
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
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.
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ãoistiod
, que segue o prefixoistio.io/rev=
. Neste exemplo, o valor éasm-1106-2
.Aplique o rótulo de revisão ao namespace. No comando a seguir,
REVISION
é o valor do rótulo de revisãoistiod
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ó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
Altere para o diretório especificado em
--output_dir
.É 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:
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.
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
. OIdentityProvider
informa ao plano de controle como autenticar a credencial da VM e onde extrair a conta de serviço da VM.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
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 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
.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.
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:
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
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-1106-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 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
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
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 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.
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
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 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ãoistiod
, que segue o prefixoistio.io/rev=
. Neste exemplo, o valor éasm-1106-2
.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. 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.
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
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
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
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.
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 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
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.