Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, y ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos en equipos físicos. Para obtener más detalles, consulta las notas de la versión 1.7. Esta no es la versión más reciente. Para obtener una lista completa de cada versión secundaria y de parche en orden cronológico, consulta las notas de la versión combinadas.

Versiones disponibles: 1.8  |   1.7  |   1.6

Problemas conocidos de clústeres de Anthos en equipos físicos

Instalación

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible con los clústeres de Anthos en equipos físicos 1.6. Kubernetes 1.18 no es compatible con cgroup v2. Además, Docker solo ofrece asistencia experimental a partir de 20.10. systemd pasó a cgroup v2 de forma predeterminada en la versión 247.2-2. La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.

A partir de los clústeres de Anthos en un equipo físico 1.6.2, las verificaciones previas verifican que cgroup v2 no esté en uso en la máquina del clúster.

Mensajes de error benignos durante la instalación

Durante la instalación del clúster con alta disponibilidad (HA), es posible que veas errores sobre etcdserver leader change. Estos mensajes de error son benignos y se pueden ignorar.

Cuando usas bmctl para la instalación del clúster, es posible que veas un mensaje de registro Log streamer failed to get BareMetalMachine al final del create-cluster.log. Este mensaje de error es benigno y se puede ignorar.

Cuando examinas los registros de creación de clústeres, puedes notar fallas transitorias sobre el registro de clústeres o la llamada a webhooks. Estos errores se pueden ignorar sin problemas, ya que la instalación reintentará estas operaciones hasta que tengan éxito.

Verificaciones de comprobación previa y credenciales de cuentas de servicio

Para las instalaciones activadas por clústeres híbridos o de administrador (en otras palabras, clústeres no creados con bmctl, como clústeres de usuarios), la verificación de comprobación previa no verifica las credenciales de la cuenta de servicio de Google Cloud Platform o sus permisos asociados.

Comprobaciones previas y permisos denegados

Durante la instalación, es posible que veas errores sobre /bin/sh: /tmp/disks_check.sh: Permission denied. Estos mensajes de error se generan porque /tmp está activado con la opción noexec. Para que bmctl funcione, debes quitar la opción noexec del punto de activación /tmp.

Crea un lugar de trabajo de supervisión en la nube antes de visualizar los paneles

Debes crear un lugar de trabajo de Cloud Monitoring a través de Google Cloud Console antes de poder ver los clústeres de Anthos en paneles de supervisión de equipos físicos.

Credenciales predeterminadas de la aplicación y bmctl

bmctl usa credenciales predeterminadas de la aplicación (ADC) para validar el valor de ubicación de la operación del clúster en cluster spec cuando no está configurado en global.

Para que ADC funcione, debes apuntar la variable de entorno GOOGLE_APPLICATION_CREDENTIALS a un archivo de credenciales de la cuenta de servicio o ejecutar gcloud auth application-default login.

LTS de Ubuntu 20.04 y bmctl

En las versiones anteriores a la versión 1.8.2 de los clústeres de Anthos en equipos físicos, algunas distribuciones de LTS de Ubuntu 20.04 con un kernel de Linux más reciente (incluidas las imágenes de LTS de Ubuntu 20.04 de GCP en el kernel 5.8) realizaron /proc/sys/net/netfilter/nf_conntrack_max de solo lectura en espacios de nombres de red que no sean init. Esto evita que bmctl establezca el tamaño máximo de la tabla de seguimiento de conexiones, lo que evita que el clúster de arranque se inicie. Un síntoma del tamaño incorrecto de la tabla es que el Pod kube-proxy del clúster de arranque se bloqueará, como se muestra en el siguiente registro de error de muestra:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

La solución alternativa es configurar net/netfilter/nf_conntrack_max de forma manual en el valor necesario en el host: sudo sysctl net.netfilter.nf_conntrack_max=393216. Ten en cuenta que el valor necesario depende de la cantidad de núcleos del nodo. Usa el comando kubectl logs que se muestra arriba para confirmar el valor deseado de los registros kube-proxy.

