Instalação e migração no GKE

Neste guia, explicamos como instalar ou migrar para o Anthos Service Mesh versão 1.6.14 para uma malha contendo um ou mais clusters do GKE que estão no mesmo projeto. Você usa um script fornecido pelo Google, que configura o projeto e o cluster, e instala o Anthos Service Mesh.

Use o guia para estes casos de uso:

  • Novas instalações do Anthos Service Mesh. Se você tiver uma versão anterior do Anthos Service Mesh instalada, consulte Como fazer upgrade do Anthos Service Mesh no GKE. O script 1.6 não lida com upgrades.

  • Como migrar do Istio 1.6 de código aberto para o Anthos Service Mesh. Não é possível migrar de uma versão anterior do Istio. A versão 1.7 do script é compatível com a migração do Istio 1.6 ou 1.7 para o Anthos Service Mesh 1.7. Como você está migrando, talvez prefira migrar para o Anthos Service Mesh 1.7.

  • Como migrar da versão 1.6 do complemento Istio no GKE para o Anthos Service Mesh. Antes de migrar para o Anthos Service Mesh, é necessário Fazer upgrade para o Istio 1.6 com o Operator. Para ver as etapas de migração completas do complemento, consulte Como migrar para o Anthos Service Mesh (em inglês) na documentação do Istio no GKE.

É necessário usar o guiaInstalação e migração avançadas no GKE para os seguintes casos de uso:

  • Quando você precisa personalizar a instalação para substituir configurações no perfil asm-gcp e tem mais de um arquivo YAML IstioOperator de sobreposição. Com o script, é possível especificar apenas um arquivo YAMl.

  • Para uma malha de vários clusters em que os clusters estão em projetos diferentes.

Antes de começar

Veja o que é necessário para seguir este guia:

Se você estiver migrando do Istio, consulte Como se preparar para migrar do Istio.

Diferenças entre o Anthos e o Anthos Service Mesh

  • Os assinantes do GKE Enterprise precisam ativar a API GKE Enterprise.

    Ativar a API

  • Mesmo que você não seja um assinante do GKE Enterprise, ainda é possível instalar o Anthos Service Mesh, mas alguns elementos e recursos da IU no console do Google Cloud estão disponíveis apenas para assinantes do GKE Enterprise. Para informações sobre o que está disponível para assinantes e não assinantes, consulte Diferenças na interface do GKE Enterprise e Anthos Service Mesh. Para informações sobre os preços do Anthos Service Mesh para não assinantes, consulte Preços.

Requisitos

  • Seu cluster do GKE precisa atender aos seguintes requisitos:

    • Um tipo de máquina que tem pelo menos quatro vCPUs, como e2-standard-4. Se o tipo de máquina do cluster não tiver pelo menos quatro vCPUs, altere o tipo de máquina conforme descrito em Como migrar cargas de trabalho para diferentes tipos de máquina.

    • O número mínimo de nós depende do seu tipo de máquina. O Anthos Service Mesh requer pelo menos oito vCPUs. Se o tipo de máquina tiver quatro vCPUs, o cluster precisará ter pelo menos dois nós. Se o tipo de máquina tiver oito vCPUs, o cluster precisará apenas de um nó. Se for preciso adicionar nós, veja Como redimensionar um cluster.

    • O script permite a Identidade da carga de trabalho no cluster. A identidade da carga de trabalho é o método recomendado para chamar APIs do Google. A ativação da Identidade da carga de trabalho altera a forma como as chamadas das cargas de trabalho para as APIs do Google são protegidas, conforme descrito em Limitações da Identidade da carga de trabalho.

    • Como opção recomendada, inscreva o cluster em um canal de lançamento. Recomendamos que você se inscreva no canal de lançamento regular porque outros canais podem estar baseados em uma versão do GKE que não é compatível com o 1.6.14 do Anthos Service Mesh. Saiba mais em Ambientes compatíveis. Siga as instruções em Como registrar um cluster existente em um canal de lançamento se você tiver uma versão estática do GKE.

  • Para serem incluídos na malha de serviço, as portas precisam ser nomeadas, e o nome precisa incluir o protocolo da porta na seguinte sintaxe: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa começar com um traço. Saiba mais em Como nomear portas de serviço.

  • Se você estiver instalando o Anthos Service Mesh em um cluster particular, abra a porta 15017 no firewall para que o webhook usado com a injeção automática de sidecar funcione corretamente. Para mais informações, consulte Como abrir uma porta em um cluster particular.

  • Se você tiver criado um perímetro de serviço na sua organização, talvez seja necessário adicionar o serviço Mesh CA ao perímetro. Saiba mais em Como adicionar o Mesh CA a um perímetro de serviço.

  • Para migrações, istiod precisa ser instalado no namespace istio-system, o que normalmente acontece.

