Instalar o Cloud Service Mesh para cargas de trabalho do Kubernetes fora do Google Cloud

Nesta página, explicamos como instalar o Cloud Service Mesh no cluster para Cargas de trabalho do Kubernetes fora do Google Cloud:

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

Se você precisar instalar o Cloud Service Mesh no cluster não gerenciado com uma plano de controle istiod no GKE, consulte Instalar o Cloud Service Mesh no cluster no Google Cloud. Para cargas de trabalho do Kubernetes Google Cloud, recomendamos provisionando um plano de controle gerenciado

Para instruções sobre como preparar uma instalação off-line do Cloud Service Mesh, consulte Preparar uma instalação off-line do Cloud Service Mesh. Você precisará especificar as opções --offline e --output_dir ao executar asmcli install.

Limitações

Observe as seguintes limitações:

  • Todos os clusters do Cloud Service Mesh de uma malha precisam ser registrados no mesmo frota para usar o Cloud Service Mesh. Outros clusters no projeto de um cluster do Cloud Service Mesh não podem ser registrados em uma frota diferente.

  • A ferramenta asmcli precisa ter acesso ao endpoint do Google Kubernetes Engine (GKE). É possível configurar o acesso por meio de um servidor"salto", como uma VM do Compute Engine na nuvem privada virtual (VPC) que dá acesso específico.

Antes de começar

Antes de começar, verifique se você:

Papéis necessários para instalar o Cloud Service Mesh no cluster

A tabela a seguir descreve os papéis necessários para instalar o Cloud Service Mesh no cluster.

Nome da função ID do papel Conceder local Descrição
Administrador do GKE Hub roles/gkehub.admin Projeto da frota Acesso total ao GKE Hub e recursos relacionados.
Administrador do Kubernetes Engine roles/container.admin Projeto do cluster. Esse papel precisa ser concedido na frota e no projeto do cluster para vinculações entre projetos. Dá acesso ao gerenciamento total de clusters do Container e dos objetos da API Kubernetes deles.
Administrador de configuração de malha roles/meshconfig.admin Projeto de frotas e clusters Concede permissões necessárias para inicializar componentes gerenciados do Cloud Service Mesh, como o plano de controle gerenciado e a permissão de back-end que permite que as cargas de trabalho se comuniquem com o Stackdriver sem que cada uma seja autorizada individualmente (para planos de controle gerenciados e no cluster).
Administrador de projetos do IAM roles/resourcemanager.projectIamAdmin Projeto do cluster Concede permissões para administrar as políticas do IAM em projetos.
Administrador de contas de serviço roles/iam.serviceAccountAdmin Projeto da frota Faça a autenticação como uma conta de serviço.
servicemanagement.admin roles/servicemanagement.admin Projeto da frota Controle completo dos recursos do Google Service Management.
Administrador do Service Usage roles/serviceusage.serviceUsageAdmin Projeto da frota Pode ativar, desativar e inspecionar estados de serviço, inspecionar operações, consumir cota e gerar faturamento para o projeto de um consumidor.(Observação 1)
Administrador de serviço de CABeta roles/privateca.admin Projeto da frota Acesso completo a todos os recursos de serviço de CA. (Observação 2)

Observações:

  1. Administrador do Service Usage: esse papel é necessário como um pré-requisito para ativar a API mesh.googleapis.com ao provisionando inicialmente o Cloud Service Mesh gerenciado.
  2. Administrador de serviço de CA: esse papel só será necessário se você estiver fazendo a integração com o serviço de CA.

Instalar o Cloud Service Mesh

