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 operador baseado no Istio 1.6 para a versão de patch mais recente

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 superior.
  • 1.19.8-gke.1600 ou superior.

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

Para corrigir sua imagem de implantação do istio-operator 1.6, 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 para a qual você quer atualizar. Por exemplo, se você quiser fazer upgrade do Istio no GKE para a versão 1.6.14-gke.5, execute o seguinte comando:

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

    O upgrade do plano de controle e do istio-ingressgateway será feito automaticamente.

  3. Reinicie as cargas de trabalho para reinjetar 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.4 para a versão de patch mais recente

Para fazer upgrade do Istio 1.4, execute os comandos a seguir em uma estação de trabalho configurada para se conectar ao cluster do Istio no GKE.

  1. Faça backup da sua imagem de implantação atual:

    export ORIGINAL_ISTIO_VERSION=$(kubectl -n  istio-system get deployment/istio-pilot -o \
    jsonpath={.spec.template.spec.containers[0].image} | sed 's/.*://')
    
    echo $ORIGINAL_ISTIO_VERSION
    
  2. Defina uma variável de ambiente para a versão do Istio para a qual você quer fazer upgrade. Por exemplo, execute o seguinte comando para defini-la como 1.4.10-gke.17:

    export ISTIO_VERSION=1.4.10-gke.17
    
  3. Atualize a versão da imagem de implantação do complemento do Istio:

    kubectl set image -n istio-system deployment/istio-ingressgateway istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-citadel citadel=gke.gcr.io/istio/citadel:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-galley galley=gke.gcr.io/istio/galley:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-sidecar-injector sidecar-injector-webhook=gke.gcr.io/istio/sidecar_injector:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-pilot discovery=gke.gcr.io/istio/pilot:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-policy mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-telemetry mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
  4. Veja o mapa de configuração do injetor do sidecar:

    kubectl get configmap -n istio-system istio-sidecar-injector -oyaml > sidecar-injector.yaml
    
  5. Substitua toda a presença da versão da imagem original pela versão de destino do istio:

    sed -i -- "s/${ORIGINAL_ISTIO_VERSION}/${ISTIO_VERSION}/g" sidecar-injector.yaml
    
  6. Aplique o configmap atualizado:

    kubectl apply -f sidecar-injector.yaml
    
  7. Reinicie as cargas de trabalho para reinjetar os novos proxies Envoy.

Se você tiver problemas e quiser reverter, execute as mesmas etapas com ISTIO_VERSION definido como a versão anterior.

Como fazer upgrade do Istio 1.1.3

A versão 1.1.3-gke.0 do complemento Istio no GKE tem definições PodDisruptionBudget (PDB) que exigem o número mínimo de disponíveis em pelo menos 1. A partir da versão 1.1.7-gke.0, o complemento não tem mais esse requisito. No entanto, após a instalação do PDB, ele impedirá o upgrade para qualquer outra versão que viole o PDB. Isso significa que, para fazer upgrade da 1.1.3-gke.0 para qualquer versão superior à 1.1.x (como a 1.1.7-gke.0), é necessário aumentar primeiro o valor de minReplicas para todas os recursos HorizontalPodAutoscaler do Istio para pelo menos 2. 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, você modifica a política de TLS por meio de anotações. Na versão 1.1, essas anotações não funcionam e exigem que você configure uma política e a DestinationRule. Consulte os detalhes no documento do Istio.

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

O CRD do RbacConfig foi renomeado como 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.