Problemas conocidos

En este documento, se describen los problemas conocidos de la versión 1.9 de los clústeres de Anthos alojados en VMware (GKE On-Prem).

/var/log/audit/ llenar el espacio del disco

Categoría

Versiones identificadas

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

Síntomas

/var/log/audit/ está lleno de registros de auditoría. Para verificar el uso del disco, ejecuta sudo du -h -d 1 /var/log/audit.

Causa

A partir de Anthos v1.8, la imagen de Ubuntu está endurecida con la comparativa de CIS de nivel 2. Y una de las reglas de cumplimiento, 4.1.2.2 Ensure audit logs are not automatically deleted, garantiza la configuración auditada de max_log_file_action = keep_logs. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.

Solución alternativa

Estación de trabajo de administrador

En la estación de trabajo de administrador, puedes cambiar de forma manual la configuración de auditd para rotar los registros de forma automática y, luego, reiniciar el servicio auditd:

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

Con la configuración anterior, se auditarían los registros de rotación automática una vez que se hayan generado más de 250 archivos (cada uno con un tamaño de 8 millones).

Nodos del clúster

En los nodos del clúster, aplica el siguiente DaemonSet a tu clúster para evitar posibles problemas:

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: /

Ten en cuenta que realizar este cambio de configuración auditado infringiría la regla de CIS nivel 2 4.1.2.2 Ensure audit logs are not automatically deleted.

No se ejecuta systemd-timesyncd después de reiniciar en el nodo de Ubuntu

Categoría

Versiones identificadas

1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0 y posteriores

Síntomas

systemctl status systemd-timesyncd debe mostrar que el servicio no está disponible:

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

Esto podría causar problemas de tiempo de desincronización.

Causa

chrony se instaló de forma incorrecta en la imagen de SO Ubuntu. Existe un conflicto entre chrony y systemd-timesyncd, en el que systemd-timesyncd se vuelve inactivo y chrony cada vez que se reinicia la VM de Ubuntu. Sin embargo, systemd-timesyncd debería ser el cliente ntp predeterminado para la VM.

Solución alternativa

Opción 1: Ejecuta restart systemd-timesyncd de forma manual cada vez que se reinicie la VM.

Opción 2: Implementa el Daemonset siguiente para que systemd-timesyncd siempre se reinicie si no funciona.

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: /

Recurso personalizado de ClientConfig

gkectl update revierte los cambios manuales que realizaste al recurso personalizado ClientConfig. Te recomendamos crear una copia de seguridad del recurso ClientConfig después de cada cambio manual.

La validación check-config de gkectl falla: no se pueden encontrar las particiones de BIG-IP de F5

Síntomas: La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
Causas posibles: Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
Solución: Vuelve a ejecutar gkectl check-config.

Interrupción de las cargas de trabajo con PodDisruptionBudgets

La actualización de los clústeres puede causar interrupciones o tiempo de inactividad para las cargas de trabajo que usan PodDisruptionBudgets (PDB).

El proceso de actualización de los nodos falla

Si tienes objetos PodDisruptionBudget configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment o la HorizontalPodAutoscaler a fin de permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten ninguna interrupción, haz lo siguiente:

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

No se pudo instalar el clúster de usuario debido al problema de elección de líder de cert-manager/ca-injector en Anthos 1.9.0

Es posible que veas una falla de instalación debido a cert-manager-cainjector en el modo de bloqueo, cuando apiserver/etcd es lento. El siguiente comando:

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

podrían producir algo como los siguientes registros:

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"

Ejecuta los siguientes comandos para mitigar el problema.

Primero, reduce la escala de monitoring-operator para que no revierta los cambios a la implementación cert-manager-cainjector.

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

En segundo lugar, aplica un parche a la implementación de cert-manager-cainjector para inhabilitar la elección de líder, lo cual es seguro, ya que solo tenemos una réplica en ejecución. No es necesario si hay una sola réplica.

# 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"
    }
]'

Mantén las réplicas de monitoring-operator en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio.

Una vez que finalice la instalación y el clúster esté en funcionamiento, activa monitoring-operator para las operaciones del día 2:

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

Después de actualizar a la versión 1.9.1 o posterior, estos pasos ya no serán necesarios, ya que Anthos inhabilitará la elección de líder para el cainjector.

Puede que sea necesario renovar los certificados antes de que se actualice el clúster de administrador

