Esta documentação é referente à versão Mais recente da veiculação do Knative, que usa frotas e o Anthos Service Mesh. Saiba mais

Acessar o console de veiculação do Knative

A versão anterior (Cloud Run for Anthos) foi arquivada, mas a documentação continua disponível para os usuários atuais.

Versões disponíveis

Mais recente
Arquivar

Como fazer upgrade do Cloud Run for Anthos no VMware para os frotas

Saiba como migrar o Cloud Run for Anthos no VMware para usar frotas e fazer upgrade para o Anthos versão 1.8.

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

Em geral, para migrar a instalação do Cloud Run para Anthos no VMware para usar uma frota, você precisa:

configurar a instalação do Cloud Run para Anthos no VMware para atender aos requisitos de frota do Anthos;
Ative o componente de recurso do Cloud Run for Anthos na frota do Anthos.

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

Veja detalhes sobre como executar uma nova instalação do Cloud Run para Anthos no VMware em Como instalar o Cloud Run for Anthos no VMware.

Antes de começar

Você precisa atender aos seguintes requisitos:

Estas etapas exigem que o cluster do Cloud Run para Anthos no VMware esteja registrado no Anthos:

Acesse Clusters do Anthos

Saiba como registrar um cluster.
A instalação do Cloud Run para Anthos 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. O Anthos Service Mesh versão 1.10 precisa ser instalado na frota, e a instalação do Cloud Run for Anthos precisa ser configurada antes de fazer upgrade desse cluster para a versão 1.8.

Consulte as instruções do Anthos Service Mesh para detalhes sobre como instalar em clusters do Anthos no VMware.

O Anthos 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 Cloud Run para Anthos para o Mesh Service.
- 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 atual para configurar o Anthos Service Mesh causa aproximadamente dois minutos de inatividade na conexão. É necessário planejar esse período para que os serviços do Cloud Run for Anthos não possam se conectar.
Verifique se o ambiente de linha de comando está configurado e atualizado.

Migrar para as frotas do Anthos

Para fazer o upgrade do Anthos para a versão 1.8, primeiro siga estas etapas para garantir que sua instalação atual do Cloud Run para Anthos na VMware seja migrada para usar o componente do Anthos.

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

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

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.

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

ID do projeto do 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']}")

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

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}

Remova cloudRun de OnPremUserCluster:

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

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

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

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

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

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

Remova a configuração cloudrun.enabled do user-config.yaml do arquivo de configuração do cluster de usuários da instalação dos clusters do Anthos no VMware.

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.
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 de frota do Anthos

Ative o componente do Cloud Run for Anthos na sua frota:
```
gcloud container hub cloudrun enable --project=$PROJECT_ID
```
Para mais detalhes e opções, consulte a referência gcloud container hub cloudrun enable.
Opcional: verifique se o componente de recursos do Cloud Run for Anthos está ativado:
Console
Veja se o componente do Cloud Run para Anthos está ativado no Console do Google Cloud:

Acessar os recursos do Anthos
Linha de comando
Veja se o estado appdevexperience é ENABLED:
```
gcloud container hub features list --project=$PROJECT_ID
```
Para mais detalhes e opções, consulte a referência da lista de recursos de hub de contêiner do gcloud.

Resultado:
```
NAME               STATE
appdevexperience   ENABLED
```
Implante o recurso personalizado CloudRun para instalar o Cloud Run para Anthos no VMware em cada um dos clusters de usuário. Por padrão, é implantada a versão latest do Cloud Run para Anthos.

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 Anthos Service Mesh

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

É possível configurar o gateway de entrada do Anthos 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 Anthos Service Mesh.

Essa opção garante que os serviços do Cloud Run for Anthos sejam reiniciados sem interrupção.

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

Configure o gateway dos serviços para o Anthos 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 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 Cloud Run para Anthos foi migrado para a frota do Anthos.

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 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 Cloud Run for Anthos no VMware para usar o componente de frota do Anthos, é 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:

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.
Aguarde a conclusão do upgrade.

Saiba mais sobre como escalonar implantações.