Restrições

Um projeto do Google Cloud só pode ter uma malha associada a ele.

Como escolher uma autoridade de certificação

Para novas instalações e migrações, é possível usar a autoridade de certificação do Anthos Service Mesh (Mesh CA) ou o Citadel (agora incorporado em istiod) como a autoridade de certificação (CA) para emitir certificados TLS mútuos (mTLS) (em inglês).

Recomendamos que você use a Mesh CA pelos seguintes motivos:

  • A Mesh CA é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente no Google Cloud.
  • Com ela, o Google gerencia a segurança e a disponibilidade do back-end da CA.
  • Esta autoridade de certificação possibilita confiar em uma única raiz de confiança entre os clusters.
Por padrão, o script ativa a CA da malha para novas instalações do Anthos Service Mesh.

No entanto, há casos em que é recomendável usar o Citadel, como os seguintes:

  • Se você tiver uma CA personalizada.

  • Se você estiver migrando do Istio ou do complemento Istio on GKE.

    Caso você escolha o Citadel, não haverá inatividade porque o tráfego mTLS não será interrompido durante a migração. Se você escolher a Mesh CA, será necessário programar o tempo de inatividade para a migração porque o tráfego mTLS falhará até que todos os pods sejam reiniciados em todos os namespaces.

Os certificados da Mesh CA incluem os seguintes dados sobre os serviços do aplicativo:

  • O ID do projeto do Google Cloud
  • O namespace do GKE
  • O nome da conta de serviço do GKE

Como instalar as ferramentas necessárias

É possível executar o script no Cloud Shell ou na máquina local executando Linux ou macOS. Todas as ferramentas necessárias são pré-instaladas no Cloud Shell.

Para executar o script localmente:

  1. Verifique se você tem as seguintes ferramentas instaladas:

  2. Faça a autenticação com a gcloud CLI:

    gcloud auth login

  3. Atualize os componentes:

    gcloud components update

  4. Verifique se git está no seu caminho para que kpt possa encontrá-lo.

Execução do script

Nesta seção, descreveremos como fazer o download do script, definir os parâmetros obrigatórios e opcionais e como executar o script. Para uma explicação detalhada sobre o que o script faz, consulte Noções básicas sobre o script.

  1. Faça o download do script para o diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6 > install_asm

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.sha256 > install_asm.sha256

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

    sha256sum -c --ignore-missing install_asm.sha256

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

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

  4. Torne o script executável:

    chmod +x install_asm

  5. Defina as opções e especifique as sinalizações para executar o script. Você sempre incluirá as seguintes opções: project_id, cluster_name, cluster_location e mode. Dependendo da mode, pode ser necessário incluir a opção ca.

    • As opções project_id, cluster_name e cluster_location identificam o cluster no qual instalar o Anthos Service Mesh.
    • O mode é install ou migrate.
    • O ca especifica a autoridade de certificação para mesh_ca ou citadel.

    Veja na seção a seguir exemplos típicos para executar o script. Para uma descrição completa dos argumentos do script, consulte Opção e sinalizações.

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

Examples

Esta seção mostra exemplos de como executar o script em cada mode e alguns argumentos adicionais que podem ser úteis. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

Somente validar

Veja no exemplo a seguir a execução do script com a opção --only_validate. Com essa opção, o script não altera o cluster nem instala o Anthos Service Mesh. O script confirma que:

  • Seu ambiente tem as ferramentas necessárias.
  • Você tem a permissão necessária no projeto especificado.
  • O cluster atende aos requisitos mínimos.
  • O projeto tem todas as APIs do Google necessárias ativadas.

Por padrão, o script faz o download e extrai o arquivo de instalação e faz o download do pacote de configuração asm (em inglês) do GitHub para um diretório temporário. Antes de sair, o script gera uma mensagem que fornece o nome do diretório temporário. Você pode especificar um diretório existente para os downloads com a opção --output_dir DIR_PATH. A opção --output_dir facilita o uso da ferramenta de linha de comando istioctl, se necessário.

  1. Crie um diretório chamado asm-packages.

    mkdir asm-packages

  2. Execute o seguinte comando para validar a configuração e fazer o download do arquivo de instalação e do pacote asm para o diretório asm-packages:

    ./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--output_dir ./asm-packages \
