Como fazer upgrade do Knative serving no VMware para as frotas

Saiba como migrar o Knative serving no VMware para usar frotas e fazer upgrade para o Anthos versão 1.8.

Importante: o Anthos versão 1.8 exige que todas as instalações anteriores do Knative serving no VMware sejam migradas para usar frotas. É necessário migrar o Knative serving antes de fazer upgrade dos clusters do GKE para a versão 1.8.

Se você optar por permanecer na versão 1.7 ou anterior do Anthos, não será necessário migrar sua instalação imediatamente. No entanto, começando com Anthos 1.8, novas instalações e upgrades para o Knative serving só estão disponíveis pelas frotas.

O Knative serving agora é uma experiência separada do Cloud Run e agora é fornecido como um componente da frota nos clusters. A instalação dos recursos do Knative Serving no VMware como um componente da frota permite gerenciar e fazer upgrade da instalação independentemente de outros componentes da frota.

Em geral, para migrar o Knative serving na instalação do VMware para usar uma frota, você precisa do seguinte:

• Configure o Knative serving na instalação do VMware para atender aos requisitos da frota.
• Ative o componente de recurso do Knative serving na frota.

O servidor da API Kubernetes não é afetado durante essa migração.

Para mais detalhes sobre como realizar uma nova instalação do Knative serving no VMware, consulte Como instalar o Knative serving no VMware.

Antes de começar

Você precisa atender aos seguintes requisitos:

• Estas etapas exigem que o serviço do Knative no cluster do VMware esteja registrado em uma frota e visível no console do Google Cloud:

  Acesse os clusters do GKE

• A instalação do Knative serving no VMware está em um cluster que executa o Anthos versão 1.7 ou anterior.

• O Istio não é mais compatível com o Anthos 1.8. A versão do Cloud Service Mesh 1.18 deve ser instalada na frota, e a instalação do Knative serving precisa ser configurada antes do upgrade do cluster para a versão 1.8.

  Consulte as instruções do Cloud Service Mesh para mais detalhes sobre como instalar no Google Distributed Cloud.

  O Cloud Service Mesh requer que o cluster use um tipo de máquina que tenha pelo menos quatro vCPUs, como e2-standard-4. Se você precisar alterar o tipo de máquina do cluster, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.

• Há duas opções para migrar o Knative serving para o Cloud Service Mesh:

  • Consiga um novo endereço IP externo para configurar o balanceador de carga.

  • Reutilize o endereço IP do balanceador de carga existente.

    Aviso: o processo de reutilização de um endereço IP para configurar o Cloud Service Mesh causa aproximadamente dois minutos de inatividade na conexão. É necessário planejar esse período para que os serviços do Knative serving não possam se conectar.

• Verifique se o ambiente de linha de comando está configurado e atualizado.

Migrar para frotas

Para fazer o upgrade do Anthos para a versão 1.8, primeiro siga estas etapas para garantir que o Knative serving no VMware seja migrado para usar o componente de frota.

Importante: a maioria das etapas deste processo exige que você configure cada um dos clusters de usuário. Portanto, repita as etapas para cada um desses clusters.

Acessar o cluster de administrador

Para conseguir o caminho e o nome do arquivo kubeconfig do cluster de administrador e criar a variável de ambiente ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Substitua [ADMIN_CLUSTER_KUBECONFIG] pelo caminho e nome do arquivo para o arquivo kubeconfig do cluster de usuário.

Configurar cada cluster de usuário

Importante: se você tiver vários clusters de usuário, repita as etapas desta seção para cada um deles.

1. Crie as seguintes variáveis de ambiente locais para o cluster de usuário:

   1. Crie a variável de ambiente USER_KUBECONFIG com o caminho do arquivo kubeconfig do cluster de usuário:

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      Substitua [USER_CLUSTER_KUBECONFIG] pelo caminho e nome do arquivo para o arquivo kubeconfig do cluster de usuário.

   2. Crie variáveis de ambiente para as seguintes configurações:

      • ID do seu projeto do Google Cloud.
      • Local dos recursos do Google Cloud.
      • Nome do cluster de usuário.

      export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}")
      export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}")
      export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
      

2. Remova a configuração cloudrun do recurso personalizado OnPremUserCluster no cluster de administrador:

   1. Verifique se cloudRun está definido em OnPremUserCluster:

      $ kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      Resultado:

      {"enabled":true}
      

   2. Remova cloudRun de OnPremUserCluster:

      kubectl patch onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --type="merge" \
        --patch '{"spec": {"cloudRun": null}}'
      

   3. Valide se cloudRun foi removido de OnPremUserCluster, executando o mesmo comando get e verificando se alguma configuração foi retornada:

      kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      Não haverá saída para o terminal.

3. Atualize o secret create-config do cluster de usuário:

   1. Crie uma cópia YAML local do arquivo create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}" \
        --output=jsonpath={.data.cfg} \
        | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
      

   2. Abra o arquivo ${CLUSTER_NAME}_create_secret.yaml que você acabou de criar em um editor e remova o campo cloudrun em spec.

   3. Codifique em base64 o arquivo ${CLUSTER_NAME}_cluster_create_secret.yaml em um arquivo .b64:

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      

   4. No editor, abra o arquivo .b64 local que você acabou de criar e copie a string do atributo data.cfg para usar na próxima etapa.

      Copie somente o conteúdo do atributo cfg. Por exemplo, não inclua novas linhas (\n).

   5. Execute o seguinte comando para editar o secret no cluster de usuário:

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      

   6. No editor que será aberto, substitua o campo data[cfg] pela string que você copiou do arquivo .b64 local e salve as alterações.

   7. Verifique se as alterações foram implantadas no cluster de usuário e se o atributo cloudrun foi removido dos secrets create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      

