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:
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
Crie as seguintes variáveis de ambiente local para o cluster de utilizadores:
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.
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']}")
Remova a configuração
cloudrun
do recurso personalizadoOnPremUserCluster
do cluster de utilizadores:Verifique se
cloudRun
está definido emOnPremUserCluster
:$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
Resultado:
{"enabled":true}
Remova
cloudRun
deOnPremUserCluster
:kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'
Valide se
cloudRun
foi removido com êxito deOnPremUserCluster
executando o mesmo comandoget
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.
Atualize o segredo create-config do cluster de utilizadores:
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"
Abra o ficheiro
${CLUSTER_NAME}_create_secret.yaml
que acabou de criar num editor e, em seguida, remova o campocloudrun
despec
.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"
No editor, abra o ficheiro
.b64
local que acabou de criar e, de seguida, copie a string do atributodata.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
).Execute o seguinte comando para editar o segredo no cluster de utilizadores:
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"
No editor apresentado, substitua o campo
data[cfg]
pela string que copiou do ficheiro.b64
local e, em seguida, guarde as alterações.Verifique se as alterações foram implementadas no cluster de utilizadores e se o atributo
cloudrun
foi removido com êxito dos segredoscreate-config
:kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace ${CLUSTER_NAME} \ --output=jsonpath={.data.cfg} \ | base64 -d
Configure o espaço de nomes
knative-serving
no cluster de utilizadores:Elimine o operador
cloudrun-operator
doknative-serving
espaço de nomes:kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
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}}}'
Remova a configuração
cloudrun.enabled
do ficheiro de configuraçãouser-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.
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
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.
Opcional: verifique se o componente da funcionalidade Knative serving está ativado:
Consola
Veja se o componente Knative Serving está ativado na Google Cloud consola:
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
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ãolatest
do Knative Serving.Execute o seguinte comando
kubectl apply
para implementar a configuração predefinida do recurso personalizadoCloudRun
: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.
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}}"
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 nomesgke-system
pode impedir que o cluster de utilizadores conclua a atualização para a versão 1.8 do Anthos. O podcluster-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 para0
. Por exemplo: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 nomesgke-system
e todas as cargas de trabalho no espaço de nomesknative-serving
são removidos.Aguarde pela conclusão do processo de atualização.