Instale o Anthos Service Mesh

Nesta página, vamos explicar como instalar o Anthos Service Mesh no GKE e nas plataformas locais:

• Execute asmcli para fazer uma nova instalação do Anthos Service Mesh 1.12.9-asm.3.
• Como opção, implante um gateway de entrada.
• Implante ou reimplante suas cargas de trabalho para injetar proxies sidecar.

Observação: para clusters do GKE Autopilot, somente o Anthos Service Mesh gerenciado é compatível. No momento, o suporte do Anthos Service Mesh para o Autopilot do GKE está em pré-lançamento e disponível apenas nas versões 1.21.3 e posteriores.

Observação: confira instruções para preparar uma instalação off-line do Anthos Service Mesh no artigo Preparar uma instalação off-line do Anthos Service Mesh. Você precisará especificar as opções --offline e --output_dir quando executar asmcli install.

Antes de começar

Antes de começar, verifique se você:

• Revise os pré-requisitos.
• Leia as informações em Planejar a instalação.
• Instale as ferramentas necessárias.
• Download asmcli.
• Conceder permissões de administrador de cluster.
• Validar o projeto e o cluster.

Aviso: para que o Anthos Service Mesh funcione corretamente, implante istiod e canonical-service-controller-manager no cluster. Eles têm permissões elevadas de controle de acesso com base em papéis (RBAC, na sigla em inglês) e a capacidade de modificar todas as implantações e secrets do cluster. Essas permissões são necessárias para as funções do Anthos Service Mesh, como injetar arquivos secundários, descobrir serviços, proteger o tráfego, gerenciar gateways de entrada e apresentar painéis de serviços.

Instale o Anthos Service Mesh

Veja a seguir como instalar o Anthos Service Mesh:

1. Execute asmcli install para instalar o plano de controle no cluster em um único cluster. Consulte as seções a seguir para exemplos de linha de comando. Os exemplos contêm argumentos obrigatórios e argumentos opcionais que podem ser úteis. Recomendamos que você sempre especifique o argumento output_dir para poder localizar facilmente gateways e ferramentas de amostra, como istioctl. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

2. Os clusters particulares do GKE precisam de mais uma etapa de configuração de firewall para permitir o tráfego para o istiod.

3. Como opção, instale um gateway de entrada. Por padrão, asmcli não instala o istio-ingressgateway. Recomendamos que você implante e gerencie o plano de controle e os gateways separadamente. Se você precisar do istio-ingressgateway padrão instalado com o plano de controle no cluster, inclua o argumento --option legacy-default-ingressgateway.

4. Para concluir a configuração do Anthos Service Mesh, ative a injeção automática do arquivo secundário e implante ou reimplante cargas de trabalho.

5. Se você estiver instalando o Anthos Service Mesh em mais de um cluster, execute asmcli install em cada cluster. Ao executar asmcli install, use o mesmo FLEET_PROJECT_ID para cada cluster. Depois que o Anthos Service Mesh for instalado, consulte Como configurar uma malha de vários clusters.

6. Se os clusters estiverem em redes diferentes, como no modo Ilha, transmita um nome de rede exclusivo para asmcli usando a sinalização --network_id.

Instalar recursos padrão e Mesh CA

Nesta seção, mostramos como executar o asmcli para instalar o Anthos Service Mesh com os recursos compatíveis padrão e ativar a autoridade de certificação do Anthos Service Mesh (Mesh CA) como o certificado autoridade.

Observação sobre a plataforma: a AC do Mesh não é compatível com o GKE na AWS, Amazon EKS ou Microsoft AKS. Se você executar asmcli install e especificar --ca mesh_ca nessas plataformas, a instalação falhará.

GKE;

Execute o comando a seguir para instalar o plano de controle com recursos padrão e CA da malha. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
Observação: anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --enable_all Permite que o script:
  • Conceder as permissões necessárias do IAM.
  • Ative as APIs do Google necessárias.
  • Defina um rótulo no cluster que identifique a malha.
  • Registre o cluster na frota se ele ainda não estiver registrado.
• --ca mesh_ca Use o Mesh CA como a autoridade de certificação. asmcliconfigura o Mesh CA para usar a identidade da carga de trabalho da frota