--only_validate

Em caso de sucesso, o script gera o seguinte:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Se um dos testes falhar na validação, o script exibirá uma mensagem de erro. Por exemplo, se seu projeto não tiver todas as APIs do Google necessárias ativadas, você verá o seguinte erro:

ERROR: One or more APIs are not enabled. Please enable them and retry, or
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Nova instalação

O comando a seguir executa o script para uma nova instalação, ativa o Mesh CA (a CA padrão para novas instalações, portanto, a opção ca não é necessária) e permite que o script ativar as APIs do Google necessárias.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Nova instalação com um arquivo de sobreposição

O exemplo a seguir faz uma nova instalação e inclui um arquivo YAML que ativa um recurso opcional.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --operator_overlay egressgateways.yaml

Migração do Istio

Se você estiver migrando do Istio de código aberto, está usando o Citadel como a CA. O comando a seguir executa o script para uma migração para o Anthos Service Mesh e ativa o Citadel como a CA. Essa migração só implanta o plano de controle. Ela não muda a CA raiz e não interrompe as cargas de trabalho atuais.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Opções e sinalizadores

Opções

-p|--project_id CLUSTER_PROJECT_ID
O ID do projeto em que o cluster foi criado.
-n|--cluster_name CLUSTER_NAME
O nome do cluster.
-l|--cluster_location CLUSTER_LOCATION
A zona (para clusters de zona única) ou a região (para clusters regionais) em que o cluster foi criado.
-m|--mode {install|migrate}
Digite install se você estiver fazendo uma nova instalação do Anthos Service Mesh. Digite migrate se você estiver migrando do Istio ou do complemento Istio no GKE para o Anthos Service Mesh.
-c|--ca {mesh_ca|citadel}
Se você estiver fazendo uma nova instalação, esse parâmetro assume como padrão o Mesh CA, e você não precisa incluí-la. Se você estiver migrando do Istio, será necessário especificar citadel ou mesh_ca. Se você puder programar o tempo de inatividade da migração, recomendamos que use mesh_ca. Se não for possível programar o tempo de inatividade da migração, use citadel.
-o|--operator_overlay YAML_FILE
O nome do arquivo YAML para ativar um recurso que não está ativado no perfil asm-gcp. O script precisa ser capaz de localizar o arquivo YAML. Sendo assim, o arquivo precisa estar no mesmo diretório do script. Também é possível especificar um caminho relativo, como: ../manifests/asm-features.yaml
-s|--service_account ACCOUNT
O nome de uma conta de serviço usada para instalar o Anthos Service Mesh. Se não for especificado, a conta de usuário ativa na configuração de gcloud atual será usada. Se você precisar alterar a conta de usuário ativa, execute gcloud auth login.
-k|--key_file FILE PATH
O arquivo de chave de uma conta de serviço. Omita essa opção se não estiver usando uma conta de serviço.
-D|--output_dir DIR_PATH
Se não for especificado, o script criará um diretório temporário em que fará o download dos arquivos e das configurações necessárias para instalar o Anthos Service Mesh. Especifique a sinalização --output-dir para designar um diretório existente a ser usado. Após a conclusão, o diretório especificado conterá os subdiretórios asm e istio-1.6.14-asm.2. O diretório asm contém a configuração da instalação. O diretório istio-1.6.14-asm.2 tem o conteúdo extraído do arquivo de instalação, que contém istioctl, amostras e manifestos.

Sinalizações

-e|--enable_apis
Permita que o script ative as APIs do Google exigidas pelo Anthos Service Mesh. Sem essa sinalização, o script será encerrado se as APIs necessárias ainda não estiverem ativadas. Para uma lista das APIs ativadas pelo script, consulte set_up_project.
-v|--verbose
Mostra comandos antes e depois da execução.
--dry_run
Mostra comandos, mas não os executa.
--only_validate
Execute a validação, mas não instale o Anthos Service Mesh.
--disable_canonical_service
Por padrão, o script implanta o controlador de serviço canônico no cluster. Se você não quiser que o script implante o controlador, especifique --disable_canonical_service. Para mais informações, consulte Como ativar e desativar o controlador de serviço canônico.
-h|--help
Mostra uma mensagem de ajuda com as opções e sinalizações para sair.