Antes de comenzar el proceso de actualización de clústeres de administrador, debes asegurarte de que tus certificados de clúster de administrador sean actualmente válidos y renovarlos si no lo son.

Proceso de renovación del certificado del clúster de administrador

Antes de comenzar, asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador.
Configura la variable KUBECONFIG.
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
Reemplaza ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG por la ruta absoluta al archivo kubeconfig del clúster de administrador.

Obtén la dirección IP y las claves SSH del nodo principal 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')

Verifica si los certificados vencieron:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
```
Si los certificados vencieron, debes renovarlos antes de actualizar el clúster de administrador.

Crea una copia de seguridad de los certificados anteriores:

Este es un paso opcional, pero recomendado.

# ssh into admin master
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 .

Renueva los certificados 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

Reinicia los pods estáticos que se ejecutan en el nodo principal del 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

Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes de la fecha de vencimiento.
- Crea una copia de seguridad del archivo kubeconfig del clúster de administrador:
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 

"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
- Reemplaza client-certificate-data y client-key-data en la kubeconfig por client-certificate-data y client-key-data en el archivo new_admin.conf que creaste.

Debes validar los certificados renuevas y el certificado de kube-apiserver.

Verifica el vencimiento de los certificados:

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

"sudo kubeadm alpha certs check-expiration"

Verifica el certificado de 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

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Si vCenter, en versiones anteriores a 7.0U2, se reinicia después de una actualización o de otra manera, el nombre de red en la información de VM de vCenter es incorrecto y hace que la máquina esté en un estado Unavailable. Finalmente, esto hace que los nodos se reparen automáticamente para crear otros nuevos.

Error relacionado de govmomi: https://github.com/vmware/govmomi/issues/2552

La solución alternativa la proporciona la asistencia de 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.

Conexión SSH cerrada por host remoto

Para los clústeres de Anthos alojados en VMware versión 1.7.2 y posteriores, las imágenes del SO de Ubuntu se endurecen con la comparativa del servidor L1 de CIS. Para cumplir con la regla de CIS “5.2.16 Asegúrate de que el intervalo de tiempo de espera de inactividad de SSH esté configurado”, /etc/ssh/sshd_config tiene la siguiente configuración:

ClientAliveInterval 300
ClientAliveCountMax 0

El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0 genera un comportamiento inesperado. Cuando uses la sesión SSH en la estación de trabajo de administrador o un nodo del clúster, la conexión SSH podría desconectarse, incluso si tu cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y tu comando podría finalizar con el siguiente mensaje:

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

Como solución alternativa, puedes hacer lo siguiente:

Usa nohup para evitar que el comando se finalice cuando te desconectes de SSH.

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

Actualiza sshd_config para usar un valor ClientAliveCountMax distinto de cero. La regla de CIS recomienda usar un valor inferior a 3.
```
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Asegúrate de volver a conectar tu sesión SSH.

Conflicto con `cert-manager` cuando se actualiza a la versión 1.9.0 o 1.9.1

Si tienes tu propia instalación de cert-manager con clústeres de Anthos alojados en VMware, es posible que experimentes una falla cuando intentes actualizar a las versiones 1.9.0 o 1.9.1. Esto es el resultado de un conflicto entre tu versión de cert-manager, que probablemente esté instalada en el espacio de nombres cert-manager, y la versión monitoring-operator.

Si intentas instalar otra copia de cert-manager después de actualizar a los clústeres de Anthos alojados en VMware 1.9.0 o 1.9.1, es posible que la instalación falle debido a un conflicto con el existente administrado por monitoring-operator.

La entidad emisora del clúster metrics-ca, en el que se basan los componentes del plano de control y la observabilidad para la creación y rotación de los secretos de certificado, requiere que un secreto de certificado metrics-ca se almacene en el espacio de nombres del recurso del clúster. Este espacio de nombres es kube-system para la instalación del operador de supervisión, y es probable que sea cert-manager para la instalación.

Si experimentaste una falla de instalación, sigue estos pasos para actualizar con éxito a las versiones 1.9.0 y 1.9.1:

Evita conflictos durante la actualización

Desinstala tu versión de cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos.
Realiza la actualización.
Sigue las siguientes instrucciones para restablecer tu propio cert-manager.

Restablece tu cert-manager en clústeres de usuario

Escala la implementación de monitoring-operator a 0.

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

Escala las implementaciones de cert-manager administradas por 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

Reinstala el cert-manager del cliente. Restablecer los recursos personalizados si los tienes

Copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de kube-system al espacio de nombres del recurso del clúster de tu cert-manager instalado. El espacio de nombres cert-manager instalado es cert-manager si se usa la instalación cert-manager predeterminada ascendente, pero eso depende de la instalación.

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

Restablece tus cert-manager en clústeres de administrador

En general, no es necesario volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan clústeres de Anthos en las cargas de trabajo del plano de control de VMware. En los casos poco frecuentes en los que también necesites instalar tu propio cert-manager en clústeres de administrador, sigue estas instrucciones para evitar conflictos. Tenga en cuenta que, si es cliente de Apigee y solo necesita cert-manager para Apigee, no necesita ejecutar los comandos del clúster de administrador.

Escala la implementación de monitoring-operator a 0.

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

Escala las implementaciones de cert-manager administradas por 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

Reinstala el cert-manager del cliente. Restablecer los recursos personalizados si los tienes

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

Conflicto con `cert-manager` cuando se actualiza a la versión 1.9.2 o superior

En las versiones 1.9.2 o posteriores, monitoring-operator instalará cert-manager en el espacio de nombres cert-manager. Si por ciertas razones, necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:

Evita conflictos durante la actualización

Desinstala tu versión de cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos.
Realiza la actualización.
Sigue las siguientes instrucciones para restablecer tu propio cert-manager.

Restablece tu cert-manager en clústeres de usuario

Escala la implementación de monitoring-operator a 0.

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

Escala las implementaciones de cert-manager administradas por 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

Reinstala el cert-manager del cliente. Restablecer los recursos personalizados si los tienes

Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que tu cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado.

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

Restablece tus cert-manager en clústeres de administrador

Escala la implementación de monitoring-operator a 0.

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

Escala las implementaciones de cert-manager administradas por 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

Reinstala el cert-manager del cliente. Restablecer los recursos personalizados si los tienes

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

Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc

Docker, containerd y runc en las imágenes del SO de Ubuntu enviadas con clústeres de Anthos alojados en VMware se fijan a versiones especiales mediante PPA de Ubuntu. Esto garantiza que los clústeres de Anthos en VMware califiquen los cambios en el entorno de ejecución del contenedor antes de cada actualización.

Sin embargo, las versiones especiales no son conocidas para la Herramienta de seguimiento de CVE de Ubuntu, que se usa como feed de vulnerabilidad en varias herramientas de análisis de CVE. Por lo tanto, verás falsos positivos en los resultados del análisis de vulnerabilidades de Docker, containerd y runc.

Por ejemplo, es posible que veas los siguientes falsos positivos en los resultados del análisis de CVE. Estas CVE ya se corrigen en las últimas versiones de parche de los clústeres de Anthos en VMware.

Consulta las notas de la versión para conocer las correcciones de CVE.

La canonicalización está al tanto de este problema, y la corrección se rastrea en https://github.com/Canonical/sec-cvescan/issues/73.

Pods de mal estado de los servidores cuando se usa el balanceador de cargas de Seesaw o de modo manual

Si usas Seesaw o el balanceador de cargas en modo manual, es posible que notes que los Pods del servidor de konnectivity están en mal estado. Esto sucede porque Seesaw no admite la reutilización de una dirección IP en un servicio. Para el modo manual, la creación de un servicio de balanceador de cargas no aprovisiona de forma automática el servicio en el balanceador de cargas.

Los túneles SSH están habilitados en los clústeres de la versión 1.9. Por lo tanto, incluso si el servidor de konnectivity no está en buen estado, puedes usar el túnel SSH para que la conectividad hacia el clúster y dentro de él no se vea afectada. Por lo tanto, no debes preocuparte por estos Pods en mal estado.

Si planeas actualizar de la versión 1.9.0 a 1.9.x, te recomendamos que borres las implementaciones del servidor de konnectivity en mal estado antes de realizar la actualización. Ejecute este comando:

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

`/etc/cron.daily/aide` Problema de aumento de memoria y CPU

A partir de los clústeres de Anthos alojados en VMware versión 1.7.2, las imágenes del SO Ubuntu se endurecen con la comparativa del servidor L1 de CIS.

Como resultado, se instaló la secuencia de comandos cron /etc/cron.daily/aide para que se programe una verificación aide a fin de garantizar que se siga la regla de CIS L1 “1.4.2 Asegúrate de que se verifique con regularidad la integridad del sistema de archivos”.

