Versión 1.8. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Versiones disponibles: 1.11 1.10 1.9 Earlier

Se usó la API de Cloud Translation para traducir esta página.

Problemas conocidos

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

/var/log/audit/ llenando espacio en disco

Categoría

Versiones identificadas

1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+ y 1.12.0+, 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 se endurece con la comparativa de CIS de nivel 2. Además, una de las reglas de cumplimiento, 4.1.2.2 Ensure audit logs are not automatically deleted, garantiza la configuración auditada 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 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

La configuración anterior haría que la auditoría rote automáticamente sus registros una vez que haya generado más de 250 archivos (cada uno con un tamaño de 8 millones).

Nodos del clúster

Para los nodos del clúster, aplica el siguiente DaemonSet a tu clúster a fin de 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 nivel 2 de CIS 4.1.2.2 Ensure audit logs are not automatically deleted.

La actualización o actualización del clúster de usuario falla debido a que “no se pudo registrar el clúster de usuario”

Categoría

Actualizar

Versiones identificadas

1.7.0+, 1.8.0 o superior

Síntomas

Ejecuta gkectl diagnose cluster cuando se agote el tiempo de espera de un comando gkectl anterior en los siguientes casos.

La actualización de clústeres de usuario con GKE Connect se habilitó en versiones 1.8.
Ejecutar gkectl update cluster en clústeres de usuario 1.8 con GKE Connect habilitado
Ejecutar gkectl update cluster para habilitar GKE Connect en clústeres de usuarios 1.8

$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
    Unhealthy Resources:
      OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...

Ten en cuenta que la funcionalidad de GKE Connect no se verá afectada. En otras palabras, si GKE Connect funcionaba antes del comando, debería seguir funcionando.

Causa

La versión 20210514-00-00 del agente de Connect que se usa en las versiones 1.8 es incompatible.

Solución alternativa

Comunícate con Atención al cliente de Google para mitigar el problema.

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

Categoría

Versiones identificadas

1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+

Síntomas

systemctl status systemd-timesyncd debe mostrar que el servicio no funciona:

● 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 inactividad.

Causa

chrony se instaló de forma incorrecta en la imagen de Ubuntu. Además, hay un conflicto entre chrony y systemd-timesyncd, en la que systemd-timesyncd se vuelve inactivo y chrony se activa cada vez que se reinicia la VM de Ubuntu. Sin embargo, systemd-timesyncd debe 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 siguiente Daemonset 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: /
````

## ClientConfig custom resource

