Version 1.6. Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Verfügbare Versionen

Bekannte Probleme

In diesem Dokument werden bekannte Probleme für Version 1.6 von Anthos-Clustern auf VMware (GKE On-Prem) beschrieben.

Benutzerdefinierte ClientConfig-Ressource

gkectl update setzt alle manuellen Änderungen, die Sie an der benutzerdefinierten ClientConfig-Ressource vorgenommen haben, wieder zurück. Es wird dringend empfohlen, die ClientConfig-Ressource nach jeder manuellen Änderung zu sichern.

`kubectl describe CSINode` und `gkectl diagnose snapshot`

kubectl describe CSINode und gkectl diagnose snapshot schlagen manchmal aufgrund des OSS-Kubernetes-Problems beim Entfernen des Verweises für Null-Zeigerfelder fehl.

OIDC und das CA-Zertifikat

Der OIDC-Anbieter verwendet nicht standardmäßig die gemeinsame Zertifizierungsstelle. Sie müssen das CA-Zertifikat explizit bereitstellen.

Durch das Upgrade des Administratorclusters von 1.5 auf 1.6.0 werden 1.5-Nutzercluster gebrochen, die einen OIDC-Anbieter verwenden und in der Konfigurationsdatei des Nutzerclusters keinen Wert für authentication.oidc.capath haben.

Führen Sie das folgende Skript aus, um dieses Problem zu umgehen:

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}\"}]"

Dabei gilt:

YOUR_OIDC_IDENTITY_PROVICER: Die Adresse Ihres OIDC-Anbieters:
YOUR_YOUR_USER_CLUSTER_KUBECONFIG: Der Pfad der Kubeconfig-Datei des Nutzerclusters.

gkectl check-config-Validierung schlägt fehl: F5 BIG-IP-Partitionen können nicht gefunden werden

Symptome: Die Validierung schlägt fehl, weil F5 BIG-IP-Partitionen nicht gefunden werden können, obwohl sie vorhanden sind.
Mögliche Ursachen: Ein Problem mit der F5 BIG-IP API kann dazu führen, dass die Validierung fehlschlägt.
Lösung: Versuchen Sie, gkectl check-config noch einmal auszuführen.

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

Derzeit kann das Upgrade von Clustern zu Unterbrechungen oder Ausfallzeiten bei Arbeitslasten führen, die PodDisruptionBudgets (PDBs) verwenden.

Knoten schließen ihren Upgradeprozess nicht ab

Wenn Sie PodDisruptionBudget-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment oder HorizontalPodAutoscaler, damit der Knoten unter Berücksichtigung der PodDisruptionBudget-Konfiguration entleert wird.

So rufen Sie alle PodDisruptionBudget-Objekte auf, die keine Störungen zulassen:

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

Möglicherweise müssen die Zertifikate vor einem Upgrade des Administratorclusters verlängert werden

Bevor Sie mit dem Upgrade des Administratorclusters beginnen, sollten Sie prüfen, ob die Zertifikate des Administratorclusters derzeit gültig sind, und sie verlängern, falls nicht.

Verlängerungsprozess des Administratorclusterzertifikats

Prüfen Sie zuerst, ob OpenSSL auf der Administrator-Workstation installiert ist, bevor Sie beginnen.
Legen Sie die Variable KUBECONFIG fest.
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
Ersetzen Sie ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG durch den absoluten Pfad zur kubeconfig-Datei des Administratorclusters.

Rufen Sie die IP-Adresse und die SSH-Schlüssel für den Administrator-Masterknoten ab:

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

Prüfen Sie, ob die Zertifikate abgelaufen sind:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
Wenn die Zertifikate abgelaufen sind, müssen Sie sie vor dem Upgrade des Administratorclusters verlängern.
Da die kubeconfig-Datei des Administratorclusters auch abläuft, wenn die Administratorzertifikate ablaufen, sollten Sie diese Datei vor Ablauf sichern.
- Sichern Sie die kubeconfig-Datei des Administratorclusters:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
- Ersetzen Sie client-certificate-data und client-key-data in kubeconfig durch client-certificate-data und client-key-data in der von Ihnen erstellten Datei new_admin.conf.

Sichern Sie alte Zertifikate:

Dieser Schritt ist optional, wird jedoch empfohlen.

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

Verlängern Sie die Zertifikate mit kubeadm:

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

Starten Sie statische Pods, die auf dem Administratormasterknoten ausgeführt werden, neu:

  # 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

Zertifikate von Administratorcluster-Worker-Knoten verlängern

Ablaufdatum des Knotenzertifikats prüfen

    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

Erneuern Sie die Knotenzertifikate durch manuelle Knotenreparatur, wenn das Zertifikat bald abläuft.

Sie müssen die erneuerten Zertifikate und das Zertifikat von kube-apiserver validieren.

Prüfen Sie den Ablauf der Zertifikate:

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

"sudo kubeadm alpha certs check-expiration"

Prüfen Sie das Zertifikat von 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

Anthos-Cluster auf VMware mit Anthos Service Mesh Version 1.7 oder höher verwenden

Wenn Sie Anthos-Cluster auf VMware mit Anthos Service Mesh ab Version 1.7 verwenden und ein Upgrade auf Anthos-Cluster auf VMware-Version 1.6.0–1.6.3 oder Anthos-Cluster auf VMware-Version 1.7.0–1.7.2 durchführen möchten, müssen Sie die Labels bundle.gke.io/component-name und bundle.gke.io/component-version aus den folgenden benutzerdefinierten Ressourcendefinitionen entfernen:

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

Führen Sie diesen Befehl aus, um die CRD destinationrules.networking.istio.io in Ihrem Nutzercluster zu aktualisieren:
```
kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG
```
Entfernen Sie die Labels bundle.gke.io/component-version und bundle.gke.io/component-name aus der CRD.

Alternativ können Sie ein Upgrade direkt auf 1.6.4 oder 1.7.3 ausführen.

Das Upgrade der Administrator-Workstation kann fehlschlagen, wenn das Datenlaufwerk fast voll ist

Wenn Sie die Admin-Workstation mit dem Befehl gkectl upgrade admin-workstation aktualisieren und das Datenlaufwerk fast voll ist, kann die Aktualisierung fehlschlagen, da das System versucht, die aktuelle Admin-Workstation lokal zu sichern, während die Aktualisierung auf eine neue Admin-Workstation erfolgt. Wenn Sie nicht genügend Speicherplatz auf dem Datenlaufwerk löschen können, verwenden Sie den Befehl gkectl upgrade admin-workstation mit dem zusätzlichen Flag --backup-to-local=false, um eine lokale Sicherung der aktuellen Administrator-Workstation zu verhindern.

vCenter für Versionen unter 7.0U2 neu starten oder aktualisieren

Wenn das vCenter für Versionen unter 7.0U2 nach einem Upgrade oder anderweitig neu gestartet wird, ist der Netzwerkname in vm-Informationen von vCenter falsch und führt dazu, dass sich der Computer im Status Unavailable befindet. Dies führt dazu, dass die Knoten automatisch repariert werden, um neue Knoten zu erstellen.

Zugehöriger govmomi-Fehler: https://github.com/vmware/govmomi/issues/2552

Diese Problemumgehung wird vom VMware-Support bereitgestellt:

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.