Problemas conocidos

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

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

Categoría

Actualizar

Versiones identificadas

1.7.0+, 1.8.0 o superior

Síntomas

Cuando actualizas los clústeres de usuario a las versiones 1.7, el comando gkectl upgrade cluster falla con mensajes de error similares a

$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:

failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00  --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...

Los errores indican que la actualización del clúster de usuario se completó en gran medida, excepto que no se actualizó el agente de Connect. Sin embargo, la funcionalidad de GKE Connect no debería verse afectada.

Causa

La versión 20210129-01-00 del agente de Connect que se usa en las versiones 1.7 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

SO

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.

## `kubectl describe CSINode` and `gkectl diagnose snapshot`

`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.

## OIDC and the CA certificate

The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.

Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).

To work around this issue, run the following script:

<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>

IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>

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

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

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

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

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

Replace the following:

* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:

* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
  kubeconfig file.

## 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}' ``

El reenvío de registros realiza una cantidad excesiva de solicitudes de OAuth 2.0

Nota: Este problema se solucionó en la versión 1.7.2 de los clústeres de Anthos alojados en VMware.

Con los clústeres de Anthos alojados en VMware, versión 1.7.1, es posible que tengas problemas para consumir memoria del servidor de reenvío si realizas solicitudes excesivas de OAuth 2.0. Esta es una solución alternativa, en la que puedes cambiar a una versión inferior de la versión de stackdriver-operator, limpiar el disco y reiniciar el servidor de reenvío.

Paso 0: Descarga las imágenes a tu registro privado, si corresponde

Si usas un registro privado, sigue estos pasos para descargar esas imágenes en tu registro privado antes de continuar. Omite este paso si no usas un registro privado.

Reemplaza PRIVATE_REGISTRY_HOST por el nombre de host o la dirección IP de tu registro privado de Docker.

stackdriver-operator

docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440

docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \
    PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

fluent-bit

docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3

docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \
    PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

Prometheus

docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0

docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \
    PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

Paso 1: Cambia a una versión inferior del operador de Stackdriver

• Ejecuta el siguiente comando para cambiar a una versión anterior del operador de Stackdriver.

kubectl  --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'

Paso 2: Limpia el búfer de discos para el reenvío de registros

• Implementa el DaemonSet en el clúster para limpiar el búfer.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

• Verifica que se haya limpiado el búfer del disco.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

El resultado muestra la cantidad de nodos del clúster.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

El resultado muestra la cantidad de nodos del clúster.

• Borra el DaemonSet de limpieza.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

Paso 3: Reinicia el reenvío de registros

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder

Los registros y las métricas no se envían al proyecto especificado por stackdriver.projectID.

En los clústeres de Anthos alojados en VMware 1.7, los registros se envían al proyecto superior de la cuenta de servicio especificada en el campo stackdriver.serviceAccountKeyPath del archivo de configuración del clúster. Se ignora el valor de stackdriver.projectID. Se solucionará este problema en una próxima versión.

Como solución alternativa, visualiza los registros en el proyecto superior de tu cuenta de servicio de supervisión y registro.

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.

Nota: Si ya iniciaste el proceso de actualización y encontraste un error de vencimiento de certificado, comunícate con el equipo de Atención al cliente de Google para obtener asistencia.

Nota: Esta guía es estrictamente para la renovación de certificados del clúster de administrador.

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

1. Antes de comenzar, asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador.

2. Obtén la dirección IP y las claves SSH del nodo principal de administrador:

   kubectl --kubeconfig [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_KUBECONFIG] get nodes -o \
   jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   --selector='node-role.kubernetes.io/master')
   

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

4. 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 [ADMIN_CLUSTER_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.

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

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

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

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

9. 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 [ADMIN_CLUSTER_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.

Anticipamos una corrección en una versión futura. Mientras tanto, puedes resolver este problema con cualquiera de las siguientes soluciones alternativas:

1. Quita los archivos de registro de forma periódica en /run/aide/cron.daily.old* (recomendado).
2. Sigue los pasos mencionados en el vínculo externo anterior. (Nota: Esta solución alternativa podría afectar el estado de cumplimiento del nodo).

Usa los clústeres de Anthos alojados en VMware con Anthos Service Mesh versión 1.7 o posterior

Si usas clústeres de Anthos alojados en VMware con la versión 1.7 o posterior de Anthos Service Mesh y deseas actualizar a la versión 1.6.0-1.6.3 o 1.7.0-1.7.2, debes quitar las etiquetas bundle.gke.io/component-name y bundle.gke.io/component-version de las siguientes definiciones de recursos personalizados (CRD):

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

1. Ejecuta este comando para actualizar la CRD destinationrules.networking.istio.io en tu clúster de usuario:

   kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG

2. Quita las etiquetas bundle.gke.io/component-version y bundle.gke.io/component-name de la CRD.

Otra opción es esperar la versión 1.6.4 y 1.7.3 y, luego, actualizar a 1.6.4 o 1.7.3 directamente.

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.

Nota: La prevención y la mitigación recomendadas aquí rompen la regla 5.4.1.1 de la comparativa de CIS, “Asegúrate de que el vencimiento de la contraseña sea de 365 días o menos”, en el nodo.

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.

1. Asegúrate de que la VM temporal y la estación de trabajo de administrador estén en estado de apagado.

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

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

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

5. Apaga la VM temporal.

6. Enciende la estación de trabajo de administrador Ahora, deberías tener acceso SSH como de costumbre.

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

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.

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.

• CVE-2019-16884
• CVE-2019-19921
• CVE-2020-15157
• CVE-2020-15257

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