Infraestrutura local

Execute os comandos a seguir no GKE no VMware ou no Google Distributed Cloud Virtual para Bare Metal para instalar o plano de controle com os recursos padrão e a CA do Mesh. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --platform multicloud Especifica que a plataforma é local.
   • --enable_all Permite que o script:
     • Conceder as permissões necessárias do IAM.
     • Ative as APIs do Google necessárias.
     • Defina um rótulo no cluster que identifique a malha.
     • Registre o cluster na frota se ele ainda não estiver registrado.
   • --ca mesh_ca Use o Mesh CA como a autoridade de certificação. asmcliconfigura o Mesh CA para usar a identidade da carga de trabalho da frota

   Para ver os SLOs e as métricas de infraestrutura na IU do Anthos Service Mesh, também é necessário executar as três primeiras etapas em Ativar a geração de registros e o monitoramento de aplicativos. Se a geração de registros e o monitoramento não estiverem ativados e não receberem registros e métricas personalizados, o painel do Anthos Service Mesh não vai mostrar SLOs, registros de erros ou métricas de CPU e memória.

Instalar recursos padrão e o serviço de autoridade de certificação (CA)

Nesta seção, mostramos como executar asmcli para instalar o Anthos Service Mesh com os recursos compatíveis padrão com sua plataforma e ativar o serviço de CA como a autoridade de certificação.

Observação sobre a plataforma: o CA Service é compatível com as seguintes plataformas: clusters do GKE no Google Cloud, GKE no VMware e GDCV para Bare Metal. Se você executar asmcli install e especificar --ca gcp_cas em outras plataformas, a instalação será bem-sucedida, mas suas cargas de trabalho não serão iniciadas.

Além da CA de malha, é possível configurar o Anthos Service Mesh para usar o Certificate Authority Service. Este guia oferece uma oportunidade de integração com o serviço de CA, o que é recomendado para os seguintes casos de uso:

• Se você precisar de autoridades de certificação diferentes para assinar certificados de carga de trabalho em clusters diferentes.
• Se você quiser usar os certificados de plug-in da CA personalizada do istiod.
• Se você precisar fazer backup das chaves de assinatura em um HSM gerenciado.
• sua empresa é altamente regulada e está sujeita a conformidade.
• Se você quiser encadear a CA do Anthos Service Mesh a um certificado raiz empresarial personalizado para assinar certificados de carga de trabalho.

O custo da CA de malha está incluído no preço do Anthos Service Mesh. O serviço de CA não está incluído no preço base do Anthos Service Mesh e é cobrado separadamente. Além disso, o serviço da CA vem com um SLA explícito, mas o CA da malha não.

Para essa integração, todas as cargas de trabalho no Anthos Service Mesh recebem papéis do IAM:

• privateca.workloadCertificateRequester
• privateca.auditor
• privateca.template (obrigatório se você estiver usando um modelo de certificado)

Configurar o serviço de CA

1. Crie o pool de CAs no nível DevOps e na mesma região que o cluster usado para evitar problemas de excesso de latência ou possíveis interrupções entre regiões. Saiba mais em Níveis otimizados para carga de trabalho.
2. Crie a CA para ter pelo menos uma autoridade certificadora ativa no pool de CAs no mesmo projeto que o cluster do GKE. Use CAs subordinadas para assinar certificados de carga de trabalho do Anthos Service Mesh. Anote o pool de CAs correspondente à CA subordinada.

3. Se você quiser usar apenas certificados de serviço para as cargas de trabalho do Anthos Service Mesh, configure a seguinte política de emissão para o pool de CAs:

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

   Observação: como prática recomendada para malhas de vários clusters, defina um pool de CAs subordinadas por região de cluster exclusiva. Todos os pools de CAs subordinadas precisam estar encadeados ao mesmo pool de CAs raiz.

4. Para atualizar a política de emissão do pool de CAs, use o seguinte comando:

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

   Para informações sobre como definir uma política em um pool, consulte Como usar uma política de emissão de certificado.

