Versão 1.6. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Versões disponíveis

Problemas conhecidos

Neste documento, descrevemos problemas conhecidos da versão 1.6 dos clusters do Anthos no VMware (GKE no local).

Recurso personalizado ClientConfig

gkectl update reverte todas as alterações manuais feitas para o recurso personalizado ClientConfig. É altamente recomendável que você faça backup do recurso ClientConfig após cada alteração manual.

`kubectl describe CSINode` e `gkectl diagnose snapshot`

kubectl describe CSINode e gkectl diagnose snapshot às vezes falham devido ao problema de OSS Kubernetes ao desreferenciar campos de ponteiro nulo.

OIDC e certificado de CA

Por padrão, o provedor OIDC não usa a CA comum. É necessário fornecer explicitamente o certificado da CA.

O upgrade do cluster de administrador de 1.5 para 1.6.0 divide os clusters de usuário da versão 1.5 que usam um provedor OIDC e não têm valor para authentication.oidc.capath no arquivo de configuração do cluster de usuário.

Para contornar esse problema, execute o script a seguir.

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"

Substitua:

YOUR_OIDC_IDENTITY_PROVICER: o endereço do seu provedor OIDC:
YOUR_YOUR_USER_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de usuário.

Falha na validação do gkectl check-config: não é possível encontrar partições F5 BIG-IP

Sintomas: A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.
Causas possíveis: Um problema com a API F5 BIG-IP pode causar falha na validação.
Resolução: Tente executar gkectl check-config novamente.

Interrupção de cargas de trabalho com PodDisruptionBudgets

O upgrade de clusters pode causar interrupção ou inatividade das cargas de trabalho que usam PodDisruptionBudgets (PDBs).

Falha no processo de upgrade dos nós

Se você tiver objetos PodDisruptionBudget configurados que não podem permitir outras interrupções, o upgrade dos nós poderá falhar no upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você escalone verticalmente Deployment ou HorizontalPodAutoscaler para permitir que o nó seja drenado enquanto respeita a configuração PodDisruptionBudget.

Para ver todos os objetos PodDisruptionBudget que não permitem interrupções:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

A renovação dos certificados pode ser necessária antes de um upgrade do cluster de administrador

Antes de iniciar o processo de upgrade do cluster de administrador, verifique se os certificados do cluster de administrador são válidos atualmente e, se não forem, renove-os.

Processo de renovação do certificado do cluster de administrador

Verifique se o OpenSSL está instalado na estação de trabalho do administrador antes de começar.
Defina a variável KUBECONFIG:
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
Substitua ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG pelo caminho absoluto para o arquivo kubeconfig do cluster de administrador.

Consiga o endereço IP e as chaves SSH do nó mestre de administrador:

kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key

export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \
jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
--selector='node-role.kubernetes.io/master')

Verifique se os certificados expiraram:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
Se os certificados tiverem expirado, você precisará renová-los antes de fazer upgrade do cluster de administrador.
Como o arquivo kubeconfig do cluster de administrador também expirará se os certificados de administrador expirarem, você precisará fazer backup desse arquivo antes que ele expire.
- Faça backup do arquivo kubeconfig do cluster de administrador:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
- Substitua client-certificate-data e client-key-data no kubeconfig por client-certificate-data e client-key-data no arquivo new_admin.conf que você criou.

Faça backup dos certificados antigos:

Esta é uma etapa opcional, mas recomendada.

# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"

# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout

# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .

Renove os certificados com o kubeadm:

 # ssh into admin master
 ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
 # on admin master
 sudo kubeadm alpha certs renew all

Reinicie os pods estáticos em execução no nó mestre do administrador:

  # on admin master
  cd /etc/kubernetes
  sudo mkdir tempdir
  sudo mv manifests/*.yaml tempdir/
  sleep 5
  echo "remove pods"
  # ensure kubelet detect those change remove those pods
  # wait until the result of this command is empty
  sudo docker ps | grep kube-apiserver

  # ensure kubelet start those pods again
  echo "start pods again"
  sudo mv tempdir/*.yaml manifests/
  sleep 30
  # ensure kubelet start those pods again
  # should show some results
  sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd

  # clean up
  sudo rm -rf tempdir

  logout

Renovar os certificados dos nós de trabalho do cluster de administrador

Verificar a data de validade dos certificados dos nós

    kubectl get nodes -o wide
    # find the oldest node, fill NODE_IP with the internal ip of that node
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}"
    openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem
    logout

Se o certificado estiver prestes a expirar, renove-o com o reparo manual de nós.

É preciso validar os certificados renovados e o certificado do kube-apiserver.

Verifique a validade dos certificados:

ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo kubeadm alpha certs check-expiration"

Verifique o certificado do kube-apiserver:

# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server
# Get the current kube-apiserver certificate
openssl s_client -showcerts -connect : 

| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  

> current-kube-apiserver.crt
# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate
# check nodes are ready
kubectl --kubeconfig $KUBECONFIG get nodes

Como usar clusters do Anthos no VMware com o Anthos Service Mesh versão 1.7 ou posterior

Se você usa clusters do Anthos no VMware com o Anthos Service Mesh versão 1.7 ou posterior e quer fazer upgrade para clusters do Anthos no VMware versão 1.6.0-1.6.3 ou clusters do Anthos no VMware versão 1.7.0-1.7.2, remova os rótulos bundle.gke.io/component-name e bundle.gke.io/component-version das seguintes definições de recursos personalizados (CRDs, na sigla em inglês):

destinationrules.networking.istio.io
envoyfilters.networking.istio.io
serviceentries.networking.istio.io
virtualservices.networking.istio.io

Execute este comando para atualizar o CRD destinationrules.networking.istio.io no cluster de usuário:
```
kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
```
Remova os rótulos bundle.gke.io/component-version e bundle.gke.io/component-name do CRD.

Como alternativa, é possível fazer upgrade para 1.6.4 ou 1.7.3 diretamente.

A atualização da estação de trabalho do administrador pode falhar se o disco de dados estiver quase cheio

Se você atualizar a estação de trabalho de administrador com o comando gkectl upgrade admin-workstation, o upgrade poderá falhar se o disco de dados estiver quase cheio, porque o sistema tentará fazer o backup da estação de trabalho de administrador atual localmente durante o upgrade para uma nova estação de trabalho de administrador. Se não for possível liberar espaço suficiente no disco de dados, use o comando gkectl upgrade admin-workstation com a sinalização adicional --backup-to-local=false para evitar fazer um backup local da estação de trabalho do administrador atual.

Como reiniciar ou fazer upgrade do vCenter em versões anteriores à 7.0U2

Se o vCenter, no caso de versões anteriores à 7.0U2, for reiniciado, após o upgrade ou de outra forma, o nome da rede nas informações da VM do vCenter estará incorreto e resultará no estado Unavailable da máquina. Isso leva os nós a serem reparados automaticamente para criar outros.

Bug relacionado do govmomi: https://github.com/vmware/govmomi/issues/2552 (em inglês)

Esta solução alternativa é fornecida pelo suporte da VMware:

1. The issue is fixed in vCenter versions 7.0U2 and above.

2. For lower versions:
Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the
VM's portgroup.