Problemi noti

Questo documento descrive i problemi noti relativi alla versione 1.9 di Cluster Anthos su VMware (GKE On-Prem).

/var/log/audit/ riempire lo spazio su disco

Categoria

Sistema operativo

Versioni identificate

1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+

Sintomi

/var/log/audit/ contiene audit log. Puoi controllare l'utilizzo del disco eseguendo sudo du -h -d 1 /var/log/audit.

Causa

A partire da Anthos v1.8, l'immagine Ubuntu è protetta da benchmark CIS di livello 2. Inoltre, una delle regole di conformità, 4.1.2.2 Ensure audit logs are not automatically deleted, garantisce l'impostazione controllata max_log_file_action = keep_logs. In questo modo tutte le regole di controllo vengono conservate sul disco.

Soluzione alternativa

Workstation di amministrazione

Per la workstation di amministrazione, puoi modificare manualmente le impostazioni controllate per far ruotare automaticamente i log, quindi riavviare il servizio controllato:

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

L'impostazione descritta sopra comporta la rotazione automatica dei log controllati una volta generati più di 250 file (ciascuno con dimensioni di 8 milioni).

Nodi cluster

Per i nodi del cluster, applica il seguente DaemonSet al tuo cluster per evitare potenziali problemi:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

Tieni presente che apportare questa modifica alla configurazione controllata violerebbe la regola CIS di livello 2 4.1.2.2 Ensure audit logs are not automatically deleted.

systemd-timesyncd non in esecuzione dopo il riavvio sul nodo Ubuntu

Categoria

Sistema operativo

Versioni identificate

1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+

Sintomi

systemctl status systemd-timesyncd dovrebbe mostrare che il servizio è inattivo:

● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)

Ciò potrebbe causare problemi di timeout della sincronizzazione.

Causa

chrony è stato installato in modo errato sull'immagine del sistema operativo Ubuntu e si è verificato un conflitto tra chrony e systemd-timesyncd, per cui systemd-timesyncd è diventato inattivo e chrony è diventato attivo ogni volta che una VM Ubuntu è stata riavviata. Tuttavia, systemd-timesyncd deve essere il client ntp predefinito della VM.

Soluzione alternativa

Opzione 1: esegui manualmente restart systemd-timesyncd ogni volta che una VM viene riavviata.

Opzione 2: esegui il deployment del seguente daemonset in modo che systemd-timesyncd venga sempre riavviato se è morto.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ensure-systemd-timesyncd
spec:
  selector:
    matchLabels:
      name: ensure-systemd-timesyncd
  template:
    metadata:
      labels:
        name: ensure-systemd-timesyncd
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: ensure-systemd-timesyncd
        # Use your preferred image.
        image: ubuntu
        command:
        - /bin/bash
        - -c
        - |
          while true; do
            echo $(date -u)
            echo "Checking systemd-timesyncd status..."
            chroot /host systemctl status systemd-timesyncd
            if (( $? != 0 )) ; then
              echo "Restarting systemd-timesyncd..."
              chroot /host systemctl start systemd-timesyncd
            else
              echo "systemd-timesyncd is running."
            fi;
            sleep 60
          done
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: "10Mi"
            cpu: "10m"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

Risorsa personalizzata ClientConfig

gkectl update ripristina eventuali modifiche manuali apportate alla risorsa personalizzata ClientConfig. Consigliamo vivamente di eseguire il backup della risorsa ClientConfig dopo ogni modifica manuale.

Convalida di gkectl check-config non riuscita: impossibile trovare le partizioni BIG-IP di F5

Sintomi: La convalida non va a buon fine perché non è possibile trovare le partizioni F5 BIG-IP, anche se esistono.
Potenziali cause: Un problema con l'API F5 BIG-IP può causare la mancata riuscita della convalida.
Risoluzione: Prova a eseguire di nuovo gkectl check-config.

Interruzione dei carichi di lavoro con PodDisruptionBudget