5. Se você estiver usando um modelo de certificado, configure-o agora. Para mais informações, siga o Guia de serviço de CA para certificados de identidade da carga de trabalho. Verifique se o modelo de certificado foi criado na mesma região do pool de CAs. Se houver várias regiões para pools de CAs, crie um modelo de certificado por região.

Configurar o Anthos Service Mesh para usar o serviço de CA

GKE;

1. Instale o plano de controle do Anthos Service Mesh que usa o Certificate Authority Service como a CA:

   ./asmcli install \
   --project_id PROJECT_ID \
   --cluster_name CLUSTER_NAME \
   --cluster_location CLUSTER_LOCATION \
   --enable_all \
   --ca gcp_cas \
   --ca_pool projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --platform multicloud Especifica que a plataforma é local.
   • --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 gcp_cas Use o Certificate Authority Service como autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura o Certificate Authority Service para usar a identidade da carga de trabalho da frota.
   • --ca_pool O identificador completo do pool de CAs (em inglês) do Certificate Authority Service. Se o modelo de certificado for usado, anexe o ID do modelo separado por :.

     --ca_pool projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/CA_POOL_PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID
     

2. Instale um gateway de entrada para receber conexões HTTP/TCP de entrada ou saída. Para mais detalhes, consulte Instalar gateways.

3. Conclua a instalação do Anthos Service Mesh para ativar a injeção automática de proxy sidecar nas suas cargas de trabalho. Para mais detalhes, consulte Implantar e reimplantar cargas de trabalho.

Infraestrutura local

Execute os comandos a seguir no GKE no VMware ou no Google Distributed Cloud Virtual para Bare Metal para instalar o plano de controle com os recursos padrão e o Certificate Authority Service. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
   --kubeconfig KUBECONFIG_FILE \
   --fleet_id FLEET_PROJECT_ID \
   --output_dir DIR_PATH \
   --enable_all \
   --ca gcp_cas \
   --platform multicloud \
   --ca_pool  projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --platform multicloud Especifica que a plataforma é local.
   • --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 gcp_cas Use o Certificate Authority Service como autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura o Certificate Authority Service para usar a identidade da carga de trabalho da frota.
   • --ca_pool O identificador completo do pool de CAs (em inglês) do Certificate Authority Service. Se você estiver usando um modelo de certificado, insira o ID do modelo separado por :. Exemplo:

     --ca_pool projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/CA_POOL_PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID
     

   Para ver os SLOs e as métricas de infraestrutura na IU do Anthos Service Mesh, também é necessário executar as três primeiras etapas em Ativar a geração de registros e o monitoramento de aplicativos. Se a geração de registros e o monitoramento não estiverem ativados e não receberem registros e métricas personalizados, o painel do Anthos Service Mesh não vai mostrar SLOs, registros de erros ou métricas de CPU e memória.

Instalar recursos padrão com a CA do Istio

Esta seção explica como:

• Gere certificados e chaves para a CA do Istio que o Anthos Service Mesh usa para assinar suas cargas de trabalho.
• Execute asmcli para instalar o Anthos Service Mesh com recursos padrão e ativar a CA do Istio.

Para ter a melhor segurança, recomendamos manter uma CA raiz off-line e usar as CAs subordinadas para emitir certificados para cada cluster. Para mais informações, consulte Conectar certificados de CA. Nesta configuração, todas as cargas de trabalho na malha de serviço usam a mesma autoridade de certificação raiz. Cada CA do Anthos Service Mesh usa um certificado e uma chave de assinatura de CA intermediários, assinados pela CA raiz. Quando houver várias CAs em uma malha, uma hierarquia de confiança entre as CAs será estabelecida. Repita essas etapas para provisionar certificados e chaves de qualquer quantia de autoridades de certificação.

Importante: estas etapas criam certificados e chaves usando um comando make que fornecemos apenas para fins ilustrativos. Para ter a melhor segurança, use um computador seguro off-line e ferramentas prontas para produção. Por exemplo, use o HashiCorp Vault (em inglês) para gerar e proteger com segurança a chave de assinatura da CA.