4. Configure o namespace knative-serving no cluster de usuário:

   1. Exclua o operador cloudrun-operator do namespace knative-serving:

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      

   2. Corrija o configmap config-network no namespace knative-serving:

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
      

5. Remova a configuração cloudrun.enabled do arquivo de configuração do cluster de usuário user-config.yaml da instalação do Google Distributed Cloud.

   Os seguintes atributos precisam ser excluídos do arquivo user-config.yaml:

   cloudRun:
     enabled: true
   

   Quando você executa o upgrade de cluster para o Anthos versão 1.8, essa alteração de configuração é implantada.

6. Se você tiver vários clusters de usuário, repita todas as etapas nesta seção para "Configurar cada cluster de usuário".

Configurar o componente da frota

1. Ative o componente do Knative serving na sua frota:

   gcloud container fleet cloudrun enable --project=$PROJECT_ID
   

   Para mais detalhes e opções, consulte a referência gcloud container fleet cloudrun enable.

2. Opcional: verifique se o componente do recurso Knative serving está ativado:

   Console

   Confira se o componente do Knative serving está ativado no Console do Google Cloud:

   Acessar o gerenciador de recursos

   Linha de comando

   Veja se o estado appdevexperience é ENABLED:

   gcloud container fleet features list --project=$PROJECT_ID
   

   Para mais detalhes e opções, consulte a referência da lista de recursos da frota de contêiner do gcloud.

   Resultado:

   NAME               STATE
   appdevexperience   ENABLED
   

3. Implante o recurso personalizado CloudRun para instalar o Knative serving no VMware em cada um dos clusters de usuário. Por padrão, a versão latest do Knative Serving é implantada.

   Importante: se você tiver vários clusters de usuário, repita esta etapa para cada cluster de usuário.

   Execute o comando kubectl apply a seguir para implantar a configuração padrão do recurso personalizado CloudRun:

   cat <<EOF | kubectl apply -f -
   apiVersion: operator.run.cloud.google.com/v1alpha1
   kind: CloudRun
   metadata:
     name: cloud-run
   spec:
     metricscollector:
       stackdriver:
         projectid: $PROJECT_ID
         gcpzone: $CLUSTER_LOCATION
         clustername: $CLUSTER_NAME
         secretname: "stackdriver-service-account-key"
         secretkey: "key.json"
   EOF
   

Configurar o Cloud Service Mesh

Configure o balanceador de carga do Cloud Service Mesh para cada um dos clusters de usuário.

Importante: se você tiver vários clusters de usuário, repita as etapas desta seção para cada um deles.

É possível configurar o gateway de entrada do Cloud Service Mesh definindo um novo endereço IP externo ou reutilizando o endereço IP existente:

• Com o novo endereço IP externo que você recebeu, configure o balanceador de carga seguindo as etapas na documentação do Cloud Service Mesh.

  Essa opção garante que os serviços do Knative serving sejam reiniciados sem interrupção.

• Alternativa: use as etapas a seguir para configurar o balanceador de carga do Cloud Service Mesh para seu endereço IP existente.

  Aviso: migrar para o Cloud Service Mesh usando seu endereço IP atual causa aproximadamente dois minutos de inatividade da conexão. É necessário planejar esse período para que os serviços do Knative serving não possam se conectar.

  1. Configure o gateway dos serviços para o Cloud Service Mesh executando os seguintes comandos:

     export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}')
     kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}"
     kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"
     

  2. Remova as configurações atuais do Istio:

     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}'
     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'
     

Verificar a migração

É possível verificar se o appdevexperience-operator está em execução para verificar se o Knative serving no VMware foi migrado para a frota.

Para cada cluster de usuário, execute o seguinte comando:

 kubectl get deployment -n appdevexperience appdevexperience-operator

O operador appdevexperience-operator mostrará 1/1 como pronto, por exemplo:

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

Se o operador não atingir o estado pronto, visualize a página de cargas de trabalho do cluster no console do Google Cloud para identificar problemas de recursos:

Acessar as cargas de trabalho do Google Kubernetes Engine

Fazer upgrade do cluster

Agora que você migrou a instalação do Knative serving no VMware para usar o componente da frota, é possível fazer upgrade do cluster para a versão 1.8 do Anthos. Siga as instruções detalhadas em Como fazer upgrade do GKE On-Prem.

Solução de problemas

O processo de upgrade do cluster de usuário não é concluído

O pod cluster-local-gateway no namespace gke-system pode impedir que o cluster de usuário conclua o upgrade para o Anthos versão 1.8. O pod cluster-local-gateway não é mais necessário e pode ser removido com segurança.

Para ajudar manualmente no processo de upgrade, remova o pod cluster-local-gateway manualmente reduzindo a escala vertical das réplicas de implantação para 0. Exemplo:

1. Reduza a escala vertical dos cluster-local-gateway:

   kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
   

   O pod cluster-local-gateway no namespace gke-system e todas as cargas de trabalho no namespace knative-serving são removidas.

2. Aguarde a conclusão do upgrade.

Saiba mais sobre como escalonar implantações.