Versión 1.9. 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.

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

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.

kubectl describe CSINode y gkectl diagnose snapshot

A veces, kubectl describe CSINode y gkectl diagnose snapshot fallan debido al problema de Kubernetes de OSS en la desreferencia de campos de puntero nulo.

OIDC y el certificado de CA

El proveedor de OIDC no usa la CA común de forma predeterminada. Debes proporcionar el certificado de CA de forma explícita.

La actualización del clúster de administrador de 1.5 a 1.6.0 interrumpe los clústeres de usuario 1.5 que usan un proveedor de OIDC y no tienen valor para authentication.oidc.capath en el archivo de configuración del clúster de usuario.

Para solucionar este problema, ejecuta la siguiente secuencia de comandos:

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

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

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

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

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

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

Reemplaza lo siguiente:

  • YOUR_OIDC_IDENTITY_PROVICER: Es la dirección de tu proveedor de OIDC:

  • YOUR_YOUR_USER_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo de configuración del clúster de usuario.

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

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

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  -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  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  -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  -n kube-system delete ds fluent-bit-cleanup

Paso 3: Reinicia el reenvío de registros

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

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

Es posible que veas un error de instalación debido a cert-manager-cainjector en bloqueo, cuando apiserver/etcd es lento:

# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system cert-manager-cainjector-xxx`

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 verticalmente la escala de monitoring-operator para que no revierta los cambios en la implementación de cert-manager.

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

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

# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit -n kube-system deployment cert-manager-cainjector

El fragmento yaml relevante para la implementación de cert-manager-cainjector debe verse de la siguiente manera: ... apiVersion: apps/v1 kind: Deployment metadata: name: cert-manager-cainjector namespace: kube-system ... spec: ... template: ... spec: ... containers: - name: cert-manager image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0" args: ... - --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 USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=1

Los cambios se revertirán después de cada actualización. Realiza los mismos pasos una vez más para mitigar el problema hasta que se solucione en una versión futura.

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.

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

  3. 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')
    
  4. 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.

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

  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 $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 una versión superior a 1.8.2

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:

  1. Desinstala tu versión de cert-manager.

  2. Realiza la actualización.

  3. Si deseas restablecer tu propia instalación de cert-manager, sigue estos pasos:

    • Escala la implementación de monitoring-operator a 0. Para el clúster de administrador, ejecuta este comando:

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

      Para un clúster de usuario, ejecuta este comando:

      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.

      Para el clúster de administrador, ejecuta este comando:

      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
      

      Para un clúster de usuario, ejecuta este comando:

      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
      
    • Vuelve a instalar tu cert-manager.

    • 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. Este espacio de nombres podría ser cert-manager si se usa la versión ascendente del administrador de certificados, como v1.0.3, pero eso depende de tu instalación.

Administra un cert-manager de terceros cuando actualices a la versión 1.9.2 o superior

Si experimentaste un error de instalación, sigue estos pasos para actualizar correctamente a la versión 1.9.2 o posterior:

  1. Desinstala tu versión de cert-manager.

  2. Realiza la actualización.

  3. Si deseas restablecer tu propia instalación de cert-manager, sigue estos pasos:

    • Escala la implementación de monitoring-operator a 0. Para el clúster de administrador, ejecuta este comando:

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

      Para un clúster de usuario, ejecuta este comando:

      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.

      Para el clúster de administrador, ejecuta este comando:

      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
      

      Para un clúster de usuario, ejecuta este comando:

      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
      
    • Vuelve a instalar tu cert-manager.

    • Copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso del clúster de tu administrador de certificados instalado. Este espacio de nombres podría ser cert-manager si se usa la versión ascendente del administrador de certificados, como v1.5.4, pero eso depende de tu instalación.

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