O makefile para gerar os certificados está localizado no subdiretório istio-1.12.9-asm.3 no diretório --output_dir que você especificou no comando asmcli validate. Se você não tiver executado asmcli validate ou não tiver o diretório transferido por download localmente, será possível acessar o Makefile fazendo o download do arquivo de instalação do Anthos Service Mesh e extrair o conteúdo.

1. Altere para o diretório istio-1.12.9-asm.3.

2. Crie um diretório para certificados e chaves:

   mkdir -p certs && \
   pushd certs

3. Gere um certificado raiz e uma chave:

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   Isso gera estes arquivos:

   • root-cert.pem: o certificado raiz
   • root-key.pem: a chave raiz
   • root-ca.conf: a configuração do openssl para gerar o certificado raiz
   • root-cert.csr: o CSR do certificado raiz

4. Gere um certificado intermediário e uma chave:

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   Isso gera estes arquivos em um diretório chamado cluster1:

   • ca-cert.pem: os certificados intermediários
   • ca-key.pem: a chave intermediária
   • cert-chain.pem: a cadeia de certificados que o istiod usa
   • root-cert.pem: o certificado raiz
   Observação: é possível substituir cluster1 por um nome diferente. Por exemplo, make mycluster-cacerts cria um diretório chamado mycluster.

   Se você executar essas etapas usando um computador off-line, copie o diretório gerado para um computador com acesso aos clusters.

5. Volte ao diretório anterior:

   popd

6. Execute asmcli para instalar uma malha usando a CA do Istio:

   GKE;

   Execute o comando a seguir para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

    ./asmcli install \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --fleet_id FLEET_PROJECT_ID \
      --output_dir DIR_PATH \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
   

   • --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
   • --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   Observação: anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz
   • --cert_chain: a cadeia de certificados

   Infraestrutura local

   Execute os seguintes comandos no GKE no VMware ou no Google Distributed Cloud Virtual for Bare Metal para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

   1. Defina o contexto atual para o cluster de usuário:

      kubectl config use-context CLUSTER_NAME
      

   2. Execute asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id O ID do projeto host da frota.
      • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
      • --platform multicloud Especifica que a plataforma é local.
      • --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 citadel Use a CA do Istio como autoridade de certificação.
      • --ca_cert: o certificado intermediário
      • --ca_key: a chave do certificado intermediário
      • --root_cert: o certificado raiz
      • --cert_chain: a cadeia de certificados

   AWS

   Execute os seguintes comandos no GKE na AWS para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos. É possível optar por ativar a entrada para a sub-rede pública ou particular.

   Pública

   1. Defina o contexto atual para o cluster de usuário:

      kubectl config use-context CLUSTER_NAME
      

   2. Execute asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id O ID do projeto host da frota.
      • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
      • --platform multicloud Especifica que a plataforma é local.
      • --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 citadel Use a CA do Istio como autoridade de certificação.
      • --ca_cert: o certificado intermediário.
      • --ca_key: a chave do certificado intermediário
      • --root_cert: o certificado raiz.
      • --cert_chain: a cadeia de certificados.

   Privado

   1. Defina o contexto atual para o cluster de usuário:

      kubectl config use-context CLUSTER_NAME
      

   2. Salve o seguinte YAML em um arquivo chamado istio-operator-internal-lb.yaml:

      apiVersion: install.istio.io/v1alpha1
      kind: IstioOperator
      spec:
        components:
          ingressGateways:
          - enabled: true
            k8s:
              serviceAnnotations:
                service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            name: istio-ingressgateway
      

   3. Execute asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert FILE_PATH \
        --ca_key FILE_PATH \
        --root_cert FILE_PATH \
        --cert_chain FILE_PATH
        --custom_overlay istio-operator-internal-lb.yaml \
      

      • --fleet_id O ID do projeto host da frota.
      • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
      • --platform multicloud Especifica que a plataforma é local.
      • --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 citadel Use a CA do Istio como autoridade de certificação.
      • --ca_cert: o certificado intermediário.
      • --ca_key: a chave do certificado intermediário
      • --root_cert: o certificado raiz.
      • --cert_chain: a cadeia de certificados.
      • --custom_overlay stackdriver.yaml por padrão, ambientes que instalam o Anthos Service Mesh com CA do Istio reportam métricas ao Prometheus. Se você quiser usar os painéis do Anthos Service Mesh, ative o Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

   Amazon EKS

   Execute os comandos a seguir no Amazon EKS para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

   1. Defina o contexto atual para o cluster de usuário:

      kubectl config use-context CLUSTER_NAME
      

   2. Execute asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id O ID do projeto host da frota.
      • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
      • --platform multicloud Especifica que a plataforma é local.
      • --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 citadel Use a CA do Istio como autoridade de certificação.
      • --ca_cert: o certificado intermediário
      • --ca_key: a chave do certificado intermediário
      • --root_cert: o certificado raiz
      • --cert_chain: a cadeia de certificados

   Microsoft AKS

   Execute os seguintes comandos no Microsoft AKS para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

   1. Defina o contexto atual para o cluster de usuário:

      kubectl config use-context CLUSTER_NAME
      

   2. Execute asmcli install:

      HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Permite o registro com o GKE Hub.
      Observação: para permitir registros com o GKE Hub, use esta sinalização porque os clusters do AKS não têm um endpoint de descoberta de OIDCs publicamente roteáveis para o token da conta de serviço do Kubernetes.
      • --fleet_id O ID do projeto host da frota.
      • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
      • --platform multicloud Especifica que a plataforma é local.
      • --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 citadel Use a CA do Istio como autoridade de certificação.
      • --ca_cert: o certificado intermediário
      • --ca_key: a chave do certificado intermediário
      • --root_cert: o certificado raiz
      • --cert_chain: a cadeia de certificados

