Atualizar o Knative Serving no VMware para frotas

Saiba como migrar o Knative Serving no VMware para usar frotas, de modo que possa atualizar para o Anthos versão 1.8.

O Knative Serving é agora uma experiência separada do produto Cloud Run gerido e é fornecido como um componente de frota nos seus clusters. A instalação do Knative serving no VMware funciona como um componente da sua frota, o que lhe permite gerir e atualizar a instalação independentemente de outros componentes da frota.

Em termos gerais, para migrar a sua instalação do Knative Serving no VMware para usar uma frota, tem de:

  • Configure a sua instalação do Knative Serving no VMware de forma a cumprir os requisitos da frota.
  • Ative o componente de publicação do Knative na sua frota.

Tenha em atenção que o servidor da API Kubernetes não é afetado durante esta migração.

Para ver detalhes sobre como fazer uma nova instalação do Knative Serving no VMware, consulte o artigo Instalar o Knative Serving no VMware.

Antes de começar

Tem de cumprir os seguintes requisitos:

  • Estes passos requerem que o seu Knative serving no cluster VMware esteja registado numa frota e seja visível na Google Cloud consola:

    Aceda aos clusters do GKE

  • A sua instalação do Knative Serving no VMware está num cluster com a versão 1.7 ou anterior do Anthos.

  • O Istio já não é suportado no Anthos 1.8. Tem de instalar a versão 1.18 do Cloud Service Mesh na sua frota e configurar a instalação do Knative Serving antes de atualizar esse cluster para a versão 1.8.

    Consulte as instruções do Cloud Service Mesh para ver detalhes sobre a instalação no Google Distributed Cloud.

    Tenha em atenção que a malha de serviços na nuvem requer que o cluster use um tipo de máquina com, pelo menos, quatro vCPUs, como e2-standard-4. Se precisar de alterar o tipo de máquina do cluster, consulte o artigo Migrar cargas de trabalho para diferentes tipos de máquinas.

  • Existem duas opções para migrar o Knative Serving para o Cloud Service Mesh. Pode:

    • Obtenha um novo endereço IP externo para o qual configura o balanceador de carga.

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

  • Certifique-se de que o ambiente de linha de comandos está configurado e atualizado.

Migre para frotas

Para atualizar o Anthos para a versão 1.8, primeiro tem de executar os passos seguintes para garantir que a sua instalação existente do Knative serving no VMware é migrada para usar o componente da frota.

Aceda ao cluster de administrador

Obtenha o caminho e o nome do ficheiro kubeconfig do cluster de administrador e, em seguida, crie a variável de ambiente ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Substitua [ADMIN_CLUSTER_KUBECONFIG] pelo caminho e nome do ficheiro para o ficheiro kubeconfig do cluster de administrador.

Configure cada cluster de utilizadores

  1. Crie as seguintes variáveis de ambiente local para o cluster de utilizadores:

    1. Crie a variável de ambiente USER_KUBECONFIG com o caminho do ficheiro kubeconfig do cluster de utilizadores:

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      Substitua [USER_CLUSTER_KUBECONFIG] pelo caminho e nome do ficheiro para o ficheiro kubeconfig do cluster de utilizadores.

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

      • ID do seu Google Cloud projeto.
      • Localização dos seus Google Cloud recursos.
      • Nome do cluster de utilizadores.
      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 do cluster de utilizadores:

    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 com êxito de OnPremUserCluster executando o mesmo comando get e verificando se não é devolvida nenhuma configuração:

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

      Não deve haver nenhuma saída para o seu terminal.

  3. Atualize o segredo create-config do cluster de utilizadores:

    1. Crie uma cópia YAML local do ficheiro 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 ficheiro ${CLUSTER_NAME}_create_secret.yaml que acabou de criar num editor e, em seguida, remova o campo cloudrun de spec.

    3. Codifique o ficheiro ${CLUSTER_NAME}_cluster_create_secret.yaml em Base64 num ficheiro .b64:

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      
    4. No editor, abra o ficheiro .b64 local que acabou de criar e, de seguida, copie a string do atributo data.cfg para usar no passo seguinte.

      Tem de garantir que copia apenas o conteúdo do atributo cfg. Por exemplo, não inclua novas linhas (\n).

    5. Execute o seguinte comando para editar o segredo no cluster de utilizadores:

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      
    6. No editor apresentado, substitua o campo data[cfg] pela string que copiou do ficheiro .b64 local e, em seguida, guarde as alterações.

    7. Verifique se as alterações foram implementadas no cluster de utilizadores e se o atributo cloudrun foi removido com êxito dos segredos create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      
  4. Configure o espaço de nomes knative-serving no cluster de utilizadores:

    1. Elimine o operador cloudrun-operator do knative-serving espaço de nomes:

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      
    2. Aplique o patch ao configmap no espaço de nomes knative-serving:config-network

      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 ficheiro de configuração user-config.yaml do cluster de utilizadores da sua instalação do Google Distributed Cloud.

    Os seguintes atributos têm de ser eliminados do ficheiro user-config.yaml:

    cloudRun:
      enabled: true
    

    Quando efetua a atualização do cluster para a versão 1.8 do Anthos, esta alteração de configuração é implementada.

  6. Se tiver vários clusters de utilizadores, tem de repetir todos os passos na secção "Configure cada cluster de utilizadores" para cada cluster de utilizadores.

