Versión 1.8. 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.8. Esta 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.

Las comprobaciones previas verifican que cgroup v2 no está en uso en la máquina de 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.

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.

Duplicación de registros y registros de auditoría de Cloud

Falta la imagen gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 en el paquete de duplicación de registros bmctl. Para habilitar la función de registros de auditoría de Cloud cuando usas una duplicación de registros, deberás descargar manualmente la imagen faltante y enviarla a tu servidor de registro con los siguientes comandos:

docker pull gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker tag gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker push REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00

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

Realiza la instalación en vSphere

Cuando instalas clústeres de Anthos en equipos físicos en las VM de vSphere, debes desactivar las marcas tx-udp_tnl-segmentation y tx-udp_tnl-csum-segmentation. Estas marcas están relacionadas con la descarga de segmentación de hardware que realiza el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de clústeres de Anthos en equipos físicos.

Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de estas marcas. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.

En ocasiones, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas, pero no lo están. Para desactivar estas marcas de manera explícita, activa y desactiva las marcas con los siguientes comandos.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Este cambio de marca no persiste en los reinicios. Configura las secuencias de comandos de inicio para que establezcan de forma explícita estas marcas cuando se inicie el sistema.

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

Las actualizaciones a los clústeres de administrador, híbridos e independientes 1.8.0 y 1.8.1 no se completan.

La actualización de los clústeres de administrador, híbridos o independientes de la versión 1.7.x a la versión 1.8.0 o 1.8.1 no se completa algunas veces. Esta falla de la actualización corresponde a los clústeres que actualizaste después de la creación del clúster.

Un indicador de este problema de actualización es el resultado Waiting for upgrade to complete ... de la consola, sin mención del nodo se está actualizando. Este síntoma también indica que el clúster de administrador se actualizó de forma correcta a la versión de Kubernetes v1.20.8-gke.1500, la versión de Kubernetes para las versiones 1.8.0 y 1.8.1 de los clústeres de Anthos en equipos físicos.

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

Para confirmar si este problema afecta la actualización de tu clúster a 1.8.0 o 1.8.1, haz lo siguiente:

  1. Crea la siguiente secuencia de comandos de shell:

    if [ $(kubectl get cluster <var>CLUSTER\_NAME -n <var>CLUSTER\_NAMESPACE
        --kubeconfig bmctl-workspace/.kindkubeconfig -o=jsonpath='{.metadata.generation}')
        -le $(kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
        --kubeconfig bmctl-workspace/.kindkubeconfig
        -o=jsonpath='{{.status.systemServiceConditions[?(@.type=="Reconciling")].observedGeneration}}') ];
        then echo "Bug Detected"; else echo "OK"; fi
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre del clúster que se está verificando.
    • CLUSTER_NAMESPACE: Es el espacio de nombres para el clúster.
  2. Ejecuta la secuencia de comandos mientras la actualización está en curso, pero después de que se completen las verificaciones previas.

    Cuando el valor observedGeneration no es menor que el valor generation, Bug Detected se escribe en el resultado de la consola. Este resultado indica que la actualización del clúster se ve afectada.

  3. Para desbloquear la actualización, ejecuta el siguiente comando:

    kubectl get --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
        --kubeconfig bmctl-workspace/.kindkubeconfig | \
        sed -e 's/\("systemServiceConditions":\[{[^{]*"type":"DashboardReady"}\),{[^{}]*}/\1/g' | \
        kubectl replace --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
        --kubeconfig bmctl-workspace/.kindkubeconfig -f-
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre del clúster que se está verificando.
    • CLUSTER_NAMESPACE: Es el espacio de nombres para el clúster.

Actualizaciones a 1.8.3 o 1.8.4

La actualización de los clústeres de Anthos en Bare Metal a la versión 1.8.3 o 1.8.4 a veces falla con un error de contexto nulo. Si la actualización de tu clúster falla con un error de contexto nulo, realiza los siguientes pasos para completar la actualización:

  1. Configura la variable GOOGLE_APPLICATION_CREDENTIALS del entorno para que apunte al archivo de claves de tu cuenta de servicio.

    export GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH
    

    Reemplaza KEY_PATH por la ruta de acceso del archivo JSON que contiene la clave de tu cuenta de servicio.

  2. Vuelve a ejecutar el comando bmctl upgrade cluster.

Incompatibilidad de Ubuntu 18.04 y 18.04.1

Para actualizar a 1.8.x, las máquinas de nodo de clúster y la estación de trabajo que ejecuta bmctl deben tener la versión 4.17.0 o una posterior del kernel de Linux. De lo contrario, el controlador de herramientas de redes anetd no funcionará. El síntoma es que los Pods con el prefijo anet en el espacio de nombres kube-system continuarán fallando con el siguiente mensaje de error: BPF NodePort services needs kernel 4.17.0 or newer.

Este problema afecta a Ubuntu 18.04 y 18.04.1, ya que se encuentran en la versión 4.15 de kernel.