Confira a seguir como instalar o Cloud 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 que é possível localizar gateways e ferramentas de amostra, como istioctl. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

  2. 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.

  3. Para concluir a configuração do Cloud Service Mesh, você precisa ativar injeção de arquivo secundário e implantar ou reimplantar cargas de trabalho.

  4. Se você estiver instalando o Cloud 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. Após a instalação do Cloud Service Mesh, consulte as instruções para configurar uma malha de vários clusters fora do Google Cloud.

  5. Se os clusters estiverem em redes diferentes (como estão modo Ilha transmita um nome de rede exclusivo para asmcli usando o --network_id.

Instalar recursos padrão e Mesh CA

Nesta seção, mostramos como executar asmcli para instalar o Cloud Service Mesh com a recursos compatíveis padrão com sua plataforma e ativar Autoridade de certificação do Cloud Service Mesh como autoridade certificadora.

No local

Execute os comandos a seguir no Google Distributed Cloud (somente software) para VMware ou no Google Distributed Cloud (somente software) para bare metal para instalar o plano de controle com recursos padrão e a autoridade certificadora do Cloud Service 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. 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 mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. asmcliconfigura a autoridade certificadora do Cloud Service Mesh para usar a identidade da carga de trabalho da frota

Para acessar os SLOs e as métricas de infraestrutura na interface do Cloud Service Mesh, você precisa realizar também as três primeiras etapas Ative 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 o painel do Cloud Service Mesh não exibirá SLOs, registros de erros ou e métricas de memória.

AWS

Execute os seguintes comandos no GKE na AWS para instalar o plano de controle com recursos padrão e a autoridade certificadora do Cloud Service 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. 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 mesh_ca Usar a autoridade certificadora do Cloud Service Mesh como autoridade certificadora. asmcliconfigura Autoridade certificadora do Cloud Service Mesh a ser usada frotas a identidade da carga de trabalho.

Para conferir os SLOs e as métricas de infraestrutura na interface do Cloud 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 o painel do Cloud Service Mesh não exibirá SLOs, registros de erros ou e métricas de memória.

Azure

Execute os comandos a seguir no GKE no Azure para: instalar o plano de controle com os recursos padrão e a autoridade de certificação do Cloud Service 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. 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 mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade de certificação. asmcli configura a autoridade certificadora do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.

Para conferir os SLOs e as métricas de infraestrutura na interface do Cloud Service Mesh, também é necessário realizar 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 Cloud Service Mesh não vai mostrar SLOs, registros de erros ou métricas de CPU e memória.

Amazon EKS

Execute os comandos a seguir no Amazon EKS para instalar o plano de controle com recursos padrão e a autoridade certificadora do Cloud Service 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 \
      --option attached-cluster \
      --network_id default \
      --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. 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.
    • --option attached-cluster muda o utilitário de assinatura padrão para ser istiod.
    • --network_id Se você estiver configurando uma malha de várias redes, defina --network_id como um valor exclusivo para cada cluster na malha.
    • --ca mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade de certificação. asmcli configura a autoridade certificadora do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.

Para conferir os SLOs e as métricas de infraestrutura na interface do Cloud 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 o painel do Cloud Service Mesh não exibirá SLOs, registros de erros ou e métricas de memória.

Microsoft AKS

Execute os comandos a seguir no Microsoft AKS para instalar o plano de controle com recursos padrão e a autoridade certificadora do Cloud Service 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:

    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 \
      --option attached-cluster \
      --network_id default \
      --ca mesh_ca
    
    • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Permite o registro com o GKE Hub.
    • --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.
    • --option attached-cluster muda o utilitário de assinatura padrão para ser istiod.
    • --network_id Se você estiver configurando uma malha de várias redes, defina --network_id como um valor exclusivo para cada cluster na malha.
    • --ca mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade de certificação. asmcli configura a autoridade certificadora do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.

Para visualizar SLOs e métricas de infraestrutura na interface do Cloud Service Mesh, você precisa realizar também as três primeiras etapas Ative 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 Cloud 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 o asmcli para instalar o Cloud Service Mesh com os recursos compatíveis padrão para sua plataforma e ativar o serviço de AC como a autoridade de certificação.

Além da autoridade certificadora do Cloud Service Mesh, é possível configurar o Cloud 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ê 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 Cloud Service Mesh a uma raiz corporativa personalizada para assinar certificados de carga de trabalho.

O custo da autoridade certificadora do Cloud Service Mesh está incluído no preço do Cloud Service Mesh. O O CA Service não está incluído no preço base do Cloud Service Mesh e é cobrados separadamente. Além disso, CA Service vem com um SLA explícito, mas a autoridade de certificação do Cloud Service Mesh não faz isso.

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 ACs subordinadas para assinar certificados de carga de trabalho do Cloud 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 Cloud Service Mesh, configure a seguinte política de emissão para o pool de ACs:

    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/") )
    
  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 Cloud Service Mesh para usar o serviço de CA

Execute os comandos a seguir no Google Distributed Cloud (somente software) para VMware ou Google Distributed Cloud (somente software) para bare metal para instalar o plano de controle com recursos padrão e 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. 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 gcp_cas Use o Certificate Authority Service como a autoridade de certificação. Alterar autoridades certificadoras durante uma gera inatividade. asmcliconfigura Certificate Authority Service que será usado frota identidade da carga de trabalho
    • --ca_pool O identificador completo do pool de CA (link 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 conferir os SLOs e as métricas de infraestrutura na interface do Cloud Service Mesh, também é necessário realizar 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 o painel do Cloud Service Mesh não exibirá SLOs, registros de erros ou e métricas de 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 Cloud Service Mesh usa para para assinar suas cargas de trabalho.
  • Execute asmcli para instalar o Cloud Service Mesh com recursos padrão e ativar a CA do Istio.

Por padrão, os ambientes que instalam o Cloud Service Mesh com o Istio CA reportam métricas para o Prometheus. Se você quiser usar os painéis do Cloud Service Mesh, ative Stackdriver. Para mais informações, consulte Instalar com recursos opcionais.

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 Cloud Service Mesh usa uma AC intermediária chave de assinatura e certificado, 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.

O makefile para gerar os certificados está localizado no subdiretório istio-1.22.5-asm.1 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 Cloud Service Mesh e extraindo o conteúdo.

  1. Altere para o diretório istio-1.22.5-asm.1.

  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

    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:

    No local

    Execute os seguintes comandos no Google Distributed Cloud (somente software) para VMware ou no Google Distributed Cloud (somente software) para 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. 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

    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úblico

    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.

    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. 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

    Azure

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

    Público

    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.

    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. 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

    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 \
        --option attached-cluster \
        --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 \
        --network_id default
      
      • --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.
      • --option attached-cluster muda o utilitário de assinatura padrão para ser istiod.
      • -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
      • --network_id Se você estiver configurando uma malha de várias redes, defina --network_id como um valor exclusivo para cada cluster na malha.

    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 \
        --option attached-cluster \
        --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 \
        --network_id default
      
      • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Permite o registro com o GKE Hub.
      • --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.
      • --option attached-cluster muda o utilitário de assinatura padrão para ser istiod.
      • -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
      • --network_id Se você estiver configurando uma malha de várias redes, defina --network_id como um valor exclusivo para cada cluster na malha.

Instalar com a CA do Istio com o Google Cloud Observability ativado

Para usar os painéis do Cloud Service Mesh, ative o Stackdriver.

No local

Execute os comandos a seguir no Google Distributed Cloud (somente software) para VMware ou Google Distributed Cloud (somente software) 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 visualizar SLOs e métricas de infraestrutura na interface do Cloud Service Mesh, você precisa realizar também as três primeiras etapas Ative 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 Cloud 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úblico

  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.

Azure

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

Público

  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 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 \
      --option attached-cluster
    
    • --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.
    • --option stackdriver muda o utilitário de assinatura padrão para ser istiod.

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 \
      --option attached-cluster
    
    • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Permite o registro com o GKE Hub.
    • --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.
    • --option stackdriver muda o utilitário de assinatura padrão para ser istiod.

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.

Há duas opções para ativar os recursos opcionais: --option e --custom_overlay.

Use --option se não precisar mudar o arquivo de sobreposição. Com esse método, asmcli busca o arquivo no repositório do GitHub para você.

Use --custom_overlay quando precisar personalizar o arquivo de sobreposição.

Para mais informações, consulte Como ativar recursos opcionais no plano de controle no cluster.

Execute os comandos a seguir no Google Distributed Cloud (somente software) para VMware. Google Distributed Cloud (somente software) para bare metal, GKE na AWS, GKE no Azure, o Amazon EKS, ou 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. 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 mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Observe que asmcli configura Autoridade certificadora do Cloud Service Mesh a ser usada frota identidade da carga de trabalho
    • --custom_overlay especifica o nome do arquivo de sobreposição.

Instalar gateways

O Cloud 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.

    1. Se você usou uma revisão de tag 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 se ela está apontando para a revisão recém-instalada.

      DIR_PATH/istioctl tag list
      
    2. 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 Cloud Service Mesh, por exemplo: asm-1225-1

    2. Aplique o identificador 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
      

      Saída esperada:

      namespace/GATEWAY_NAMESPACE labeled
      

    Você pode ignorar a mensagem "istio.io/rev" not found na saída. Isso significa que o namespace não tinha o rótulo istio.io/rev anteriormente, o que é esperado em novas instalações do Cloud Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tem istio.io/rev e istio-injection. rótulo, todos os comandos kubectl label no Cloud Service Mesh a documentação para especificar explicitamente os dois rótulos.

    Se o namespace do gateway não estiver rotulado, os pods istio-ingressgateway falharão com um erro ImagePullBackOff quando o gateway tentar extração e a imagem auto. Essa imagem deve ser substituída pelo webhook.

  3. Faça o download do exemplo do arquivo de configuração .yaml do gateway de entrada no repositório anthos-service-mesh-packages.

  4. Aplique o exemplo de configuração do .yaml do gateway de entrada no estado em que se encontra ou modifique conforme necessário.

    kubectl apply -n GATEWAY_NAMESPACE \
      -f CONFIG_PATH/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 Cloud Service Mesh usa proxies sidecar para aumentar a segurança, a confiabilidade e a observabilidade da rede. Com o Cloud Service Mesh, essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo entregues 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 sidecar (injeção automática) e reinicie os pods de todas as cargas de trabalho que estavam sendo executadas no cluster antes de instalar o Cloud Service Mesh.

Para ativar a injeção automática, rotule seus namespaces com o rótulos de injeção padrão se a tag padrão estiver configurada, ou um rótulo de revisão que foi definido em istiod quando você instalou o Cloud 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 automática para que o Cloud 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:

    1. Se você usou uma revisão de tag padrão para ativar a injeção automática no de gateway, verifique se a tag padrão existe no diretório que você especificado em --output_dir e que aponta para a instância recém-instalada revisão.

      DIR_PATH/istioctl tag list
      
    2. Execute o 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-
      

    Os rótulos de injeção padrão injetam a revisão para a qual a tag padrão aponta.

    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-1225-1-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1225-1,istio=istiod,pod-template-hash=5788d57586
      istiod-asm-1225-1-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1225-1,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-1225-1.

    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 antes o istio-injection, que é o novo padrão instalações do Cloud Service Mesh ou novas implantações. Porque a injeção automática o comportamento é indefinido quando um namespace tem o istio-injection e o rótulo de revisão, todos os comandos kubectl label na A documentação do Cloud Service Mesh garante explicitamente que apenas um deles seja definido.

  2. Se as cargas de trabalho estavam em execução no cluster antes de instalar o Cloud 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, na sua produção, ambiente, é possível ter um processo que implemente implantação azul-verde para que seja possível reiniciar os pods com segurança e 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