Como implantar e reimplantar cargas de trabalho

A instalação não é completa até você ativar a injeção automática de proxy de arquivo secundário (injeção automática).

  • Para novas instalações, é preciso ativar a injeção automática e reiniciar os pods de todas as cargas de trabalho em execução no cluster antes de instalar o Anthos Service Mesh.

  • As migrações do Istio seguem o processo de upgrade do plano de controle duplo (chamado de "upgrades canário" na documentação do Istio). Com um upgrade de plano de controle duplo, o script instala uma nova versão de istiod junto com o istiod existente. Depois, transfira algumas das cargas de trabalho para a nova versão. Esse processo permite monitorar o efeito da nova versão com uma pequena porcentagem das cargas de trabalho antes de migrar todo o tráfego para a nova versão.

  • Antes de implantar novas cargas de trabalho, ative a injeção automática para que o Anthos Service Mesh possa monitorar e proteger o tráfego.

Para ativar a injeção automática, você recebe o rótulo de revisão que o script aplicou a istiod e rotula seus namespaces com o rótulo de revisão. As seções a seguir dão detalhes.

Acessar o rótulo de revisão

O script adiciona um rótulo de revisão no formato istio.io/rev=asm-1614-2 a istiod. Para ativar a injeção automática, você adiciona um rótulo de revisão correspondente aos namespaces. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Depois de adicionar o rótulo, todos os pods existentes no namespace precisarão ser reiniciados para que os sidecars sejam injetados.

  1. Defina o contexto atual para kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Exiba os rótulos em istiod para receber o rótulo de revisão definido pelo script:

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

    A saída deste comando é semelhante a:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7

    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-1614-2, mas você pode ter um valor diferente.

    Para migrações, observe também o valor no rótulo de revisão para a versão istiod antiga. Você precisa disso para excluir a versão antiga do istiod ao concluir a migração. No exemplo de saída, o valor no rótulo de revisão para a versão antiga de istiod é default, mas você pode ter um valor diferente.

Como ativar a injeção automática

Siga estas etapas para novas instalações e migrações para ativar a injeção automática.

  1. Consiga o valor no rótulo de revisão para istiod.

  2. Adicione o rótulo de revisão a um namespace e remova o rótulo istio-injection original: No comando a seguir, altere REVISION para o valor que corresponda à revisão em istiod.

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

  3. Reinicie os pods para acionar a nova injeção:

    kubectl rollout restart deployment -n NAMESPACE

  4. Verifique se os pods estão configurados para apontar para a nova versão de istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.

  6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.

Para migração:

Concluir a transição

Para migrações, você precisa remover a versão antiga de istiod. Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.

  1. Receba o valor no rótulo de revisão para a versão antiga do istiod.

  2. Exclua a versão antiga de istiod. No comando a seguir, substitua OLD_REVISION pela revisão da etapa anterior.

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

Reverter para a versão anterior

Para migrações, se você encontrar um problema ao testar seu aplicativo com a nova versão de istiod, siga estas etapas para reverter para a versão anterior:

  1. Atualize as cargas de trabalho a serem injetadas com a versão anterior do istiod:

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

  2. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:

    kubectl rollout restart deployment -n NAMESPACE

  3. Reimplante a versão anterior do istio-ingressgateway:

    kubectl -n istio-system rollout undo deploy istio-ingressgateway

  4. Remova o novo istiod:

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. Se você não incluiu a sinalização --disable_canonical_service, o script ativou o controlador de serviço canônico. Siga as etapas em Como ativar e desativar o controlador de serviço canônico para desativá-lo.

Como visualizar os painéis do Anthos Service Mesh

Esta seção é aplicável somente se você tiver instalado o Anthos Service Mesh com o perfil de configuração asm-gcp. Se você tiver usado o perfil asm-gcp-multiproject para instalar o Anthos Service Mesh, os dados de telemetria não estarão disponíveis nos painéis do Anthos Service Mesh no console do Google Cloud.

Depois de implantar as cargas de trabalho no seu cluster com os proxies sidecar injetados, acesse as páginas do Anthos Service Mesh no Console do Google Cloud para ver todos os recursos de observabilidade que o Anthos Service Mesh oferece. Observe que leva cerca de um ou dois minutos para que os dados de telemetria sejam exibidos no console do Google Cloud após a implantação das cargas de trabalho.