`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.

## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions

<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>

## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}

Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).

## Nodes fail to complete their upgrade process

If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.

To see all `PodDisruptionBudget` objects that do not allow any disruptions:

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.8.2 y 1.8.3

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

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

puede 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 Deployment cert-manager-cainjector.

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

Segundo, aplique un parche a la Deployment cert-manager-cainjector para inhabilitar la elección de líder, lo cual es seguro porque 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

Ten en cuenta que, después de actualizar a la versión 1.8.4 y superior (o 1.9.1 y superior, si actualizas a la versión 1.9), estos pasos ya no serán necesarios, ya que Anthos inhabilitará la elección de líder para Cainjector. Hasta entonces, si tienes este problema durante cada actualización, deberás volver a realizar los mismos pasos.

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

Crea una copia de seguridad de los certificados anteriores:

Este es un paso opcional, pero recomendado.

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

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

Renueva los certificados de los nodos trabajadores del clúster de administrador

Verifica la fecha de vencimiento de los certificados de nodos

    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

Si el certificado está a punto de vencer, renueva los certificados de nodo mediante la reparación manual de nodos.

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

La secuencia de comandos /etc/cron.daily/aide usa todo el espacio en /run, lo que provoca un bloqueo en los Pods.

A partir de los clústeres de Anthos alojados en VMware 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 de ayuda a fin de garantizar la regla del servidor L1 de CIS “1.4.2 Asegurarse de que la integridad del sistema de archivos se verifique con regularidad”.

La secuencia de comandos usa /run/aide como directorio temporal para guardar sus registros cron y, con el tiempo, podría usar todo el espacio en /run. Consulta la secuencia de comandos /etc/cron.daily/aide usa todo el espacio en /run para obtener una solución alternativa.

Si ves que uno o más Pods se encuentran en un bucle de fallas en un nodo, ejecuta df -h /run en el nodo. Si el resultado del comando muestra un uso del 100% del espacio, es probable que estés experimentando este problema.

Este problema se corrigió en la versión 1.8.1. Para las versiones 1.7.2 y 1.8.0, puedes resolver este problema de forma manual con cualquiera de las siguientes dos soluciones:

Quita los archivos de registro de forma periódica en /run/aide/cron.daily.old* (recomendado).
Sigue los pasos mencionados en la secuencia de comandos /etc/cron.Daily/aide para usar todo el espacio de /run. (Nota: Esta solución alternativa podría afectar el estado de cumplimiento del nodo).

Actualiza el balanceador de cargas de Seesaw con la versión 1.8.0

Si usas gkectl upgrade loadbalancer para intentar actualizar algunos parámetros del balanceador de cargas de Seesaw en la versión 1.8.0, esto no funcionará en modo DHCP o IPAM. Si su configuración incluye esta configuración, no actualice a la versión 1.8.0, sino a la versión 1.8.1 o posterior.

No se puede acceder a la estación de trabajo de administrador debido a un problema de vencimiento de la contraseña

Es posible que experimentes este problema si usas una de las siguientes versiones de clústeres de Anthos alojados en VMware.

1.7.2-gke.2
1.7.3-gke.2
1.8.0-gke.21
1.8.0-gke.24
1.8.0-gke.25
1.8.1-gke.7
1.8.2-gke.8

Es posible que recibas el siguiente error cuando intentes establecer una conexión SSH a tus VM de Anthos, incluida la estación de trabajo de administrador, los nodos del clúster y los nodos de Seesaw:

WARNING: Your password has expired.

Este error se produce porque la contraseña del usuario de ubuntu en las VM está vencida. Debes restablecer de forma manual el tiempo de vencimiento de la contraseña de usuario a un valor grande antes de acceder a las VM.

Prevención de error de vencimiento de contraseña

Si ejecutas las versiones afectadas que se mencionaron antes y la contraseña del usuario aún no venció, debes extender el tiempo de vencimiento antes de ver el error de SSH.

Ejecuta el siguiente comando en cada VM de Anthos:

sudo chage -M 99999 ubuntu

Mitigación del error de vencimiento de contraseña

Si la contraseña de usuario ya venció y no puedes acceder a las VM para extender el tiempo de vencimiento, realiza los siguientes pasos de mitigación para cada componente.

Estación de trabajo de administrador

Usa una VM temporal para realizar los siguientes pasos. Puedes crear una estación de trabajo de administrador con la versión 1.7.1-gke.4 para usarla como VM temporal.

Asegúrate de que la VM temporal y la estación de trabajo de administrador estén en estado de apagado.
Adjunta el disco de arranque de la estación de trabajo de administrador a la VM temporal. El disco de arranque es el que tiene la etiqueta “Hard disk 1”.
Activa el disco de arranque dentro de la VM mediante la ejecución de estos comandos. Sustituye tu propio identificador de disco de arranque por dev/sdc1.
```
sudo mkdir -p /mnt/boot-disk
sudo mount /dev/sdc1 /mnt/boot-disk
```
Configura la fecha de vencimiento del usuario de ubuntu en un valor grande, como 99999 días.
```
sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
```
Apaga la VM temporal.
Enciende la estación de trabajo de administrador Ahora, deberías tener acceso SSH como de costumbre.
Como limpieza, borra la VM temporal.

VM del plano de control del clúster de administrador

Sigue las instrucciones para volver a crear la VM del plano de control del clúster de administrador.

VM del complemento del clúster de administrador

Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear la VM:

  kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

Después de ejecutar este comando, espera a que las VM del complemento de clúster de administrador terminen de crear y estén listas antes de continuar con los pasos siguientes.

VM del plano de control del clúster de usuario

Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear las VM:

usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

Después de ejecutar este comando, espera a que las VM del plano de control del clúster de usuario terminen de crear y estén listas antes de continuar con los siguientes pasos.

VM de trabajador del clúster de usuario

Ejecuta el siguiente comando desde la estación de trabajo de administrador para volver a crear las VM.

for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done

VM de Seesaw

Ejecuta los siguientes comandos desde la estación de trabajo de administrador para volver a crear las VM de Seesaw. Habrá un tiempo de inactividad. Si la alta disponibilidad está habilitada en el balanceador de cargas, el tiempo de inactividad máximo es de dos segundos.

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff

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.

Error irrecuperable `gkectl create-config admin` y `gkectl create-config cluster`

En las versiones 1.8.0-1.8.3, el comando gkectl create-config admin/cluster entra en conflicto con el mensaje panic: invalid version: "latest".

Como solución alternativa, usa gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION. Reemplaza DESIRED_CLUSTER_VERSION por la versión deseada, como 1.8.2-gke.8.

Crea o actualiza el tiempo de espera del clúster de administrador

Este problema afecta a las versiones 1.8.0-1.8.3.

Es posible que se agote el tiempo de espera de la creación o actualización del clúster de administrador con el siguiente error:

Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory

Además, el registro en nodes/ADMIN_MASTER_NODE/files/var/log/startup.log de la instantánea del clúster externo termina con este mensaje:

[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

Este error ocurre cuando la red es lenta entre la VM del plano de control del administrador y el registro de contenedores. Asegúrate de inspeccionar la configuración de tu red o proxy para reducir la latencia y aumentar el ancho de banda.

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.8.2 o superior

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.8.2 o posteriores. 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.8.2 o versiones posteriores, es posible que la instalación falle debido a un conflicto con el existente que administra 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 un error de instalación, sigue estos pasos para actualizar correctamente a la versión 1.8.2 o posterior:

Evita conflictos durante la actualización

Desinstala tu versión de cert-manager. Si definiste tus propios recursos, es posible que quieras crear una copia de seguridad.
Realiza la actualización.
Sigue estas instrucciones para restablecer tu propio cert-manager.

Restablece tu propio cert-manager en los 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 tu propio cert-manager en los 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 cargas de trabajo del plano de control de VMware. En los casos excepcionales en los que también necesite instalar su propio cert-manager en clústeres de administrador, siga las instrucciones que se indican a continuación 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

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.

`/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`.

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.

Un token del portador de una cuenta de servicio que es demasiado largo puede romper los registros del balanceador de cargas de Seesaw.

Si el token del portador de la cuenta de servicio de supervisión de registros es superior a 512 KB, puede romper los registros del balanceador de cargas de Seesaw. Para solucionar este problema, actualiza a la versión 1.9 o a una posterior.

Problemas de conectividad entre Pods debido a daemons `anetd` en un interbloqueo de software

Los clústeres con enableDataplaneV2 configurado como true pueden experimentar problemas de conectividad entre Pods debido a daemons anetd (que se ejecutan como un Daemonset) que ingresan a un interbloqueo del software. En este estado, los daemons anetd verán que los nodos inactivos (que antes se borraron) son pares y no detectarán nodos recientemente agregados como pares nuevos.

Si experimentaste este problema, completa los siguientes pasos para reiniciar los daemons anetd a fin de actualizar los nodos de intercambio de tráfico, y se debe restablecer la conectividad.

Busca todos los daemons anetd en el clúster:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd

Verifica si los daemons anetd ven pares inactivos:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status

Reemplaza ANETD_XYZ por el nombre de un Pod anetd.

Reinicia todos los Pods afectados:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ

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/ llenando espacio en disco

Categoría

Versiones identificadas

Síntomas

Causa

Solución alternativa

Estación de trabajo de administrador

Nodos del clúster

La actualización o actualización del clúster de usuario falla debido a que “no se pudo registrar el clúster de usuario”

Categoría

Versiones identificadas

Síntomas

Causa

Solución alternativa

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

Categoría

Versiones identificadas

Síntomas

Causa

Solución alternativa

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.8.2 y 1.8.3

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

La secuencia de comandos /etc/cron.daily/aide usa todo el espacio en /run, lo que provoca un bloqueo en los Pods.

Actualiza el balanceador de cargas de Seesaw con la versión 1.8.0

No se puede acceder a la estación de trabajo de administrador debido a un problema de vencimiento de la contraseña

Prevención de error de vencimiento de contraseña

Mitigación del error de vencimiento de contraseña

Estación de trabajo de administrador

VM del plano de control del clúster de administrador

VM del complemento del clúster de administrador

VM del plano de control del clúster de usuario

VM de trabajador del clúster de usuario

VM de Seesaw

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Error irrecuperable gkectl create-config admin y gkectl create-config cluster

Crea o actualiza el tiempo de espera del clúster de administrador

Conexión SSH cerrada por host remoto

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

Evita conflictos durante la actualización

Restablece tu propio cert-manager en los clústeres de usuario

Restablece tu propio cert-manager en los clústeres de administrador

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

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

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

Un token del portador de una cuenta de servicio que es demasiado largo puede romper los registros del balanceador de cargas de Seesaw.

Problemas de conectividad entre Pods debido a daemons anetd en un interbloqueo de software

Falla de los certificados de verificación gkectl diagnose

Error irrecuperable `gkectl create-config admin` y `gkectl create-config cluster`

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

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

Problemas de conectividad entre Pods debido a daemons `anetd` en un interbloqueo de software