El trabajo cron se ejecuta todos los días a las 6:25 a.m. UTC. Según la cantidad de archivos del sistema de archivos, es posible que experimentes aumentos repentinos del uso de memoria y CPU durante ese período debido a este proceso aide.

Si los aumentos afectan tu carga de trabajo, puedes inhabilitar el trabajo cron diario:

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

Los balanceadores de cargas y las reglas de firewall distribuido con estado de NSX-T interactúan de forma impredecible

Cuando implementas clústeres de Anthos en la versión 1.9 o posterior de VMware, cuando la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall con estado de NSX-T, stackdriver-operator podría no crear un ConfigMap gke-metrics-agent-conf y provocar que los Pods gke-connect-agent entren en un bucle de fallas.

El problema subyacente es que las reglas de firewall distribuido con estado de NSX-T finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw porque Seesaw usa flujos de conexión asimétricos. Los problemas de integración con las reglas de firewall distribuido de NSX-T afectan a todas las versiones de los clústeres de Anthos alojados en VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando creen objetos grandes de Kubernetes con tamaños de más de 32,000. Sigue estas instrucciones a fin de inhabilitar las reglas de firewall distribuido de NSX-T o usar reglas de firewall distribuido sin estado en las VM de Seesaw.

Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas a fin de restablecer las conexiones de clientes cuando detecte una falla del nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes podrían dejar de responder durante varios minutos cuando falla una instancia del servidor.

No se pudo registrar el clúster de administrador durante la creación

Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si el clúster de administrador no se registra con la especificación gkeConnect proporcionada durante su creación, recibirás el siguiente error.

  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

Aún podrás usar este clúster de administrador, pero recibirás el siguiente error si luego intentas actualizarlo a la versión 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: ""

Si se produce este error, sigue estos pasos para solucionar el problema de registro del clúster. Después de realizar esta corrección, puedes actualizar tu clúster de administrador.

Proporciona govc, la interfaz de línea de comandos a vSphere, algunas variables que declaran elementos de vCenter Server y el entorno de vSphere.

Nota: Puedes encontrar muchos de estos valores en el archivo de configuración del clúster de administrador o mediante el acceso al servidor de vCenter
```
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
```
Reemplaza lo siguiente:
- VCENTER_SERVER_ADDRESS es la dirección IP o el nombre de host de vCenter Server.
- VCENTER_SERVER_USERNAME es el nombre de usuario de una cuenta que contiene el rol de administrator o privilegios equivalentes en vCenter Server.
- VCENTER_SERVER_PASSWORD es la contraseña de la cuenta de vCenter Server.
- VSPHERE_DATASTORE es el nombre del almacén de datos que configuraste en el entorno de vSphere.
- VSPHERE_DATACENTER es el nombre del centro de datos que configuraste en el entorno de vSphere.
- DATA_DISK_NAME es el nombre del disco de datos.

Descarga el archivo DATA_DISK_NAME‑checkpoint.yaml.

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

Edita los campos de punto de control.

# 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

Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

Genera una suma de verificación nueva.
- Cambia la última línea del archivo de punto de control a
```
checksum:$NEW_CHECKSUM
```
  Reemplaza NEW_CHECKSUM por el resultado del siguiente comando:
```
sha256sum temp-checkpoint.yaml
```

Sube el archivo de punto de control nuevo.

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

El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible.

Si usas la función Anthos Identity Service para administrar Clientconfig de Anthos Identity Service, es posible que el agente de Connect se reinicie de forma inesperada.

Si tienes este problema con un clúster existente, puedes realizar una de las siguientes acciones:

Inhabilita Anthos Identity Service (AIS). Si inhabilitas AIS, no se quitará el objeto binario de AIS implementado ni Clientconfig de AIS. Para inhabilitar AIS, ejecuta este comando:
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
Reemplaza PROJECT_NAME por el nombre del proyecto host de la flota del clúster.
Actualiza el clúster a la versión 1.9.3, 1.10.1 o posterior, para actualizar la versión del agente de Connect.

Alto tráfico de red a monitoring.googleapis.com

Es posible que veas un tráfico de red alto a monitoring.googleapis.com, incluso en un clúster nuevo que no tiene cargas de trabajo de usuarios.

Este problema afecta a las versiones 1.10.0-1.10.1 y 1.9.0-1.9.4. Este problema se solucionó en las versiones 1.10.2 y 1.9.5.

Para solucionar este problema, actualiza a la versión 1.10.2/1.9.5 o a una posterior.