Este problema se solucionó en la versión 1.8.2 y posteriores de los clústeres de Anthos en equipos físicos.

Ubuntu 20.04.3+ LTS y HWE

Ubuntu 20.04.3 habilitó el kernel 5.11 en su paquete de habilitación de hardware (HWE). Los clústeres de Anthos en la versión 1.7.x de equipos físicos no son compatibles con este kernel. Si deseas usar el kernel 5.11, descarga y actualiza los clústeres de Anthos en la versión 1.8.0 o posterior de Bare Metal.

Servicio de Docker

En las máquinas de nodo del clúster, si el ejecutable de Docker está presente en la variable de entorno PATH, pero el servicio de Docker no está activo, la verificación de comprobación previa fallará y, además, informará que Docker service is not active. Para solucionar este error, quita Docker o habilita el servicio de Docker.

Containerd requiere /usr/local/bin en la RUTA

Los clústeres con el entorno de ejecución de containerd requieren que /usr/local/bin esté en la RUTA del usuario SSH para que el comando kubeadm init encuentre el objeto binario crictl. Si no se puede encontrar crictl, la creación del clúster fallará.

Cuando no accedes como el usuario raíz, sudo se usa para ejecutar el comando kubeadm init. La RUTA sudo puede diferir del perfil raíz y puede no contener /usr/local/bin.

Para corregir este error, actualiza secure_path en /etc/sudoers a fin de incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.

A partir de la versión 1.8.2, los clústeres de Anthos en equipos físicos agregan /usr/local/bin a la RUTA cuando se ejecutan comandos. Sin embargo, la ejecución de la instantánea como usuario no raíz seguirá conteniendo crictl: command not found (que se puede solucionar mediante la solución alternativa anterior).

Oscilación de preparación de nodo

En ocasiones, los clústeres pueden presentar una preparación de nodos inestable (el estado de los nodos cambia con rapidez entre el comportamiento de Ready y NotReady). Un generador de eventos de ciclo de vida de pod (PLEG) en mal estado causa este comportamiento. PLEG es un módulo de kubelet.

Para confirmar que un PLEG en mal estado causa este comportamiento, usa el siguiente comando de journalctl a fin de verificar las entradas de registro de PLEG:

journalctl -f | grep -i pleg

Las entradas de registro como las siguientes indican que el PLEG está en mal estado:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Una condición de carrera runc conocida es la causa probable del PLEG en mal estado. Los procesos runc atascados son un síntoma de la condición de carrera. Usa el siguiente comando para verificar el estado del proceso runc init:

ps aux | grep 'runc init'

Para solucionar este problema, haz lo siguiente:

  1. Ejecuta los siguientes comandos en cada nodo para instalar el último containerd.io y extraer la última herramienta de línea de comandos de runc:

    Ubuntu

    sudo apt update
    sudo apt install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    

    CentOS/RHEL

    sudo dnf install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    
  2. Reinicia el nodo si hay procesos runc init atascados.

    Como alternativa, puedes limpiar de manera manual cualquier proceso atascado.

Actualizar clústeres de Anthos alojados en equipos físicos

Actualiza desde 1.6.0

La actualización no está disponible en la versión 1.6.0.

Actualiza de 1.7.0 a 1.7.x

Cuando se actualiza de 1.7.0 a 1.7.x, es posible que el clúster se detenga en la actualización del nodo del plano de control. Es posible que veas que los trabajos de MACHINE-IP-machine-upgrade se ejecutan y fallan de forma periódica. Este problema afecta a los clústeres 1.7.0 que tienen lo siguiente:

  • Docker preinstalado en los nodos del plano de control.
  • containerd seleccionado como el entorno de ejecución.

