Esta página foi traduzida pela API Cloud Translation.
Switch to English

Como fazer upgrade para o Istio 1.6 com o operador

A partir da versão 1.6, o complemento do Istio no Google Kubernetes Engine usa o Istio Operator para instalação e configuração . O Istio Operator segue o padrão de operador do Kubernetes. O operador permite que você configure o Istio ao estabelecer uma definição de recurso personalizado (CRD, na sigla em inglês) do Kubernetes para a instalação do Istio. Em seguida, o operador usa um controlador para fazer alterações na instalação que correspondem ao recurso personalizado.

Quando você fizer upgrade do cluster para a versão 1.17.17-gke.3100+, 1.18.16-gke.1600+, ou 1.19.8-gke.1600+, o Istio 1.6 Operator e o plano de controle serão instalados juntos no plano de controle do Istio 1.4.x. O upgrade requer ação do usuário e usa revisões para migrar suas cargas de trabalho para o novo plano de controle. Com um upgrade baseado em revisão, você migra para a versão 1.6 definindo um rótulo nas cargas de trabalho para apontar para o novo plano de controle e para executar uma reinicialização gradual.

Não estamos lançando uma versão 1.5 do complemento Istio on Google Kubernetes Engine. A versão 1.6 é a versão que lançamos após a versão 1.4.10.

Benefícios do Istio Operator

O Operator permite maior configuração de instalação. Nas versões anteriores à 1.6, o gerenciador de complementos do GKE reconcilia qualquer alteração no manifesto do Istio e impede a maioria dos tipos de alterações de configuração. O Istio Operator não tem essa limitação. Ele gera um manifesto de instalação do plano de controle do Istio com base no recurso personalizado IstioOperator (CR, na sigla em inglês) fornecido durante a instalação. Esse CR está totalmente sob seu controle e nunca é reconciliado.

Depois de fazer upgrade para o Istio 1.6 com o Operator, é possível migrar do complemento Istio on GKE para a versão de código aberto do Istio ou para o Anthos Service Mesh.

Como fazer upgrade para o Istio 1.6 com o operador

Você só precisa seguir estas etapas uma vez para fazer a transição para o Operator. Os upgrades subsequentes seguem o processo de upgrade do plano de controle duplo.

  1. Selecione uma versão do GKE que inclua o Istio 1.6 (1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.11.1.8-gke.1600+) e faça upgrade do cluster.

    O complemento do Istio no Google Kubernetes Engine com o Istio 1.6 instala duas versões do Istio:

    • A versão do manifesto estático controlada pelo gerenciador de complementos, que fica ativa depois do upgrade do cluster.

    • A versão 1.6 controlada pelo Operator (que fica inativa até que seja ativada). A versão 1.6 inativa não se conecta a nenhum proxy e consome recursos de cluster insignificantes.

    Se a versão atualmente instalada do Istio for diferente da versão no manifesto estático de destino, o upgrade do cluster também poderá executar um upgrade no local do Istio. Por exemplo, se o cluster estiver atualmente executando o Istio 1.4.6-gke.0 e você selecionar a versão de cluster 1.17.7-gke.3100, o plano de controle do Istio será atualizado para 1,4.10-gke. 0 (ou superior) como parte do upgrade.

    Para garantir que a versão do cluster seja recente o suficiente, execute o seguinte comando:

    kubectl get ns istio-system --show-labels | if [[ $(grep EnsureExists) ]];
    then echo "Version is recent enough"; else echo "Need more recent version"; fi
    

    A resposta do console indica se a versão do cluster é recente o suficiente.

  2. Faça o download do script upgrade-14-16:

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/upgrade-14-16
    

    Veja o script no GitHub (em inglês).

  3. Torne o script executável:

    chmod +x upgrade-14-16
    
  4. Certifique-se de que kubectl esteja configurado no cluster de que você quer fazer upgrade.

    gcloud container clusters get-credentials cluster-name
    

    em que cluster-name é o nome do cluster.

  5. Execute o script:

    ./upgrade-14-16
    

    O script guia você pelo processo de migração de um único cluster.

  6. Para migrar outro cluster, execute a ferramenta com a sinalização --reset:

    ./upgrade-14-16 --reset
    

    Em seguida, repita as etapas 4 e 5.

Como migrar para o Anthos Service Mesh

Antes de migrar para o Anthos Service Mesh, desative o Operator como descrito abaixo. Depois da migração, ainda será feita a configuração da malha de serviço usando o mesmo formato de resposta automática IstioOperator como Operator. No entanto, você fará isso com o comando istioctl install quando quiser alterar o estado instalado, em vez de deixar o controlador do Operator observando a resposta automática IstioOperator de forma contínua no cluster.

Para migrar para o Anthos Service Mesh, use um script fornecido pelo Google, install_asm, para migrar para o Anthos Service Mesh 1.7. O script install_asm processa todos os detalhes da preparação do projeto do Cloud e do cluster e, em seguida, instala o Anthos Service Mesh usando a versão do Anthos Service Mesh de istioctl install.

Requisitos

O cluster precisa atender aos seguintes requisitos:

Planejar a migração

Para informações sobre como planejar a migração, consulte este link.

Desativar o Operator

Para evitar que o Operator reconcilie o istio-ingressgateway que o Anthos Service Mesh instalou, desative o Operator.

Para desativar o Operator:

  1. Consiga a versão do Operator:

    kubectl get istiooperators -n istio-system
    

    A resposta será semelhante a:

    NAME                        REVISION     STATUS    AGE
    istio-1-6-11-gke-0          istio-1611   HEALTHY   12h

    No exemplo de saída, a versão do Operator é istio-1-6-11-gke-0.

  2. Desativar o Operator. No comando a seguir, substitua VERSION pela versão do operador da etapa anterior:

    kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=merge
    

    Esse comando bloqueia o Operator de fazer qualquer alteração no cluster.

Migrar para o Anthos Service Mesh

Esta seção descreve como migrar para o Anthos Service Mesh 1.7 usando o script install_asm.

  1. Escolha uma autoridade de certificação.

  2. Instale as ferramentas necessárias.

  3. Faça o download do script install_asm.

  4. Revise as opções e sinalizações do script.

    Os exemplos a seguir mostram como migrar para o Anthos Service Mesh com a autoridade de certificação (CA, na sigla em inglês) escolhida. e migrar para o Anthos Service Mesh com a malha de malha.

    Citadel

    Para continuar usando o Citadel como CA depois de migrar para o Anthos Service Mesh:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --output_dir DIR_PATH  \
      --ca citadel \
      --enable_apis
    
    .

    CA da malha

    Para migrar para a Mesh CA quando migrar para o Anthos Service Mesh:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --output_dir DIR_PATH  \
      --ca mesh_ca \
      --enable_apis
    

    O Anthos Service Mesh 1.7 também fornece arquivos de sobreposição disponíveis no GitHub para recursos usados com frequência, como a ativação no gateway de saída. Para mais informações, consulte Como ativar recursos opcionais.

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

Depois de migrar

Execute o seguinte comando e substitua VERSION pela versão do Operator usada anteriormente para desativar o Operator:

kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'

Esse comando reativa o Operator com um perfil empty, o que faz com que ele remova do cluster os recursos instalados anteriormente. Isso não inclui os gateways ou elementos do plano de controle instalados pelo script install_asm.