Configure o componente da frota

  1. Ative o componente de publicação do Knative na sua frota:

    gcloud container fleet cloudrun enable --project=$PROJECT_ID
    

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

  2. Opcional: verifique se o componente da funcionalidade Knative serving está ativado:

    Consola

    Veja se o componente Knative Serving está ativado na Google Cloud consola:

    Aceda ao Gestor de funcionalidades

    Linha de comandos

    Veja se o estado appdevexperience é ENABLED:

    gcloud container fleet features list --project=$PROJECT_ID
    

    Para ver detalhes e opções adicionais, consulte a referência da lista de funcionalidades do gcloud container fleet.

    Resultado:

    NAME               STATE
    appdevexperience   ENABLED
    
  3. Implemente o recurso personalizado CloudRun para instalar o Knative Serving no VMware em cada um dos seus clusters de utilizadores. Por predefinição, é implementada a versão latest do Knative Serving.

    Execute o seguinte comando kubectl apply para implementar a configuração predefinida 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
    

Configure o Cloud Service Mesh

Configure o balanceador de carga do Cloud Service Mesh para cada um dos seus clusters de utilizadores.

Pode configurar o gateway de entrada do Cloud Service Mesh de uma das seguintes formas: configurando um novo endereço IP externo ou reutilizando o seu endereço IP existente:

  • Com o novo endereço IP externo que obteve, configure o balanceador de carga seguindo os passos na documentação do Cloud Service Mesh.

    Tenha em atenção que esta opção garante que os seus serviços de publicação do Knative são reiniciados sem interrupções.

  • Alternativa: siga os passos abaixo para configurar o balanceador de carga da malha de serviços na nuvem para o seu endereço IP existente.

    1. Configure o gateway dos seus serviços para a 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 definições de configuração do Istio atuais:

      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}}'
      

Valide a migração

Pode verificar se o appdevexperience-operator está em funcionamento para confirmar que a publicação do Knative no VMware foi migrada com êxito para a sua frota.

Para cada cluster de utilizadores, execute o seguinte comando:

 kubectl get deployment -n appdevexperience appdevexperience-operator

O appdevexperience-operator operador deve 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 conseguir atingir o estado de preparação, pode ver a página de cargas de trabalho do cluster na Google Cloud consola para identificar problemas de recursos:

Aceda às cargas de trabalho do Google Kubernetes Engine

Atualize o cluster

Agora que migrou a sua instalação do Knative Serving no VMware para usar o componente fleet, pode atualizar o cluster para o Anthos versão 1.8. Siga as instruções detalhadas no artigo Atualizar o GKE On-Prem.

Resolução de problemas

O processo de atualização do cluster de utilizadores não é concluído

O pod cluster-local-gateway no espaço de nomes gke-system pode impedir que o cluster de utilizadores conclua a atualização para a versão 1.8 do Anthos. O pod cluster-local-gateway já não é necessário e pode ser removido em segurança.

Para ajudar manualmente no processo de atualização, pode remover manualmente o pod cluster-local-gateway reduzindo as réplicas da implementação para 0. Por exemplo:

  1. Diminua a cluster-local-gateway:

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

    O pod cluster-local-gateway no espaço de nomes gke-system e todas as cargas de trabalho no espaço de nomes knative-serving são removidos.

  2. Aguarde pela conclusão do processo de atualização.

Saiba mais sobre como dimensionar implementações.