Este problema se debe a que los clústeres de Anthos en equipos físicos configuran de forma incorrecta el cri-socket en Docker en lugar de containerd. A fin de resolver este problema, debes configurar las credenciales de extracción de imágenes para Docker:

  1. Accede a Docker:

    docker login gcr.io
    

    Esto crea un archivo $HOME/.docker/config.json.

  2. Enumera las direcciones IP de todos los nodos del plano de control, separados por un espacio:

    IPs=(NODE_IP1 NODE_IP2 ...)
    
  3. Copia la configuración de Docker en los nodos:

    for ip in "${IPs[@]}"; do
      scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
    

    Reemplaza USER_NAME por el nombre de usuario configurado en el archivo de configuración del clúster de administrador.

  4. Configura las credenciales de extracción de imágenes para Docker:

    ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
    

El controlador del grupo de control está mal configurado en cgroupfs

Si tienes problemas relacionados con el controlador del grupo de control (cgroup), esto puede deberse a que los clústeres de Anthos en el equipo físico lo configuraron de forma incorrecta como cgroupfs en lugar de systemd.

Para solucionar este problema, haz lo siguiente:

  1. Accede a tus máquinas y abre /etc/containerd/config.toml.

  2. En [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options], agrega SystemdCgroup = true:

    ...
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
         [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
           runtime_type = "io.containerd.runc.v2"
           runtime_engine = ""
           runtime_root = ""
           privileged_without_host_devices = false
           base_runtime_spec = ""
           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
             SystemdCgroup = true
     [plugins."io.containerd.grpc.v1.cri".cni]
       bin_dir = "/opt/cni/bin"
       conf_dir = "/etc/cni/net.d"
       max_conf_num = 1
       conf_template = ""
    ...
    
  3. Guarda los cambios y cierra el archivo.

  4. Abre /etc/systemd/system/kubelet.service.d/10-kubeadm.conf.

  5. Al final del archivo, agrega --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service:

    [Service]
    Environment="HOME=/root"
    Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
    Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
    # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
    EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
    # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
    # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
    EnvironmentFile=-/etc/default/kubelet
    ExecStart=
    ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service
    
  6. Guarda los cambios y reinicia el servidor.

  7. Para verificar que systemd sea el controlador del grupo de control, ejecuta el siguiente comando:

    systemd-cgls
    

    Verifica que haya una sección kubepods.slice y que todos los Pods estén en ella.

Restablecimiento/eliminación

Compatibilidad con clústeres de usuarios

No puedes restablecer clústeres de usuarios con el comando bmctl reset.

Puntos de activación y fstab

El restablecimiento no desactiva los puntos de activación en /mnt/localpv-share/ y no limpia las entradas correspondientes en /etc/fstab.

Eliminación del espacio de nombres

Borrar un espacio de nombres evitará que se creen recursos nuevos en ese espacio de nombres, incluidos los trabajos para restablecer máquinas. Cuando borras un clúster de usuario, primero debes borrar el objeto del clúster antes de borrar su espacio de nombres. De lo contrario, los trabajos para restablecer máquinas no se pueden crear y el proceso de eliminación omitirá el paso de limpieza de la máquina.

servicio de containerd

El comando bmctl reset no borra ningún archivo de configuración containerd u objeto binario. El servicio containerd systemd está en funcionamiento. El comando borra los contenedores que ejecutan pods programados en el nodo.

Seguridad

El certificado/CA del clúster se rotará durante la actualización. Por el momento, la compatibilidad con la rotación a pedido no está disponible.

Anthos en un equipo físico rota automáticamente los certificados de entrega kubelet. Cada agente de nodo kubelet puede enviar una solicitud de firma de certificado (CSR) cuando un certificado está cerca del vencimiento. Un controlador en tus clústeres de administrador valida y aprueba la CSR.

Logging y Monitoring

Los registros de nodos no se exportan a Cloud Logging

Los registros de nodos de los nodos con un punto (“.”) en su nombre no se exportan a Cloud Logging. Como solución alternativa, usa las siguientes instrucciones para agregar un filtro al recurso stackdriver-log-forwarder-config a fin de permitir que el operador de Stackdriver reconozca y exporte estos registros.

  1. Disminuye el tamaño del operador de Stackdriver, stackdriver-operator:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system scale \
        deploy stackdriver-operator --replicas=0
    
  2. Edita el configmap de reenvío de registros, stackdriver-log-forwarder-config:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
        stackdriver-log-forwarder-config
    
  3. Agrega el siguiente filtro al final de la sección input-systemd.conf del configmap:

       [FILTER]
           Name    lua
           Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
           script  replace_dot.lua
           call    replace
    
     replace_dot.lua: |
       function replace(tag, timestamp, record)
           new_record = record
    
           local local_resource_id_key = "logging.googleapis.com/local_resource_id"
    
           -- Locate the local_resource_id
           local local_resource_id = record[local_resource_id_key]
    
           local first = 1
           local new_local_resource_id = ""
           for s in string.gmatch(local_resource_id, "[^.]+") do
               new_local_resource_id = new_local_resource_id .. s
               if first == 1 then
                   new_local_resource_id = new_local_resource_id .. "."
                   first = 0
               else
                   new_local_resource_id = new_local_resource_id .. "_"
               end
           end
    
           -- Remove the trailing underscore
           new_local_resource_id = new_local_resource_id:sub(1, -2)
           new_record[local_resource_id_key] = new_local_resource_id
           return 1, timestamp, new_record
       end
    
  4. Borra todos los Pods del servidor de reenvío de registros:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
        stackdriver-log-forwarder -p \
        '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    

    Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso.

  5. Implementa un daemonset para limpiar todos los datos procesados sin procesar en búferes en bits de bits:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system apply -f - << EOF
        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
    EOF
    
  6. Verifica que el daemonset limpió todos los nodos con los siguientes comandos.

    kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
        -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
    
    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
        -l app=fluent-bit-cleanup --no-headers | wc -l
    

    El resultado de los dos comandos debe ser igual al número de nodo en el clúster

  7. Borra el DaemonSet de limpieza.

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system delete ds fluent-bit-cleanup
    
  8. Reinicia Pods:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
        daemonset stackdriver-log-forwarder --type json \
        -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    

Redes

Si modificas firewalld, se borrarán las cadenas de políticas de iptables de Cilium

Cuando ejecutas clústeres de Anthos en equipos físicos con firewalld habilitado en CentOS o Red Had Enterprise Linux (RHEL), los cambios en firewalld pueden quitar las cadenas de iptables de Cilium en la red de host. El pod anetd agrega las cadenas de iptables cuando se inicia. La pérdida de las cadenas de iptables de Cilium hace que el pod en el nodo pierda conectividad de red fuera del nodo.

Entre los cambios en firewalld que quitarán las cadenas de iptables, se incluyen los siguientes:

  • Reinicio de firewalld con systemctl
  • Recarga de firewalld con el cliente de línea de comandos (firewall-cmd --reload)

Para solucionar este problema de conectividad, reinicia anetd en el nodo. Ubica y borra el Pod anetd con los siguientes comandos para reiniciar anetd:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Reemplaza ANETD_XYZ con el nombre del pod anetd.

Fallas de conectividad del Pod y filtrado de la ruta de acceso inversa

Los clústeres de Anthos en equipos físicos configuran el filtrado de la ruta de acceso inversa en los nodos para inhabilitar la validación de origen (net.ipv4.conf.all.rp_filter=0). Si la configuración rp_filter se cambia a 1 o 2, los pods fallarán debido a los tiempos de espera de comunicación fuera del nodo.

El filtrado de ruta de acceso inversa se establece con los archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). También es posible que sysctl anule este valor, que almacena la configuración del filtrado de la ruta de acceso inversa en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.

