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.

Ao fazer upgrade do cluster para 1.17.9-gke.6300 ou superior, o operador do Istio 1.6 e o plano de controle são instalados junto com o plano de controle atual do Istio 1.4.x. O upgrade requer ação do usuário e segue 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, é possível migrar para a versão 1.6 definindo um rótulo nas cargas de trabalho para apontar para o novo plano de controle e executar uma reinicialização contínua.

Não estamos lançando uma versão 1.5 do complemento Istio no GKE. A 1.6 é a versão lançada após a 1.4.10.

  • O upgrade do cluster para as versões 1.17 e posteriores do GKE faz com que o gateway de entrada integrado fique indisponível por aproximadamente cinco minutos durante o processo de upgrade e faz com que as modificações do usuário no Deployment sejam perdidas. Recomendamos instalar e gerenciar gateways separados definidos pelo usuário para evitar esse problema, conforme descrito em Como adicionar gateways.
  • Há um problema conhecido no upgrade das versões 1.16 a 1.17 e 1.18 do GKE, anteriores à R33. Uma correção está disponível nas versões 1.17.12-gke.1501 ou posterior e 1.18.9-gke.1501 ou posterior. O problema faz com que todos os recursos personalizados criados no namespace do istio-system sejam excluídos durante o upgrade. Esses recursos precisam ser recriados manualmente. Faça o upgrade apenas para uma versão afetada. O problema ocorre apenas durante os upgrades, por isso os novos clusters não são afetados.

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, migre do complemento do Istio no GKE para a versão de código aberto do Istio.

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.7-gke.8+, 1.17.8-gke.6+) 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 executando o Istio 1.4.6-gke.0 e você selecionar o GKE versão 1.17.7-gke.8, será feito o upgrade do plano de controle do Istio para a versão 1.4.10-gke.0 (ou superior) como parte do upgrade.

  2. Verifique se a versão 1.6 do Istio está instalada e em execução:

    kubectl get pods -n istio-system
    

    Você verá um pod istiod em um estado "Em execução" com os componentes do plano de controle 1.4. Por exemplo:

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-78b9b5b589-52cqg                   1/1     Running     0          4m16s
    istio-galley-79bd448645-zxfjm                    1/1     Running     0          4m16s
    istio-ingressgateway-b4f8986c4-dbr6c             1/1     Running     0          4m27s
    istio-pilot-dc558d859-cnrqt                      2/2     Running     1          4m16s
    istio-policy-8664dd6c4-m42xs                     2/2     Running     1          4m15s
    istio-security-post-install-1.4.10-gke.4-255r6   0/1     Completed   0          4m15s
    istio-sidecar-injector-7f85d7f7c4-vt2x9          1/1     Running     0          4m15s
    istio-telemetry-69b6477c5f-4pr6v                 2/2     Running     2          4m15s
    <b>istiod-istio-163-5fccfcf4dd-2p9c8                1/1     Running     0          3m31s</b>
    prometheus-7d9f49d945-4nps2                      2/2     Running     0          3m17s
    promsd-696bcc5b96-ln2s8                          2/2     Running     1          4m15s
    
  3. Certifique-se de que migrou todos os objetos de configuração de política de segurança v1alpha1 não compatíveis. Para mais informações, consulte as Observações sobre o upgrade do Istio.

  4. Desative a validação da configuração no plano de controle 1.4.x.

    1. Editar o recurso ClusterRole do galley:

      kubectl edit clusterrole -n istio-system istio-galley-istio-system
      
    2. Altere o valor '*' para get na seguinte entrada de lista:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - '*' # change this to get
      

      Após a atualização, seu código deverá ficar assim:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - get
      
    3. Exclua a ValidatingWebhookConfiguration do Galley:

      kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
      

Migrar um namespace para 1.6

