Versão 2.4

Versões disponíveis

2.11 – Versão mais recente
2.10
2.9
2.7 – Fim de vida/Não suportado
2.6 – Fim de vida/Não suportado
2.8 – Fim de vida/Não suportado
2.5 – Fim de vida/Não suportado
2.4 – Fim de vida/Não suportado
2.3 – Fim de vida/Não suportado
2.2 – Fim de vida/Não suportado
2.1 – Fim de vida/Não suportado

Esta página foi traduzida pela API Cloud Translation.

Atualize o Kf

Este documento descreve como atualizar uma instalação existente do Kf e as respetivas dependências.

Como parte do procedimento de atualização, certifique-se de que a sua instalação do Kf usa a versão mais recente do operador do Kf:

Confirme se a sua versão atual do Kf pode ser atualizada para o Kf v2.4.1.
Atualize para o Kf v2.4.1.
Atualize as dependências (se necessário).

Antes de começar

Vai precisar de:

Um cluster existente com o Kf instalado.
Acesso a um computador com o gcloud, o kf e o kubectl instalados.

Preparação para a atualização

Ligue-se ao cluster de destino

gcloud container clusters get-credentials CLUSTER_NAME \
 --zone CLUSTER_ZONE \
 --project CLUSTER_PROJECT_ID

Confirme se as versões atuais da CLI Kf e do servidor correspondem

Execute kf debug e valide se as versões da CLI Kf e do servidor Kf correspondem.

A versão da CLI é apresentada em Kf Client.
A versão do servidor Kf é apresentada em kf["app.kubernetes.io/version"].

$ kf debug
...
Version:
  Kf Client:                        v2.3.2
  Server version:                   v1.20.6-gke.1000
  kf["app.kubernetes.io/version"]:  v2.3.2
...

Se os valores do cliente Kf e do servidor Kf não corresponderem, mas a versão do servidor for v2.3.x, instale a CLI Kf v2.4.1 antes de continuar.

Se o valor do servidor Kf for anterior à versão v2.3.x, tem de atualizar primeiro de forma incremental para o Kf v2.3.x para continuar.

Confirme se o Kf está em bom estado antes de atualizar

Execute kf doctor para verificar o estado do cluster. Certifique-se de que todos os testes são aprovados antes de continuar.

$ kf doctor
...
=== RUN doctor/user
=== RUN doctor/user/ContainerRegistry
--- PASS: doctor/user
   --- PASS: doctor/user/ContainerRegistry
...

Se vir mensagens FAIL ou Error: environment failed checks, siga as orientações na saída kf doctor ou consulte o guia de resolução de problemas para resolver o problema e tente novamente o comando até ter êxito.

Opcionalmente, faça uma cópia de segurança dos mapas de configuração do Kf se tiver feito personalizações

Faça uma cópia de segurança do configmap config-defaults executando:

kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml

Faça uma cópia de segurança do configmap config-secrets executando:
```
kubectl get configmap config-secrets -o yaml -n kf > config-secrets-backup.yaml
```
Nota: esta cópia de segurança é apenas para referência e não deve ser aplicada diretamente.

Atualize o operador Kf

O operador Kf foi lançado pela primeira vez como parte das versões 2.4.0:

Se já tiver instalado o operador Kf como parte da instalação da versão 2.4.0, só tem de o atualizar como parte da atualização para a versão 2.4.1.

Consulte o artigo Atualize o operador Kf.
Se estiver a fazer a atualização a partir da versão 2.3.2, tem de instalar a versão 2.4.1 do operador Kf para atualizar para o Kf gerido pelo operador.

Consulte o artigo Instale o operador Kf.

Atualize o operador Kf atual

O operador Kf faz as atualizações por si.

Aplique o YAML do operador:

Nota: esta operação começa imediatamente e não é reversível.
```
kubectl apply -f "https://storage.googleapis.com/kf-releases/v2.4.1/operator.yaml"
```

Instale o operador Kf pela primeira vez

Siga estes passos para atualizar para um Kf gerido pelo operador.

Aplique o YAML do operador:

Nota: esta operação começa imediatamente e não é reversível.
```
kubectl apply -f "https://storage.googleapis.com/kf-releases/v2.4.1/operator.yaml"
```
Escolha entre usar as predefinições ou manter as personalizações:

Nota: escolha uma das opções. Não preencha ambos.
1. Prepare kfsystem.yaml para a atualização com as predefinições:
  
  Nota: siga estes passos se não tiver feito personalizações a config-defaults ou config-secrets.
  
  Transfira o ficheiro kfsystem.yaml, preencha as variáveis abaixo e, em seguida, execute os comandos no mesmo diretório que o ficheiro para preparar automaticamente o kfsystem.yaml para a atualização.
```
export CLUSTER_PROJECT_ID=YOUR_PROJECT_ID
export CLUSTER_NAME=YOUR_CLUSTER_NAME
export CONTAINER_REGISTRY=YOUR_CLUSTER_COMPUTE_REGION-docker.pkg.dev/${CLUSTER_PROJECT_ID}/${CLUSTER_NAME}

kubectl apply -f kfsystem.yaml

kubectl patch \
kfsystem kfsystem \
--type='json' \
-p="[{'op': 'replace', 'path': '/spec/kf', 'value': {'enabled': true, 'config': {'spaceContainerRegistry': '${CONTAINER_REGISTRY}', 'secrets':{'workloadidentity':{'googleserviceaccount':'${CLUSTER_NAME}-sa', 'googleprojectid':'${CLUSTER_PROJECT_ID}'}}}}}]"
```
2. Prepare-se kfsystem.yaml para a atualização preservando as personalizações:
  
  Nota: se tiver feito personalizações a config-defaults ou config-secrets, tem de as copiar manualmente para os campos correspondentes em kfsystem.yaml.
  1. Transfira o ficheiro kfsystem.yaml.
  2. Faça uma cópia de segurança do configmap config-defaults executando:
```
kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml
```
  3. Faça uma cópia de segurança do configmap config-secrets executando:
```
kubectl get configmap config-secrets -o yaml -n kf > config-secrets-backup.yaml
```
  4. Inspeccione os configmaps config-defaults e config-secrets atuais e encontre as definições correspondentes em kfsystem.yaml.
  5. Copie as definições existentes de config-secrets e config-defaults. Pode encontrar todas as definições em config-secrets e config-defaults em kfsystem.yaml. O campo googleProjectId é agora obrigatório.
  6. O campo wi.googleServiceAccount é a conta de serviço completa em config-secrets, mas para kfsystem, o sufixo tem de ser removido. Por exemplo, ${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com passa a ser ${CLUSTER_NAME}-sa em kfsystem.yaml.
  7. Depois de as definições serem copiadas, altere o campo enabled em kfsystem para true.
  8. Guarde as alterações a kfsystem.yaml.
  9. Configure o operador para o Kf:
```
kubectl apply -f kfsystem.yaml
```

Atualize as dependências do Kf

Atualize o Tekton:

kubectl apply -f "https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.23.0/release.yaml"

Atualize o Cloud Service Mesh:

Nota: se estiver a executar uma versão do Cloud Service Mesh anterior à 1.9, conclua este passo.
1. Siga os passos no guia de atualização do Cloud Service Mesh 1.9.
Atualize o Config Connector.

Nota: o Config Connector é necessário a partir do Kf v2.4.0.
Aviso: não use o método de suplemento do GKE para instalar o Config Connector, uma vez que não é suportado pelo Kf. Use estes passos de instalação personalizados.
1. Transfira o ficheiro tar do operador do Config Connector necessário.
  
  Nota: mantenha uma cópia do pacote de instalação, uma vez que precisa deste pacote para desinstalar o Config Connector.
2. Extraia o ficheiro TAR.
```
tar zxvf release-bundle.tar.gz
```
3. Instale o operador do Config Connector no seu cluster.
```
kubectl apply -f operator-system/configconnector-operator.yaml
```
4. Configure o operador do Config Connector se estiver a instalar o Config Connector pela primeira vez.
  1. Copie o seguinte YAML para um ficheiro com o nome configconnector.yaml:
    
    Aviso: substitua a variável KF_SERVICE_ACCOUNT_NAME no YAML abaixo pela conta de serviço completa resolvida a partir de ${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com
```
# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
# the name is restricted to ensure that there is only one
# ConfigConnector resource installed in your cluster
name: configconnector.core.cnrm.cloud.google.com
spec:
mode: cluster
googleServiceAccount: "KF_SERVICE_ACCOUNT_NAME" # Replace with the full service account resolved from ${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com
```
  2. Aplique a configuração ao cluster.
```
kubectl apply -f configconnector.yaml
```
5. Verifique se o Config Connector está totalmente instalado antes de continuar.
  - O Config Connector executa todos os respetivos componentes num espaço de nomes denominado cnrm-system. Verifique se os pods estão prontos executando o seguinte comando:
```
kubectl wait -n cnrm-system --for=condition=Ready pod --all
```
  - Se o Config Connector estiver instalado corretamente, o resultado é semelhante ao seguinte:
```
pod/cnrm-controller-manager-0 condition met
```
    Nota: o controlador Pod pode demorar vários minutos a iniciar.
6. Configure a identidade de carga de trabalho se estiver a instalar o Config Connector pela primeira vez.
```
kubectl annotate serviceaccount \
--namespace cnrm-system \
--overwrite \
cnrm-controller-manager \
iam.gke.io/gcp-service-account=${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com
```

Atualize para a CLI Kf v2.4.1

Instale a CLI:
Linux
Este comando instala a CLI do Kf para todos os utilizadores no sistema. Siga as instruções no separador do Cloud Shell para o instalar apenas para si.
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-linux /tmp/kf
chmod a+x /tmp/kf
sudo mv /tmp/kf /usr/local/bin/kf
```
Mac
Este comando instala o kf para todos os utilizadores no sistema.
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-darwin /tmp/kf
chmod a+x /tmp/kf
sudo mv /tmp/kf /usr/local/bin/kf
```
Cloud Shell
Este comando instala o kf na sua instância do Cloud Shell se usar o bash. Caso contrário, pode ter de modificar as instruções para outras shells.
```
mkdir -p ~/bin
gcloud storage cp gs://kf-releases/v2.4.1/kf-linux ~/bin/kf
chmod a+x ~/bin/kf
echo "export PATH=$HOME/bin:$PATH" >> ~/.bashrc
source ~/.bashrc
```
Windows
Esta ação transfere kf para o diretório atual. Adicione-o ao caminho se quiser chamá-lo a partir de qualquer outro local que não seja o diretório atual.
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-windows.exe kf.exe
```
Valide se as versões da CLI Kf e do servidor Kf correspondem:
- A versão da CLI é apresentada em Kf Client.
- A versão do servidor Kf é apresentada em kf["app.kubernetes.io/version"].
```
$ kf debug
...
Version:
  Kf Client:                        v2.4.1
  Server version:                   v1.20.6-gke.1000
  kf["app.kubernetes.io/version"]:  v2.4.1
...
```

Verifique se a atualização do Kf foi bem-sucedida

Se estiver a instalar o operador Kf pela primeira vez, confirme se o operador foi instalado:
```
kubectl get deployment -n appdevexperience appdevexperience-operator
```
Se não vir o operador como no exemplo de saída abaixo, reveja os passos de Instale o operador Kf pela primeira vez.
```
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
appdevexperience-operator   1/1     1            1           1h
```
Execute doctor para garantir que a versão recém-instalada está em bom estado:
```
kf doctor --retries=20
```
O comando executa verificações de clusters várias vezes. É normal que algumas das tentativas falhem enquanto os novos controladores estão a ser iniciados.

Se o comando falhar com a mensagem Error: environment failed checks, siga as orientações na saída doctor para resolver o problema e tente novamente o comando até ter êxito.

Se fez personalizações a config-defaults ou config-secrets, verifique se foram transferidas:

Compare o ficheiro config-defaults-backup.yaml com kubectl diff -f config-defaults-backup.yaml para garantir que o cluster continua configurado corretamente.

Por exemplo, se manteve todas as alterações da sua versão antiga do Kf e aprovou a utilização de um novo buildpack incluído na versão seguinte do Kf:

$ kubectl diff -f config-defaults-backup.yaml
diff -u -N /tmp/LIVE/v1.ConfigMap.kf.config-defaults /tmp/MERGED/v1.ConfigMap.kf.config-defaults
--- /tmp/LIVE/v1.ConfigMap.kf.config-defaults
+++ /tmp/MERGED/v1.ConfigMap.kf.config-defaults
@@ -131,6 +131,8 @@
     enable_route_services: false
   spaceBuildpacksV2: |
-    - name: new_buildpack
-      url: https://github.com/cloudfoundry/new-buildpack
     - name: staticfile_buildpack
       url: https://github.com/cloudfoundry/staticfile-buildpack
     - name: java_buildpack
exit status 1

Se os passos de validação forem bem-sucedidos, o cluster foi atualizado com êxito! Se tiver problemas, reveja a página de apoio técnico para obter orientações.