Para restablecer la conectividad del Pod, vuelve a establecer net.ipv4.conf.all.rp_filter en 0 de forma manual o reinicia el Pod anetd para volver a configurar net.ipv4.conf.all.rp_filter en 0. A fin de reiniciar el Pod anetd, usa los siguientes comandos para ubicar y borrar el pod anetd, y se iniciará un nuevo Pod anetd en su lugar:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Reemplaza ANETD_XYZ con el nombre del pod anetd.

Direcciones IP del clúster de arranque (kind) y superposiciòn de direcciones IP de nodo del clúster

192.168.122.0/24 y 10.96.0.0/27 son los CIDR predeterminados del pod y del servicio que usa el clúster de arranque (kind). Las verificaciones de comprobación previa fallarán si se superponen con las direcciones IP de la máquina del nodo del clúster. A fin de evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl para especificar valores diferentes.

Cómo superponer direcciones IP en diferentes clústeres

No hay verificación previa para validar direcciones IP superpuestas en diferentes clústeres.

Función hostport en clústeres de Anthos en equipos físicos

Actualmente, no se admite la función hostport de ContainerPort.

Limitaciones del extremo del sistema operativo

En RHEL y CentOS, existe una limitación de nivel de clúster de 100,000 extremos. Este número es la suma de todos los pods a los que hace referencia un servicio de Kubernetes. Si 2 servicios hacen referencia al mismo conjunto de pods, esto cuenta como 2 conjuntos de extremos separados. La implementación subyacente de nftable en RHEL y CentOS genera esta limitación. no es una limitación intrínseca de Anthos en el equipo físico.