Instalar com a CA do Istio com a observabilidade do Google Cloud ativada

Se você quiser usar os painéis do Anthos Service Mesh, ative o Stackdriver.

GKE;

Execute o comando a seguir para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

./asmcli install \
   --project_id PROJECT_ID \
   --cluster_name CLUSTER_NAME \
   --cluster_location CLUSTER_LOCATION \
   --fleet_id FLEET_PROJECT_ID \
   --output_dir DIR_PATH \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  Observação:anote esse diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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 citadel Use a CA do Istio como autoridade de certificação.
• --ca_cert: o certificado intermediário
• --ca_key: a chave do certificado intermediário
• --root_cert: o certificado raiz
• --cert_chain: a cadeia de certificados
• --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

Infraestrutura local

Execute os seguintes comandos no GKE no VMware ou no Google Distributed Cloud Virtual para Bare Metal para instalar o plano de controle com o Stackdriver e outros recursos opcionais e a CA do Istio. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --platform multicloud \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz
   • --cert_chain: a cadeia de certificados
   • --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

   Para ver os SLOs e as métricas de infraestrutura na IU do Anthos Service Mesh, também é necessário executar as três primeiras etapas em Ativar a geração de registros e o monitoramento de aplicativos. Se a geração de registros e o monitoramento não estiverem ativados e não receberem registros e métricas personalizados, o painel do Anthos Service Mesh não vai mostrar SLOs, registros de erros ou métricas de CPU e memória.

AWS

Execute os seguintes comandos nos GKE na AWS para instalar o plano de controle com o Stackdriver e outros recursos opcionais e a CA do Istio. Digite os valores nos marcadores fornecidos. É possível optar por ativar a entrada para a sub-rede pública ou privada.

Pública

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert CA_CERT_FILE_PATH \
     --ca_key CA_KEY_FILE_PATH \
     --root_cert ROOT_CERT_FILE_PATH \
     --cert_chain CERT_CHAIN_FILE_PATH \
     --option stackdriver
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário.
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz.
   • --cert_chain: a cadeia de certificados.
   • --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

Privado

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Salve o seguinte YAML em um arquivo chamado istio-operator-internal-lb.yaml:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml \
     --option stackdriver
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário.
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz.
   • --cert_chain: a cadeia de certificados.
   • --custom_overlay: o nome do arquivo de sobreposição criado. Para mais informações sobre arquivos de sobreposição, consulte Como ativar recursos opcionais no plano de controle no cluster
   • --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver. Como alternativa, é possível ativar o Stackdriver usando --custom_overlay stackdriver.yaml. Você precisa fazer o download do anthos-service-mesh-package ou criar stackdriver.yaml no manifesto fornecido.