Para mitigar este problema en una versión anterior, haz lo siguiente:

Reduce verticalmente la escala de stackdriver-operator:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

Abre el ConfigMap gke-metrics-agent-conf para editar:

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

Aumenta el intervalo del sondeo de 0.1 segundos a 13 segundos:

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

Cierra la sesión de edición.

Cambia la versión de DaemonSet de gke-metrics-agent a 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

Faltan métricas en algunos nodos

Es posible que te falten las siguientes métricas en algunos nodos, pero no en todos:

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

Para solucionar este problema, haz lo siguiente:

[versión 1.9.5+]: Para aumentar la CPU de gke-metrics-agent, sigue los pasos 1 a 4
[versión 1.9.0-1.9.4]: Sigue los pasos 1 a 9.

Abre tu recurso stackdriver para editarlo:

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

Para aumentar el límite de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver:

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

El recurso editado debe ser similar al siguiente:

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

Guarda los cambios y cierra el editor de texto.
Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
El comando encuentra cpu: 50m si tus ediciones se aplicaron.

Para evitar que los cambios se reviertan, reduce verticalmente la escala de stackdriver-operator:

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

Abre gke-metrics-agent-conf para editarla:

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

Edita la configuración para cambiar todas las instancias de probe_interval: 0.1s a 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

Guarda los cambios y cierra el editor de texto.

Cambia la versión de DaemonSet de gke-metrics-agent a 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 no funciona con el retorno directo del servidor (DSR)

Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP del plano de datos. Una posible solución es inhabilitar el aprendizaje de IP agregando la dirección IP de Seesaw como una IP virtual de L4-L7 en el controlador de infraestructura de política de aplicación (APIC) de Cisco.

Para configurar la opción de IP virtual de L4-L7, ve a Usuario > Perfiles de aplicaciones > EPG de aplicación o EPG de uSeg. Si no se inhabilita el aprendizaje de IP, el extremo de IP oscilará entre diferentes ubicaciones en la estructura de la API de Cisco.

Falla de los certificados de verificación gkectl diagnose

Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, recibirá las siguientes fallas cuando se ejecute gkectl diagnose. Es seguro ignorarlas.

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

Problemas conocidos

/var/log/audit/ llenar el espacio del disco

Categoría

Versiones identificadas

Síntomas

Causa

Solución alternativa

Estación de trabajo de administrador

Nodos del clúster

No se ejecuta systemd-timesyncd después de reiniciar en el nodo de Ubuntu

Categoría

Versiones identificadas

Síntomas

Causa

Solución alternativa

Recurso personalizado de ClientConfig

La validación check-config de gkectl falla: no se pueden encontrar las particiones de BIG-IP de F5

Interrupción de las cargas de trabajo con PodDisruptionBudgets

El proceso de actualización de los nodos falla

No se pudo instalar el clúster de usuario debido al problema de elección de líder de cert-manager/ca-injector en Anthos 1.9.0

Puede que sea necesario renovar los certificados antes de que se actualice el clúster de administrador

Proceso de renovación del certificado del clúster de administrador

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Conexión SSH cerrada por host remoto

Conflicto con cert-manager cuando se actualiza a la versión 1.9.0 o 1.9.1

Evita conflictos durante la actualización

Restablece tu cert-manager en clústeres de usuario

Restablece tus cert-manager en clústeres de administrador

Conflicto con cert-manager cuando se actualiza a la versión 1.9.2 o superior

Evita conflictos durante la actualización

Restablece tu cert-manager en clústeres de usuario

Restablece tus cert-manager en clústeres de administrador

Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc

Pods de mal estado de los servidores cuando se usa el balanceador de cargas de Seesaw o de modo manual

/etc/cron.daily/aide Problema de aumento de memoria y CPU

Los balanceadores de cargas y las reglas de firewall distribuido con estado de NSX-T interactúan de forma impredecible

No se pudo registrar el clúster de administrador durante la creación

El uso de Anthos Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible.

Alto tráfico de red a monitoring.googleapis.com

Faltan métricas en algunos nodos

Cisco ACI no funciona con el retorno directo del servidor (DSR)

Falla de los certificados de verificación gkectl diagnose

Conflicto con `cert-manager` cuando se actualiza a la versión 1.9.0 o 1.9.1

Conflicto con `cert-manager` cuando se actualiza a la versión 1.9.2 o superior

`/etc/cron.daily/aide` Problema de aumento de memoria y CPU