A instalação da nova revisão não afeta os proxies sidecar atuais. Para fazer upgrade, configure-os para que direcionem para o novo plano de controle. Isso é controlado durante a injeção do sidecar com base no rótulo de namespace istio.io/rev.

  1. Encontre o número exato da versão 1.6 do Istio:

    kubectl -n istio-system get pods -lapp=istiod --show-labels

    A saída deste comando é semelhante a:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-istio-163-5fccfcf4dd-2p9c8   1/1     Running   0          22h   app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd

    Neste exemplo, a versão é: istio-163

  2. Marque novamente o namespace que contém as cargas de trabalho que você quer passar para 1.6. O rótulo da versão precisa corresponder à versão do plano de controle. No comando a seguir, substitua VERSION pela versão do comando anterior, por exemplo: istio-163

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
  3. Execute uma reinicialização gradual das cargas de trabalho selecionadas:

    kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE
  4. Liste os pods no namespace:

    kubectl get pods -n NAMESPACE
  5. Selecione um dos pods para verificar se as cargas de trabalho foram injetadas com a versão 1.6 do proxy sidecar:

    kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD

    O resultado mostrará o contêiner do proxy na versão 1.6, por exemplo:

    ...
    istio-proxy:
      Container ID:  docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5
      Image:         gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0
    ...
    
  6. Conclua a migração de todos os namespaces para a nova versão do Istio. Repita as etapas 3 a 5 para todos os namespaces de carga de trabalho.

Se você planeja migrar para o Anthos Service Mesh, pule para Desativar o plano de controle antigo.

Para continuar no complemento do Istio, siga as etapas a seguir para migrar os gateways de entrada para a nova versão.

  1. Edite a resposta automática IstioOperator para substituir o gateway de entrada por uma versão 1.6:

    kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0
    
  2. Altere a configuração enabled do gateway para true:

    ...
    spec:
      components:
        ingressGateways:
        - enabled: false # change this to true
          name: istio-ingressgateway
    
  3. Verifique se o pod de gateway foi recriado com a nova versão 1.6.

    kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image
    

Desativar o plano de controle antigo

Depois que todos os proxies de carga de trabalho estiverem usando o plano de controle 1.6, será possível desativar o plano de controle antigo. Para isso, dimensione as réplicas de cada componente antigo para 0.

Para reduzir as réplicas:

kubectl scale deploy -n istio-system --replicas=0 \
  istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd

Os demais recursos do Istio podem ser deixados no cluster sem problemas.

Se você ainda estiver no Istio, edite a resposta automática IstioOperator e faça upgrade do Operator na sua programação. Para mais informações, consulte a documentação do Operator (em inglês).

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 que processe todos os detalhes da preparação do seu projeto e cluster do Cloud. Depois, instale o Anthos Service Mesh usando a versão de istioctl install. Recomendamos migrar para o Anthos Service Mesh 1.7, mas é possível migrar o 1.6 usando a versão 1.6 do script.

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

Nesta seção, descrevemos como migrar para o Anthos Service Mesh usando o script install_asm. Recomendamos a migração para o Anthos Service Mesh 1.7, mas a migração para o 1.6 é compatível.

Migrar para o 1.7

  1. Instale as ferramentas necessárias.

  2. Faça o download do script install_asm:

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

    Se você não tiver personalizado a instalação do Istio e quiser continuar usando o Citadel como a autoridade de certificação (CA, na sigla em inglês), migre para o Anthos Service Mesh com os seguintes argumentos para o script:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --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.

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

Migrar para o 1.6

  1. Instale as ferramentas necessárias.

  2. Faça o download do script install_asm:

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

    Se você não tiver personalizado a instalação do Istio e quiser continuar usando o Citadel como a autoridade de certificação (CA, na sigla em inglês), migre para o Anthos Service Mesh com os seguintes argumentos para o script:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    
  4. Para concluir a configuração do Anthos Service Mesh, ative a injeção automática do arquivo secundário e implante ou reimplante cargas de trabalho.

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.