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

Como fazer upgrade do Istio no GKE

Este guia contém notas de upgrade para todas as versões que tenham instruções de upgrade específicas. Você não precisa fazer nada em upgrades que não são mencionados neste guia.

Como fazer upgrade do Istio 1.6 com base no operador para a versão mais recente do patch

Verifique se você está usando um cluster do GKE em execução:

  • 1.17.17-gke.3100 ou superior
  • 1.18.16-gke.1600 ou posterior.
  • 1.19.8-gke.1600 ou posterior

Caso contrário, siga as instruções de upgrade para fazer upgrade do cluster.

Para corrigir a imagem de implantação do operador istio- novo, execute os seguintes comandos em uma estação de trabalho configurada para se conectar ao cluster do Istio no GKE.

  1. Faça backup da versão atual da imagem do operador:

    kubectl -n istio-operator get deployment/istio-operator -o \
    jsonpath={.spec.template.spec.containers..image} > operator-image-backup
    
    more operator-image-backup
    
  2. Identifique a versão que você quer atualizar. Por exemplo, se você quiser fazer upgrade do Istio no GKE para 1.6.14-gke.1, execute o comando a seguir:

    kubectl -n istio-operator set image deployment/istio-operator \
    istio-operator=gcr.io/gke-release/istio/operator:1.6.14-gke.1
    

    Observe que o upgrade do plano de controle e do istio-ingressgateway serão atualizados automaticamente.

  3. Reinicie suas cargas de trabalho para injetar novamente os novos proxies Envoy.

Se você tiver problemas e quiser reverter, execute:

kubectl -n istio-operator set image deployment/istio-operator \
istio-operator=$(cat operator-image-backup)

Como fazer upgrade do Istio 1.1.3

O complemento do Istio no GKE versão 1.1.3-gke.0 tem PodDisruptionBudget (PDB) que exigem o número mínimo de que as réplicas disponíveis sejam pelo menos 1. A partir da versão 1.1.7-gke.0, esse complemento não tem mais esse requisito. No entanto, depois que esse PDB é instalado, ele impede o upgrade para qualquer outra versão caso viole o PDB. Isso significa que, para fazer upgrade do 1.1.3-gke.0 para qualquer versão 1.1.x mais recente (como 1.6.7-gke.0), é necessário primeiro aumentar o valor de minReplicas de todos os Istio HorizontalPodAutoscaler recursos para pelo menos dois. Caso contrário, o upgrade falhará devido a uma violação de PodDisruptionBudget.

Como fazer upgrade para o Istio 1.1

Antes de fazer upgrade de um cluster do GKE de 1.0.x para 1.1.x, verifique se sua configuração é compatível com o 1.1. As seguintes alterações no Istio 1.1 são possivelmente incompatíveis com versões anteriores e podem exigir que você atualize sua configuração para evitar comportamentos inesperados ou inesperados. Recomendamos que você execute o script de upgrade para verificar a configuração.

Modificação de comportamento do TLS por meio de anotações

Na versão 1.0, modifique a política de TLS por meio de anotações. Na 1.1, essas anotações não funcionam e exigem que você configure uma política e um DestinationRule. Consulte o documento do Istio para mais detalhes.

Processo de upgrade

Substitua as anotações por uma Policy e DestinationRule, de acordo com os documentos do Istio (em inglês). Essa alteração não muda a configuração da versão 1.0. Depois do upgrade para a versão 1.1, as anotações antigas não terão efeito. Portanto, é possível excluir as anotações antigas ou deixá-las no lugar.

O RbacConfig foi renomeado para ClusterRbacConfig

RbacConfig CRD foi renomeado para ClusterRbacConfig. O esquema não foi alterado.

Processo de upgrade

Cria uma resposta automática de ClusterRbacConfig para cada resposta automática de RaccbConfig.

Precedência da regra de destino

Durante o roteamento de arquivos secundários para um serviço, as regras para o serviço de destino no mesmo namespace que o arquivo secundário têm precedência, seguidas pelas regras de destino no namespace do serviço e, finalmente, pelas regras de destino em outros namespaces, se aplicável.

Processo de upgrade

Verifique as DestinationRules para ver se elas têm regras em vários namespaces para o mesmo serviço de destino. Em caso afirmativo, examine as regras com atenção para ver como elas se sobrepõem e que a precedência correta se aplica ao comportamento desejado.