L'upgrade dei cluster può causare interruzioni o tempi di inattività per i carichi di lavoro che utilizzano PodDisruptionBudget (PDB).

I nodi non completano il processo di upgrade

Se hai configurato PodDisruptionBudget oggetti che non sono in grado di consentire ulteriori interruzioni, gli upgrade dei nodi potrebbero non riuscire a eseguire l'upgrade alla versione del piano di controllo dopo tentativi ripetuti. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consentire il svuotamento del nodo pur rispettando la configurazione PodDisruptionBudget.

Per visualizzare tutti gli oggetti PodDisruptionBudget che non consentono interruzioni:

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

Installazione del cluster utente non riuscita a causa di un problema di propaganda leader del certificato/ca-injector in Anthos 1.9.0

Potresti riscontrare un errore di installazione dovuto a cert-manager-cainjector in CrashLoop, quando l'apiserver/etcd è lento. Il seguente comando,

  kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector

potrebbe produrre qualcosa di simile ai seguenti log:

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

Esegui i comandi seguenti per mitigare il problema.

Per prima cosa, fare lo scale down di monitoring-operator in modo che non ripristini le modifiche al deployment di cert-manager-cainjector.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

In secondo luogo, applica il patch del deployment di cert-manager-cainjector per disabilitare le elezioni leader, il che è sicuro perché abbiamo una sola replica in esecuzione. Non è necessaria per una singola replica.

# Ensure that we run only 1 cainjector replica, even during rolling updates.
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch '
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
'
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[
    {
        "op": "add",
        "path": "/spec/template/spec/containers/0/args/-",
        "value": "--leader-elect=false"
    }
]'

Mantieni monitoring-operator repliche a 0 come mitigazione fino al termine dell'installazione. In caso contrario, la modifica verrà annullata.

Al termine dell'installazione e quando il cluster è in esecuzione, attiva monitoring-operator per le operazioni day-2:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=1

Dopo l'upgrade alla versione 1.9.1 o successiva, questi passaggi non saranno più necessari, poiché Anthos disattiverà l'elezione leader per il cainjector.

Potrebbe essere necessario il rinnovo dei certificati prima di un upgrade del cluster di amministrazione

Prima di iniziare il processo di upgrade del cluster di amministrazione, assicurati che i certificati del cluster di amministrazione siano attualmente validi e rinnovali se non lo sono.

Procedura di rinnovo del certificato del cluster di amministrazione

Assicurati che OpenSSL sia installato sulla workstation di amministrazione prima di iniziare.
Imposta la variabile KUBECONFIG:
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
Sostituisci ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG con il percorso assoluto al file kubeconfig del cluster di amministrazione.

Ottieni l'indirizzo IP e le chiavi SSH per il nodo master di amministrazione:

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

Controlla se i certificati sono scaduti:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
Se i certificati sono scaduti, devi rinnovarli prima di eseguire l'upgrade del cluster di amministrazione.
Poiché anche il file kubeconfig del cluster di amministrazione scade se i certificati amministrativi scadono, devi eseguire il backup di questo file prima della scadenza.
- Esegui il backup del file kubeconfig del cluster di amministrazione:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
- Sostituisci client-certificate-data e client-key-data in kubeconfig con client-certificate-data e client-key-data nel file new_admin.conf che hai creato.

Esegui il backup dei vecchi certificati:

Si tratta di un passaggio facoltativo, ma consigliato.

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

Rinnova i certificati con kubeadm:

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

Riavvia i pod statici in esecuzione sul nodo master amministrativo:

  # 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

Devi convalidare i certificati rinnovati e il certificato di kube-apiserver.

Controlla la scadenza dei certificati:

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

"sudo kubeadm alpha certs check-expiration"

Controlla il certificato di 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

Riavvio o upgrade di vCenter per le versioni precedenti a 7.0U2

