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.

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 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.

  • 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.

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

  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 Google Cloud .
      • Local dos seus 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 doGoogle 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.

    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.

É 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.

    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.