Actualiza los clústeres 1.7.x que usan containerd

Las actualizaciones de los clústeres a 1.8.x están bloqueadas para los clústeres 1.7.x que están configurados a fin de usar la capacidad de vista previa de containerd. La vista previa de containerd usa el controlador de grupo de control (cgroup) cgroupfs incorrecto, en lugar del controlador recomendado systemd. Hay casos informados de inestabilidad de los clústeres cuando aquellos que usan el controlador cgroupfs se encuentran bajo presión de recursos. La capacidad de containerd de GA en la versión 1.8.0 usa el controlador systemd correcto.

Si tienes clústeres 1.7.x existentes que usan la función del entorno de ejecución del contenedor de containerd de vista previa, te recomendamos que crees nuevos clústeres 1.8.0 configurados para containerd y que migres las apps y cargas de trabajo existentes. Esto garantiza la mayor estabilidad de los clústeres cuando se usa el entorno de ejecución del contenedor de containerd.

Fallas de actualización de SELinux

La actualización de los clústeres 1.7.1 configurados con el entorno de ejecución del contenedor de containerd y la ejecución de SELinux en RHEL o CentOS fallarán. Te recomendamos crear clústeres nuevos de 1.8.0 configurados para usar containerd y migrar tus cargas de trabajo.

El desvío de nodos no puede iniciarse cuando el nodo está fuera de alcance

El proceso de desvío para nodos no comenzará si el nodo está fuera del alcance de los clústeres de Anthos en equipos físicos. Por ejemplo, si un nodo se desconecta durante un proceso de actualización de clústeres, es posible que la actualización deje de responder. Este caso es poco frecuente. Para minimizar la probabilidad de encontrar este problema, asegúrate de que tus nodos funcionen de forma correcta antes de iniciar una actualización.

Restablecimiento/eliminación

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.

Rotación de CA del clúster (función de vista previa)

Después de realizar una rotación de autoridad certificada (CA) de clúster de usuario en un clúster, todos los flujos de autenticación del usuario fallan. Estas fallas ocurren porque el recurso personalizado ClientConfig que se usa en los flujos de autenticación no se actualiza con los nuevos datos de CA durante la rotación de la CA. Si realizaste una rotación de CA en tu clúster, comprueba si el campo certificateAuthorityData en el ClientConfig de default del espacio de nombres kube-public contiene la CA del clúster más antigua.

Para resolver el problema de forma manual, actualiza el campo certificateAuthorityData con la CA actual del clúster.

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.

Direcciones egressSourceIP duplicadas

Cuando uses la vista previa de funciones de puerta de enlace NAT de salida, es posible establecer reglas de selección de tráfico que especifiquen una dirección de egressSourceIP que ya está en uso para otro objeto EgressNATPolicy. Esto puede causar conflictos de enrutamiento de tráfico de salida. Coordina con tu equipo de desarrollo a fin de determinar qué direcciones IP flotantes están disponibles para usarse antes de especificar la dirección de egressSourceIP en tu recurso personalizado EgressNATPolicy.

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

Entorno de ejecución de VM de Anthos

  • Reiniciar un Pod hace que las VM del Pod cambien de dirección IP o pierdan su dirección IP por completo. Si la dirección IP de una VM cambia, esto no afecta la accesibilidad de las aplicaciones de VM expuestas como un servicio de Kubernetes. Si se pierde la dirección IP, debes ejecutar dhclient desde la VM para adquirir una dirección IP.

SELinux

Errores de SELinux durante la creación de Pods

La creación de Pods a veces falla cuando SELinux impide que el entorno de ejecución del contenedor configure etiquetas en activaciones de tmpfs. Esta falla es poco frecuente, pero puede ocurrir cuando SELinux está en modo Enforcing y en algunos kernels.

Para verificar que SELinux sea la causa de las fallas de creación de Pods, usa el siguiente comando a fin de verificar si hay errores en los registros kubelet:

journalctl -u kubelet

Si SELinux provoca la falla de la creación del Pod, la respuesta del comando contiene un error similar al siguiente:

error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied

Para verificar que este problema esté relacionado con la aplicación de SELinux, ejecuta el siguiente comando:

ausearch -m avc

Este comando busca errores de permisos de la caché de vector de acceso (AVC) en los registros de auditoría. avc: denied en la siguiente respuesta de muestra confirma que las fallas de creación de Pods están relacionadas con la aplicación de SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

La causa raíz de este problema de creación de Pods con SELinux es un error de kernel que se encuentra en las siguientes imágenes de Linux:

  • Versiones de Red Hat Enterprise Linux (RHEL) anteriores a 8.3
  • Versiones de CentOS anteriores a la 8.3

Reiniciar la máquina ayuda a solucionar el problema.

Para evitar que se produzcan errores de creación de Pods, usa RHEL 8.3 o una versión posterior, o CentOS 8.3 o versiones posteriores, ya que esas versiones corrigieron el error del kernel.

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.