Configuración

Especificaciones del plano de control y el balanceador de cargas

Las especificaciones del plano de control y el grupo de nodos del balanceador de cargas son especiales. Estas especificaciones declaran y controlan los recursos críticos del clúster. La fuente canónica de estos recursos es sus respectivas secciones en el archivo de configuración del clúster:

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

En consecuencia, no modifiques el plano de control de nivel superior ni los recursos del grupo de nodos del balanceador de cargas directamente. En su lugar, modifica las secciones asociadas en el archivo de configuración del clúster.

Campos mutables en la especificación del clúster y el grupo de nodos

Actualmente, solo los siguientes campos de especificación grupo de nodos y clúster del archivo de configuración del clúster se pueden actualizar después de la creación del clúster (son campos mutables):

  • Para el objeto Cluster (kind: Cluster), los siguientes campos son mutables:

    • spec.anthosBareMetalVersion
    • spec.bypassPreflightCheck
    • spec.controlPlane.nodePoolSpec.nodes
    • spec.loadBalancer.nodePoolSpec.nodes
    • spec.maintenanceBlocks
    • spec.nodeAccess.loginUser
  • Para el objeto NodePool (kind: NodePool), los siguientes campos son mutables:

    • spec.nodes

Instantáneas

Captura una instantánea como usuario no raíz de acceso

En el caso de la versión 1.8.1 y anteriores de los clústeres de Anthos en equipos físicos, si no accediste a tu cuenta como raíz, no puedes tomar una instantánea de clúster con el comando bmctl. A partir de la versión 1.8.2, los clústeres de Anthos en equipos físicos respetarán nodeAccess.loginUser en las especificaciones del clúster. Si no se puede acceder al clúster de administrador, puedes especificar el usuario de acceso con la marca --login-user.

Ten en cuenta que, si usas containerd como entorno de ejecución del contenedor, la instantánea no podrá ejecutar comandos crictl. Consulta Containerd requiere /usr/local/bin en PATH para obtener una solución alternativa. La configuración de PATH que se usó para SUDO causa este problema.

GKE Connect

Falla de repetición de Pod gke-connect-agent

El uso intensivo de la puerta de enlace de GKE Connect a veces puede causar problemas de falta de memoria en el Pod gke-connect-agent. Los síntomas de estos problemas de memoria insuficiente son los siguientes:

  • El Pod gke-connect-agent muestra una gran cantidad de reinicios o termina en un estado de fallas de repetición.
  • La puerta de enlace de conexión deja de funcionar.

Para solucionar este problema de memoria insuficiente, edita la implementación con el prefijo gke-connect-agent en el espacio de nombres gke-connect y aumenta el límite de memoria a 256 MiB o más.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

Este problema se solucionó en la versión 1.8.2 y posteriores de los clústeres de Anthos en equipos físicos.