O acesso ao Anthos Service Mesh no console do Google Cloud é controlado pelo Gerenciamento de identidade e acesso (IAM). Para acessar as páginas do Anthos Service Mesh, um proprietário do projeto precisa conceder aos usuários o papel de Editor ou Visualizador de projeto ou os papéis mais restritivos descritos em Como controlar o acesso ao Anthos Service Mesh no console do Google Cloud.

  1. No console do Google Cloud, acesse Anthos Service Mesh.

    Acessar o Anthos Service Mesh

  2. Selecione o projeto do Google Cloud na lista suspensa na barra de menus.

  3. Se você tiver mais de uma malha de serviço, selecione a malha na lista suspensa Service Mesh.

Para saber mais, consulte Como explorar o Anthos Service Mesh no console do Google Cloud.

Além das páginas do Anthos Service Mesh, as métricas relacionadas aos seus serviços, como o número de solicitações recebidas por um serviço específico, são enviadas para o Cloud Monitoring, onde elas aparecem o Metrics Explorer.

Para ver métricas:

  1. No Console do Google Cloud, acesse a página Monitoring.

    Acessar Monitoring

  2. Selecione Recursos > Metrics Explorer.

Veja uma lista completa de métricas em Métricas do Istio na documentação do Cloud Monitoring.

Como registrar o cluster

É necessário registrar o cluster com a frota do projeto para ter acesso à interface do usuário unificada no console do Google Cloud. Uma frota fornece uma forma unificada de visualizar e gerenciar os clusters e as cargas de trabalho deles, incluindo clusters fora do Google Cloud.

Veja informações sobre como registrar seu cluster em Como registrar clusters na frota.

Como entender o script

É possível fazer o download do script a partir de um local seguro do Cloud Source Repositories, mas o script também estará disponível no GitHub para que você possa ver o que ele faz antes de iniciar o download. O script valida que seu cluster atende aos requisitos e automatiza todas as etapas que você faria manualmente em Como instalar o Anthos Service Mesh no GKE,

validate_args e validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  fi
  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

As funções validate_args e validate_dependencies:

  • Verifique se todas as ferramentas necessárias estão instaladas.
  • Verifique se o nome e o local do cluster, além do ID do projeto que você inseriu como valores de parâmetro são válidos.
  • Garante que o cluster atenda ao tipo de máquina e ao número de nós mínimo necessário.

set_up_project

Se você tiver incluído a sinalização --enable_apis, a função set_up_project ativará as APIs necessárias:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

A função set_up_cluster faz as seguintes atualizações no cluster:

  • Ativa a Identidade da carga de trabalho, que é a maneira recomendada de acessar com segurança os serviços do Google Cloud a partir de aplicativos do GKE

  • Ativa o Cloud Monitoring e o Cloud Logging no GKE

  • Define o rótulo mesh_id no cluster, que é necessário para que as métricas sejam exibidas nas páginas do Anthos Service Mesh no Console do Google Cloud.

  • Define um rótulo como asmv=asm-1614-2 para que você saiba que o cluster foi modificado pelo script

  • Vincula o usuário da GCP ou a conta de serviço que executa o script ao papel de administrador do cluster no cluster.

install_asm

install_asm(){

  local CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

A função install_asm:

  • faz o download do pacote kpt para um diretório temporário;
  • executam os setters kpt para configurar o arquivo istio-operator.yaml;
  • instalam o Anthos Service Mesh.

Diferenças com o script 1.7

1.7 script 1.6 script
Compatível com upgrades. Não faz upgrades.
Compatível com migrações do Istio 1.6 e do Istio 1.7. Compatível com a migração do Istio 1.6.
--print_config
Fornece a configuração usada quando você instalou usando o script install_asm. Essa sinalização facilita a reinstalação do mesmo Anthos Service Mesh (que o script não permite) com a mesma configuração usada anteriormente para criar um anexo da VLAN de monitoramento.		 Indisponível
--custom_overlay
Permite vários arquivos de sobreposição.		 --custom_overlay
Permite apenas um arquivo de sobreposição.
--option
Extrai arquivos de sobreposição do pacote asm no GitHub. 		Indisponível.
Compatível com CA personalizada com as seguintes opções:

--ca_cert
--ca_key
--root_cert
--cert_chain

Indisponível.