Se vCenter, per le versioni precedenti alla 7.0U2, viene riavviato, dopo un upgrade o in altro modo, il nome della rete in VM Informazioni da vCenter non è corretto e la macchina è in stato Unavailable. In questo modo, i nodi vengono riparati automaticamente per crearne di nuovi.

Bug govmomi correlato: https://github.com/vmware/govmomi/issues/2552

Questa soluzione alternativa è fornita dal supporto 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.

Connessione SSH chiusa dall'host remoto

Per Cluster Anthos su VMware versione 1.7.2 e successive, le immagini del sistema operativo Ubuntu sono protette da CIS L1 Server Benchmark. Per soddisfare la regola CIS "5.2.16 Assicurati che l'intervallo di timeout per inattività SSH sia configurato", /etc/ssh/sshd_config ha le seguenti impostazioni:

ClientAliveInterval 300
ClientAliveCountMax 0

Lo scopo di queste impostazioni è terminare una sessione client dopo 5 minuti di inattività. Tuttavia, il valore ClientAliveCountMax 0 causa un comportamento imprevisto. Quando utilizzi la sessione SSH sulla workstation di amministrazione o su un nodo cluster, la connessione SSH potrebbe essere disconnessa, anche se il client SSH non è inattivo, ad esempio quando viene eseguito un comando dispendioso in termini di tempo, e il comando potrebbe arrestarsi con il seguente messaggio:

Connection to [IP] closed by remote host.
Connection to [IP] closed.

In alternativa, puoi:

Utilizza nohup per impedire l'interruzione del comando sulla disconnessione SSH.

nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig

Aggiorna sshd_config per utilizzare un valore ClientAliveCountMax diverso da zero. La regola CIS consiglia di utilizzare un valore inferiore a 3.
```
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Assicurati di riconnettere la tua sessione SSH.

Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.0 o 1.9.1

Se hai una tua installazione cert-manager con Cluster Anthos su VMware, potresti riscontrare un errore quando tenti di eseguire l'upgrade alle versioni 1.9.0 o 1.9.1. Ciò è dovuto a un conflitto tra la tua versione di cert-manager, che è probabilmente installata nello spazio dei nomi di cert-manager, e la versione di monitoring-operator.

Se tenti di installare un'altra copia di cert-manager dopo l'upgrade ai cluster Anthos su VMware versione 1.9.0 o 1.9.1, l'installazione potrebbe non riuscire a causa di un conflitto con quello esistente gestito da monitoring-operator.

L'emittente del cluster metrics-ca, su cui i componenti del piano di controllo e dell'osservabilità fanno affidamento per la creazione e la rotazione di secret del certificato, richiede l'archiviazione di un secret del certificato metrics-ca nello spazio dei nomi delle risorse del cluster. Questo spazio dei nomi è kube-system per l'installazione dell'operatore di monitoraggio e probabilmente è cert-manager per l'installazione.

Se hai riscontrato un errore di installazione, segui questi passaggi per eseguire correttamente l'upgrade alle versioni 1.9.0 e 1.9.1:

Evitare conflitti durante l'upgrade

Disinstalla la tua versione di cert-manager. Se hai definito le tue risorse, potresti voler eseguire il backup delle risorse.
Esegui l'upgrade.
Segui queste istruzioni per ripristinare il tuo cert-manager.

Ripristina il tuo gestore di certificati nei cluster utente

Scala il deployment monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

Scala i deployment cert-manager gestiti da monitoring-operator a 0.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0

Reinstalla la cert-manager del cliente. Ripristina le risorse personalizzate, se disponibili.

Copia il certificato cert-manager.io/v1 di metrics-ca e le risorse dell'emittente metrics-pki.cluster.local da kube-system nello spazio dei nomi delle risorse del cluster del gestore dei certificati installato. Lo spazio dei nomi cert-manager installato è cert-manager se utilizzi l'installazione predefinita cert-manager upstream, ma dipende dall'installazione.

relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

Ripristina il tuo gestore di certificati nei cluster di amministrazione

In generale, non è necessario reinstallare il certificatore nei cluster di amministrazione perché questi ultimi eseguono solo i cluster Anthos sui carichi di lavoro del piano di controllo VMware. Nei rari casi in cui sia necessario installare un proprio gestore di certificati nei cluster di amministrazione, seguire le istruzioni riportate di seguito per evitare conflitti. Tieni presente che, se sei un cliente Apigee e ti serve solo il gestore di certificati per Apigee, non è necessario eseguire i comandi del cluster di amministrazione.

Scala il deployment monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

Scala i deployment cert-manager gestiti da monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0

Reinstalla la cert-manager del cliente. Ripristina le risorse personalizzate, se disponibili.

relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.2 o successiva

Nella versione 1.9.2 o successiva, monitoring-operator installerà cert-manager nello spazio dei nomi cert-manager. Se per determinati motivi devi installare il tuo gestore di certificati, segui le istruzioni riportate di seguito per evitare conflitti:

Evitare conflitti durante l'upgrade

Disinstalla la tua versione di cert-manager. Se hai definito le tue risorse, potresti voler eseguire il backup delle risorse.
Esegui l'upgrade.
Segui queste istruzioni per ripristinare il tuo cert-manager.

Ripristina il tuo gestore di certificati nei cluster utente

Scala il deployment monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

Scala i deployment cert-manager gestiti da monitoring-operator a 0.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

Reinstalla la cert-manager del cliente. Ripristina le risorse personalizzate, se disponibili.

Puoi saltare questo passaggio se utilizzi l'installazione predefinita cert-manager upstream oppure hai la certezza che il tuo cert-manager sia installato nello spazio dei nomi cert-manager. In caso contrario, copia il certificato metrics-ca cert-manager.io/v1 e le risorse dell'emittente metrics-pki.cluster.local da cert-manager nello spazio dei nomi delle risorse del cluster del gestore di certificati installato.

relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n cert-manager metrics-ca -o json | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

Ripristina il tuo gestore di certificati nei cluster di amministrazione

Scala il deployment monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

Scala i deployment cert-manager gestiti da monitoring-operator a 0.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

Reinstalla la cert-manager del cliente. Ripristina le risorse personalizzate, se disponibili.

relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n cert-manager metrics-ca -o json | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

Falsi positivi nell'analisi delle vulnerabilità docker, containerd ed runc

Il Docker, il containerd e il runc nelle immagini del sistema operativo Ubuntu forniti con Cluster Anthos su VMware sono bloccati su versioni speciali utilizzando Ubuntu PPA. Ciò garantisce che tutte le modifiche al runtime dei container siano qualificate dai cluster Anthos su VMware prima di ogni release.

Tuttavia, le versioni speciali sono sconosciute al tracker CVE Ubuntu, che viene utilizzato come feed di vulnerabilità da vari strumenti di scansione CVE. Pertanto, vedrai falsi positivi nei risultati dell'analisi delle vulnerabilità Docker, containerd e runc.

Ad esempio, potresti vedere i seguenti falsi positivi nei risultati della scansione di CVE. Queste CVE sono già state risolte nelle versioni più recenti delle patch di Cluster Anthos su VMware.

Fai riferimento alle note di rilascio per eventuali correzioni di CVE.

Canonical è a conoscenza di questo problema e la correzione viene tracciata all'indirizzo https://github.com/canonical/sec-cvescan/issues/73.

Pod server di konnectivity in stato non integro quando si utilizza il bilanciatore del carico di Seesaw o in modalità manuale

Se utilizzi Seesaw o il bilanciatore del carico in modalità manuale, potresti notare che i pod del server konnectivity non sono integri. Ciò accade perché Seesaw non supporta il riutilizzo di un indirizzo IP in un servizio. Per la modalità manuale, la creazione di un servizio di bilanciamento del carico non esegue automaticamente il provisioning del servizio sul bilanciatore del carico.

Il tunneling SSH è abilitato nei cluster della versione 1.9. Pertanto, anche se il server konnectivity non è integro, puoi comunque utilizzare il tunnel SSH, in modo che la connettività all'interno del cluster non ne risenta. Pertanto, non è necessario preoccuparsi di questi pod in stato non integro.

Se si prevede di eseguire l'upgrade dalla versione 1.9.0 alla 1.9.x, si consiglia di eliminare i deployment del server konnectivity in stato non integro prima dell'upgrade. Esegui questo comando.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

`/etc/cron.daily/aide` problema di picco di CPU e memoria

A partire dai cluster Anthos su VMware versione 1.7.2, le immagini del sistema operativo Ubuntu sono protette con CIS L1 Server Benchmark.

Di conseguenza, lo script cron /etc/cron.daily/aide è stato installato in modo da pianificare un controllo aide, per garantire che venga rispettata la regola del server CIS L1 "1.4.2 Assicurati che l'integrità del file system sia controllata regolarmente".

Il cron job viene eseguito ogni giorno alle 06:25 UTC. A seconda del numero di file nel file system, potresti riscontrare picchi di utilizzo della CPU e della memoria durante questo periodo aide.

Se i picchi interessano il tuo carico di lavoro, puoi disabilitare il cron job giornaliero:

`sudo chmod -x /etc/cron.daily/aide`.

I bilanciatori del carico e le regole firewall distribuiti con stateful NSX-T interagiscono in modo imprevedibile

Quando si esegue il deployment di Cluster Anthos su VMware versione 1.9 o successiva, quando il deployment ha il bilanciatore del carico in bundle Seesaw in un ambiente che utilizza le regole firewall stateful NSX-T, stackdriver-operator potrebbe non riuscire a creare ConfigMap di gke-metrics-agent-conf e causare gke-connect-agent pod in un loop di arresto anomalo.

Il problema sottostante è che le regole del firewall distribuito NSX-T stateful interrompono la connessione da un client al server API del cluster utente tramite il bilanciatore del carico di Seesaw, poiché quest'ultimo utilizza flussi di connessione asimmetrici. I problemi di integrazione con le regole firewall distribuite di NSX-T interessano tutti Cluster Anthos su VMware che utilizzano Seesaw. Potresti riscontrare problemi di connessione simili sulle tue applicazioni quando creano oggetti Kubernetes di grandi dimensioni e di dimensioni superiori a 32.000. Segui queste istruzioni per disattivare le regole firewall distribuite NSX-T o per utilizzare le regole firewall distribuite stateless per le VM Seesaw.

Se i tuoi cluster utilizzano un bilanciatore del carico manuale, segui queste istruzioni per configurare il bilanciatore del carico in modo da reimpostare le connessioni client quando rileva un errore del nodo di backend. Senza questa configurazione, i client del server API Kubernetes potrebbero non rispondere più per diversi minuti quando un'istanza di server non è disponibile.

Mancata registrazione del cluster di amministrazione durante la creazione

Se crei un cluster di amministrazione per la versione 1.9.xo 1.10.0 e se il cluster di amministrazione non viene registrato con la specifica gkeConnect fornita durante la creazione, viene visualizzato il seguente errore.

  Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

Potrai comunque utilizzare questo cluster di amministrazione, ma riceverai il seguente errore se in seguito tenti di eseguire l'upgrade del cluster di amministrazione alla versione 1.10.y.

  failed to migrate to first admin trust chain: failed to parse current version "":
  invalid version: "" failed to migrate to first admin trust chain: failed to parse
  current version "": invalid version: ""

Se si verifica questo errore, segui questi passaggi per risolvere il problema della registrazione del cluster. Una volta completata l'operazione, potrai eseguire l'upgrade del cluster di amministrazione.

Fornisci govc, l'interfaccia a riga di comando a vSphere, alcune variabili che dichiarano gli elementi dell'ambiente vCenter Server e vSphere.

Nota: puoi trovare molti di questi valori nel file di configurazione del cluster di amministrazione o accedendo a vCenter Server
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
Sostituisci quanto segue:
- VCENTER_SERVER_ADDRESS è l'indirizzo IP o il nome host del tuo vCenter Server.
- VCENTER_SERVER_USERNAME è il nome utente di un account che ha il ruolo Amministratore o privilegi equivalenti in vCenter Server.
- VCENTER_SERVER_PASSWORD è la password dell'account vCenter Server.
- VSPHERE_DATASTORE è il nome del datastore configurato nel tuo ambiente vSphere.
- VSPHERE_DATACENTER è il nome del data center che hai configurato nel tuo ambiente vSphere.
- DATA_DISK_NAME è il nome del disco dati.

Scarica il file DATA_DISK_NAME‑checkpoint.yaml.

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

Modifica i campi del checkpoint.

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster -n kube-system $ADMIN_CLUSTER_NAME -o=jsonpath='{.spec.gkeOnPremVersion}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

Genera un nuovo checksum.
- Cambia l'ultima riga del file del checkpoint in
```
checksum:$NEW_CHECKSUM
```
  Sostituisci NEW_CHECKSUM con l'output del seguente comando:
```
sha256sum temp-checkpoint.yaml
```

Carica il nuovo file di checkpoint.

govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml

L'utilizzo del servizio Anthos Identity può causare il riavvio imprevedibile dell'agente Connect

Se utilizzi la funzionalità Anthos Identity Service per gestire Anthos Identity Service ClientConfig, l'agente Connect potrebbe riavviarsi in modo imprevisto.

Se hai riscontrato questo problema in un cluster esistente, puoi procedere in uno dei seguenti modi:

Disattiva Anthos Identity Service (AIS). Se disabiliti AIS, il codice binario AIS di cui è stato eseguito il deployment non verrà rimosso e non verrà rimosso ClientConfig di AIS. Per disabilitare AIS, esegui questo comando:
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
Sostituisci PROJECT_NAME con il nome del progetto host del parco risorse del cluster.
Aggiorna il cluster alla versione 1.9.3, 1.10.1 o versioni successive, in modo da eseguire l'upgrade della versione di Connect Agent.

Traffico di rete elevato verso monitoring.googleapis.com

Potresti vedere un traffico di rete elevato verso monitoraggio.googleapis.com, anche in un nuovo cluster privo di carichi di lavoro utente.

Questo problema riguarda le versioni 1.10.0-1.10.1 e 1.9.0-1.9.4. Questo problema è stato risolto nelle versioni 1.10.2 e 1.9.5.

Per risolvere il problema, esegui l'upgrade alla versione 1.10.2/1.9.5 o successiva.

Per risolvere il problema per una versione precedente:

Scale down stackdriver-operator:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

Apri il ConfigMap di gke-metrics-agent-conf per la modifica:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit configmap gke-metrics-agent-conf

Aumenta l'intervallo del probe da 0,1 secondi a 13 secondi:

processors:
  disk_buffer/metrics:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-metrics
    probe_interval: 13s
    retention_size_mib: 6144
 disk_buffer/self:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-self
    probe_interval: 13s
    retention_size_mib: 200
  disk_buffer/uptime:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-uptime
    probe_interval: 13s
    retention_size_mib: 200

Chiudi la sessione di modifica.

Cambia la versione gke-metrics-agent DaemonSet alla versione 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

Metriche mancanti su alcuni nodi

Su alcuni nodi potresti notare che mancano alcune delle seguenti metriche:

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

Per risolvere questo problema:

[versione 1.9.5+]: aumenta la CPU per gke-metrics-agent seguendo i passaggi 1-4
[versione 1.9.0-1.9.4]: segui i passaggi 1 - 9

Apri la risorsa stackdriver per la modifica:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

Per aumentare la richiesta di CPU per gke-metrics-agent da 10m a 50m, aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver :

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

La risorsa modificata dovrebbe essere simile alla seguente:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Salva le modifiche e chiudi l'editor di testo.
Per verificare che le modifiche siano state applicate, esegui questo comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
Il comando trova cpu: 50m se le modifiche sono state applicate.

Per evitare che le seguenti modifiche vengano annullate, fare lo scale down di stackdriver-operator:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0

Apri gke-metrics-agent-conf per modificare:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

Modifica la configurazione per cambiare tutte le istanze di probe_interval: 0.1s in probe_interval: 13s:

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Salva le modifiche e chiudi l'editor di testo.

Cambia la versione gke-metrics-agent DaemonSet alla versione 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

Cisco ACI non funziona con il reso diretto da server (DSR)

Seesaw viene eseguito in modalità DSR e, per impostazione predefinita, non funziona in Cisco ACI a causa dell'apprendimento IP del piano dati. Una possibile soluzione alternativa è disabilitare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 in Cisco Application Policy Infrastructure Controller (APIC).

Per configurare l'opzione IP virtuale L4-L7, vai a Tenant > Profili di applicazione > EPG di applicazioni o EPG uSeg. Se non disattivi l'apprendimento IP, l'endpoint IP si sposterà tra diverse posizioni nel tessuto dell'API Cisco.

gkectl diagnostica controllo errori certificati

Se la tua postazione di lavoro non ha accesso ai nodi worker del cluster utente, verranno eseguiti i seguenti errori durante l'esecuzione di gkectl diagnose, pertanto puoi ignorarli.

Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

Problemi noti

/var/log/audit/ riempire lo spazio su disco

Categoria

Versioni identificate

Sintomi

Causa

Soluzione alternativa

Workstation di amministrazione

Nodi cluster

systemd-timesyncd non in esecuzione dopo il riavvio sul nodo Ubuntu

Categoria

Versioni identificate

Sintomi

Causa

Soluzione alternativa

Risorsa personalizzata ClientConfig

Convalida di gkectl check-config non riuscita: impossibile trovare le partizioni BIG-IP di F5

Interruzione dei carichi di lavoro con PodDisruptionBudget

I nodi non completano il processo di upgrade

Installazione del cluster utente non riuscita a causa di un problema di propaganda leader del certificato/ca-injector in Anthos 1.9.0

Potrebbe essere necessario il rinnovo dei certificati prima di un upgrade del cluster di amministrazione

Procedura di rinnovo del certificato del cluster di amministrazione

Riavvio o upgrade di vCenter per le versioni precedenti a 7.0U2

Connessione SSH chiusa dall'host remoto

Conflitto con cert-manager durante l'upgrade alla versione 1.9.0 o 1.9.1

Evitare conflitti durante l'upgrade

Ripristina il tuo gestore di certificati nei cluster utente

Ripristina il tuo gestore di certificati nei cluster di amministrazione

Conflitto con cert-manager durante l'upgrade alla versione 1.9.2 o successiva

Evitare conflitti durante l'upgrade

Ripristina il tuo gestore di certificati nei cluster utente

Ripristina il tuo gestore di certificati nei cluster di amministrazione

Falsi positivi nell'analisi delle vulnerabilità docker, containerd ed runc

Pod server di konnectivity in stato non integro quando si utilizza il bilanciatore del carico di Seesaw o in modalità manuale

/etc/cron.daily/aide problema di picco di CPU e memoria

I bilanciatori del carico e le regole firewall distribuiti con stateful NSX-T interagiscono in modo imprevedibile

Mancata registrazione del cluster di amministrazione durante la creazione

L'utilizzo del servizio Anthos Identity può causare il riavvio imprevedibile dell'agente Connect

Traffico di rete elevato verso monitoring.googleapis.com

Metriche mancanti su alcuni nodi

Cisco ACI non funziona con il reso diretto da server (DSR)

gkectl diagnostica controllo errori certificati

Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.0 o 1.9.1

Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.2 o successiva

`/etc/cron.daily/aide` problema di picco di CPU e memoria