Amazon EKS

Execute os comandos a seguir no Amazon EKS para instalar o plano de controle com o Stackdriver e outros recursos opcionais e a CA do Istio. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert CA_CERT_FILE_PATH \
     --ca_key CA_KEY_FILE_PATH \
     --root_cert ROOT_CERT_FILE_PATH \
     --cert_chain CERT_CHAIN_FILE_PATH \
     --option stackdriver
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz
   • --cert_chain: a cadeia de certificados
   • --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

Microsoft AKS

Execute os seguintes comandos no Microsoft AKS para instalar o plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert CA_CERT_FILE_PATH \
     --ca_key CA_KEY_FILE_PATH \
     --root_cert ROOT_CERT_FILE_PATH \
     --cert_chain CERT_CHAIN_FILE_PATH \
     --option stackdriver
   

   • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Permite o registro com o GKE Hub.
   Observação: para permitir registros com o GKE Hub, use esta sinalização porque os clusters do AKS não têm um endpoint de descoberta de OIDCs publicamente roteáveis para o token da conta de serviço do Kubernetes.
   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 citadel Use a CA do Istio como autoridade de certificação.
   • --ca_cert: o certificado intermediário
   • --ca_key: a chave do certificado intermediário
   • --root_cert: o certificado raiz
   • --cert_chain: a cadeia de certificados
   • --option stackdriver ativa a opção do Stackdriver. Também é possível ativar o Stackdriver e o Prometheus usando --option prometheus-and-stackdriver.

Instalar com recursos opcionais

Um arquivo de sobreposição é um arquivo YAML contendo um recurso personalizado (CR) IstioOperator que você passa para asmcli para configurar o plano de controle. É possível substituir a configuração do plano de controle padrão e ativar um recurso opcional transmitindo o arquivo YAML para asmcli. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores. Como prática recomendada, salve os arquivos de sobreposição no seu sistema de controle de versões.

GKE;

Execute o comando a seguir para instalar o plano de controle com um recurso opcional. Para adicionar vários arquivos, especifique --custom_overlay e o nome do arquivo. Por exemplo: --custom_overlay overlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml Insira seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
Observação: anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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 a Mesh CA como a autoridade de certificação. Observe que asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
• --custom_overlay especifica o nome do arquivo de sobreposição.

Fora do Google Cloud

Execute os seguintes comandos no GKE no VMware, no Google Distributed Cloud Virtual for Bare Metal, no GKE na AWS, no Amazon EKS ou no Microsoft AKS. Digite seus valores nos marcadores fornecidos.

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install para instalar o plano de controle com um recurso opcional. Para adicionar vários arquivos, especifique --custom_overlay e o nome do arquivo, por exemplo: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui.
   • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --platform multicloud Especifica que a plataforma é local.
   • --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 a Mesh CA como a autoridade de certificação. Observe que asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
   • --custom_overlay especifica o nome do arquivo de sobreposição.

Instalar gateways

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

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

   kubectl create namespace GATEWAY_NAMESPACE
   

   Saída esperada:

   namespace/GATEWAY_NAMESPACE created
   

2. Ativar a injeção automática no gateway. As etapas necessárias dependem do uso de rótulos de injeção padrão (por exemplo, istio-injection=enabled) ou do rótulo de revisão no namespace do gateway. A tag de revisão e o rótulo de revisão padrão são usados pelo webhook do injetor do sidecar para associar os proxies injetados a uma revisão específica do plano de controle.

   Rótulos de injeção padrão

   Observação: se você usou uma tag de revisão padrão para ativar a injeção automática no gateway, verifique se a tag padrão existe no diretório especificado em --output_dir e está apontando para a revisão recém-instalada. Execute o comando DIR_PATH/istioctl tag list.

   Aplique os rótulos de injeção padrão ao namespace.

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

   Rótulo de revisão

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

      kubectl get deploy -n istio-system -l app=istiod -o \
        "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
      

      O comando gera o rótulo de revisão que corresponde à versão do Anthos Service Mesh, por exemplo: asm-1129-3

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

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

      Resposta esperada:

      namespace/GATEWAY_NAMESPACE labeled
      

3. É 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 DIR_PATH/samples/gateways/istio-ingressgateway
   

   Saída esperada:

   deployment.apps/istio-ingressgateway created
   poddisruptionbudget.policy/istio-ingressgateway created
   horizontalpodautoscaler.autoscaling/istio-ingressgateway created
   role.rbac.authorization.k8s.io/istio-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
   service/istio-ingressgateway created
   serviceaccount/istio-ingressgateway created
   

Saiba mais sobre as práticas recomendadas para gateways.

Implantar e reimplantar cargas de trabalho

O Anthos Service Mesh usa proxies sidecar para aumentar a segurança, a confiabilidade e a observabilidade da rede. Com o Anthos Service Mesh, essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo, entregue como um contêiner separado no mesmo pod.

A instalação não será concluída até que você ative a injeção automática de proxy de arquivo secundário (injeção automática) e reinicie os pods de todas as cargas de trabalho que estavam sendo executadas no cluster antes de instalar o Anthos Service Mesh.

Para ativar a injeção automática, rotule seus namespaces com os rótulos de injeção padrão se a tag padrão estiver configurada ou com um rótulo de revisão que foi definido em istiod quando você instalou o Anthos Service Mesh. A tag de revisão padrão e o rótulo de revisão são usados pelo webhook do injetor do sidecar para associar sidecars injetados a uma revisão istiod. Depois de adicionar o rótulo, todos os pods atuais no namespace precisarão ser reiniciados para que os arquivos secundários sejam injetados.

Antes de implantar novas cargas de trabalho em um novo namespace, configure a injeção automática para que o Anthos Service Mesh possa monitorar e proteger o tráfego.

1. As etapas necessárias para ativar a injeção automática dependem do rótulo de injeção padrão ou da revisão:

   Rótulos de injeção padrão

   Observação: se você usou uma tag de revisão padrão para ativar a injeção automática no gateway, verifique se a tag padrão existe no diretório especificado em --output_dir e está apontando para a revisão recém-instalada. Execute o comando DIR_PATH/istioctl tag list.

   No comando a seguir, NAMESPACE é o nome do namespace em que você quer ativar a injeção automática.

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

   Como os rótulos de injeção padrão injetarão a revisão que a tag padrão aponta, não é necessário rotular novamente os namespaces.

   Rótulo de revisão

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

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

      A resposta será semelhante a:

      NAME                                READY   STATUS    RESTARTS   AGE   LABELS
      istiod-asm-1129-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1129-3,istio=istiod,pod-template-hash=5788d57586
      istiod-asm-1129-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1129-3,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-1129-3.

   2. Aplique o rótulo de revisão e remova o rótulo istio-injection, se ele existir. No comando a seguir, NAMESPACE é o nome do namespace em que você quer ativar a injeção automática, e REVISION é o rótulo de revisão que você anotou na etapa anterior.

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

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

2. Se as cargas de trabalho estavam em execução no cluster antes de instalar o Anthos Service Mesh, reinicie os pods para acionar a nova injeção.

   A maneira como você reinicia os pods depende do seu aplicativo e do ambiente em que o cluster está. Por exemplo, no seu ambiente de preparo, basta excluir todos os pods, o que faz com que eles sejam reiniciados. Mas no ambiente de produção, há um processo que implementa uma implantação azul-verde para que você possa reiniciar os pods com segurança para evitar a interrupção do tráfego.

   É possível usar kubectl para executar uma reinicialização gradual:

   kubectl rollout restart deployment -n NAMESPACE
   

A seguir

• Saiba como configurar uma malha de vários clusters:

  • Se sua malha consistir inteiramente em clusters do GKE, consulte Configurar uma malha de vários clusters no GKE.

  • Se sua malha consistir em clusters fora do Google Cloud, consulte Configurar uma malha de vários clusters fora do Google Cloud.

• Configure um endereço IP externo no local.

• Implantar o aplicativo de amostra Online Boutique