Versión 1.8. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.9, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.9.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

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

Instalación

La creación del clúster falla cuando se usan varias NIC, `containerd` y un proxy

La creación de clústeres falla cuando tienes la siguiente combinación de condiciones:

El clúster está configurado para usar containerd como el entorno de ejecución del contenedor (nodeConfig.containerRuntime configurado como containerd en el archivo de configuración del clúster, la opción predeterminada para la versión 1.8 de los clústeres de Anthos en equipos físicos).
El clúster está configurado a fin de proporcionar interfaces de red múltiples, varias NIC, para los Pods (spec.clusterNetwork.multipleNetworkInterfaces configurado como true en el archivo de configuración del clúster).
El clúster se configura para usar un proxy (spec.proxy.url se especifica en el archivo de configuración del clúster). Aunque la creación de clústeres falla, esta configuración se propaga cuando intentas crear un clúster. Es posible que veas esta configuración de proxy como una variable de entorno HTTPS_PROXY o en la configuración de containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Como solución alternativa a este problema, agrega los CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodos.

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

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 producen debido a la activación de /tmp con la opción noexec. Para que bmctl funcione, debes quitar la opción noexec del punto de activación /tmp.

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

En las versiones de clústeres de Anthos en equipos físicos anteriores a la 1.8.2, falta la imagen de gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 en el paquete de duplicación de registro 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 del Pod (PLEG) en mal estado causa este comportamiento. PLEG es un módulo de kubelet.

Para confirmar que un PLEG en mal estado está causando este comportamiento, usa el siguiente comando de journalctl a fin de verificar las entradas de registro del 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:

Determina el entorno de ejecución del clúster

Antes de actualizar la versión de runc, debes determinar qué entorno de ejecución de contenedor usa tu clúster. El campo containerRuntime en el archivo de configuración del clúster identifica qué entorno de ejecución del contenedor usa tu clúster. Cuando containerRuntime se establece como containerd, el clúster usa el entorno de ejecución de containerd. Si el campo está configurado como docker o no está configurado, tu clúster usa el entorno de ejecución de Docker.

Para obtener el valor, abre el archivo de configuración del clúster con tu editor favorito o, si tienes acceso al kubeconfig del clúster de administrador, ejecuta el siguiente comando:
```
kubctl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE | grep -i runtime
```
Reemplaza lo siguiente:
- CLUSTER_NAME: el nombre del clúster del que se creará una copia de seguridad.
- CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-.

Para instalar containerd.io o docker-ce, y extraer la última herramienta de línea de comandos de runc, ejecuta los comandos que corresponden a tu sistema operativo y entorno de ejecución del contenedor en cada nodo.

Containerd de 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

Docker de Ubuntu

sudo apt update
sudo apt install docker-ce
# 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

Containerd de 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

Docker de CentOS/RHEL

sudo dnf install docker-ce
# 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

Reinicia el nodo si hay procesos runc init atascados.

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

Revisiones y actualizaciones

`bmctl update cluster` falla si falta el directorio `.manifests`

Si el directorio .manifests se quita antes de ejecutar bmctl update cluster, el comando falla con un error similar al siguiente:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

Para solucionar este problema, ejecuta bmctl check cluster primero, lo que volverá a crear el directorio .manifests.

Este problema se aplica a los clústeres de Anthos alojados en Bare Metal 1.10 y versiones anteriores, y se soluciona en la versión 1.11 y posteriores.

La actualización se detuvo en `error during manifests operations`

En algunas situaciones, las actualizaciones del clúster no se completan y la CLI de bmctl deja de responder. Este problema puede deberse a un recurso actualizado de forma incorrecta. Para determinar si este problema te afecta y para corregirlo, sigue estos pasos:

Verifica los registros anthos-cluster-operator y busca errores similares a las siguientes entradas:
```
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
```
Estas entradas son un síntoma de un recurso actualizado de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso del problema.
Si encuentras estos errores en tus registros, usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso que el mensaje de registro contiene.
Guarda los cambios y aplícalos al recurso.
Vuelve a intentar la actualización del clúster.

Las actualizaciones fallan para los clústeres de la versión 1.8 en modo de mantenimiento

El intento de actualizar un clúster de la versión 1.8.x a la versión 1.9.x falla si alguna máquina de nodo se encuentra en modo de mantenimiento. Esto se debe a una anotación que permanece en estos nodos.

Para determinar si este problema te afectará, sigue estos pasos:

Obtén la versión del clúster que deseas actualizar mediante la ejecución del siguiente comando:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"
```
Si el valor de la versión que se muestra es para la versión secundaria de 1.8, como 1.8.3, continúa. De lo contrario, este problema no se aplica a tu caso.
Ejecuta el siguiente comando para verificar si el clúster tiene nodos que hayan estado en modo de mantenimiento:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"
```
Si las anotaciones que se muestran contienen baremetal.cluster.gke.io/maintenance-mode-duration, te verás afectado por este problema conocido.

A fin de desbloquear la actualización del clúster, ejecuta el siguiente comando para cada máquina de nodo afectada a fin de quitar la anotación baremetal.cluster.gke.io/maintenance-mode-duration:

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

`bmctl update` no quita los bloques de mantenimiento

El comando bmctl update no puede quitar ni modificar la sección maintenanceBlocks de la configuración de recursos del clúster. Si deseas obtener más información, incluidas las instrucciones para quitar los nodos del modo de mantenimiento, consulta Pon nodos en modo de mantenimiento.

Las actualizaciones del clúster de la versión 1.7.x fallan para ciertas opciones de configuración del balanceador de cargas

La actualización de los clústeres de la versión 1.7.x a la 1.8.y puede fallar en las siguientes opciones de configuración del balanceador de cargas:

Balanceador de cargas externo configurado de forma manual (loadBalancer.mode configurado como manual)
Balanceo de cargas en paquetes (loadBalancer.mode configurado como bundled), mediante un grupo de nodos independiente (se especifican loadBalancer.nodePoolSpec.nodes)

Un síntoma de esta falla es que el trabajo cal-update en un nodo del plano de control falla en la tarea Check apiserver health con mensajes de error de conexión rechazada.

Este es un registro de muestra para el trabajo cal-update:

TASK [cal-update : Check apiserver health] *************************************
Thursday 20 January 2022  13:50:46 +0000 (0:00:00.033)       0:00:09.316 ******
FAILED - RETRYING: Check apiserver health (30 retries left).
FAILED - RETRYING: Check apiserver health (29 retries left).
FAILED - RETRYING: Check apiserver health (28 retries left).
FAILED - RETRYING: Check apiserver health (27 retries left).
FAILED - RETRYING: Check apiserver health (26 retries left).
...
FAILED - RETRYING: Check apiserver health (3 retries left).
FAILED - RETRYING: Check apiserver health (2 retries left).
FAILED - RETRYING: Check apiserver health (1 retries left).
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.
If you need to use command because get_url or uri is insufficient you can add
'warn: false' to this command task or set 'command_warnings=False' in
ansible.cfg to get rid of this message.
fatal: [10.50.116.79]: FAILED! => {"attempts": 30, "changed": true, "cmd": "curl
-k https://127.0.0.1/healthz", "delta": "0:00:00.008949", "end": "2022-01-20
19:22:30.381875", "msg": "non-zero return code", "rc": 7, "start": "2022-01-20
19:22:30.372926", "stderr": "  % Total    % Received % Xferd  Average Speed
Time    Time     Time  Current\n                                 Dload  Upload
Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --
:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to 127.0.0.1 port 443:
Connection refused", "stderr_lines": ["  % Total    % Received % Xferd  Average
Speed   Time    Time     Time  Current", "                                 Dload
Upload   Total   Spent    Left  Speed", "", "  0     0    0     0    0     0
0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to
127.0.0.1 port 443: Connection refused"], "stdout": "", "stdout_lines": []}

Como solución alternativa, crea una redirección de puertos desde el puerto 443 (en el que se realiza la verificación) hasta el puerto 6444 (en el que apiserver escucha) antes de la actualización. Para crear la redirección de puertos, ejecuta el siguiente comando en cada nodo del plano de control:

sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

El trabajo cal-update se ejecuta cuando hay una conciliación y se verifica en el puerto 443, por lo que debes conservar este puerto para tus clústeres actualizados 1.8.x.

Después de actualizar a la versión 1.9.0 o posterior, ejecuta el siguiente comando para quitar el puerto de cada plano del control:

sudo iptables -t nat -D OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

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:

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.

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.

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 las versiones 1.8.3 o 1.8.4

La actualización de los clústeres de Anthos en equipos físicos 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 este tipo de error, realiza los siguientes pasos para completar la actualización:

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.
Vuelve a ejecutar el comando bmctl upgrade cluster.

Limitación de la actualización del parche del clúster de usuario

Los clústeres de usuario que administra un clúster de administrador deben estar en la misma versión de los clústeres de Anthos en equipos físicos o una versión inferior y dentro de una actualización secundaria. Por ejemplo, se acepta un clúster de administrador de versión 1.7.1 (anthosBareMetalVersion: 1.7.1) que administra los clústeres de usuario de versión 1.6.2.

Una limitación de actualización te impide actualizar tus clústeres de usuario a un nuevo parche de seguridad cuando el parche se lanza después de la versión de actualización que usa el clúster de administrador. Por ejemplo, si tu clúster de administrador se encuentra en la versión 1.7.2, que se lanzó el 2 de junio de 2021, no puedes actualizar tus clústeres de usuario a la versión 1.6.4 porque se lanzó el 13 de agosto de 2021.

Incompatibilidad de Ubuntu 18.04 y 18.04.1

Para actualizar a 1.8.1 o 1.8.2, las máquinas de nodo de clúster y la estación de trabajo que ejecuta bmctl deben tener la versión de kernel de Linux 4.17.0 o posterior. 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.

Este problema se solucionó en los clústeres de Anthos en equipos físicos 1.8.3.

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.

Operación

Se reemplazó el secret de kubeconfig

Cuando el comando bmctl check cluster se ejecuta en clústeres de usuario, reemplaza el secret de kubeconfig del clúster de usuario por el kubeconfig del clúster de administrador. Reemplazar el archivo hace que las operaciones de clúster estándar, como la actualización, no funcionen en los clústeres de usuario afectados. Este problema se aplica a los clústeres de Anthos en las versiones de equipos físicos 1.11.1 y anteriores.

Para determinar si un clúster de usuario se ve afectado por este problema, ejecuta el siguiente comando:

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

Reemplaza lo siguiente:

ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador.
USER_CLUSTER_NAME: es el nombre del clúster de usuario que se verificará.

Si el nombre del clúster en el resultado (consulta contexts.context.cluster en el siguiente resultado de muestra) es el nombre del clúster de administrador, el clúster de usuario especificado se verá afectado.

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

En los siguientes pasos, se restablece la función a un clúster de usuario afectado (USER_CLUSTER_NAME):

Ubica el archivo kubeconfig del clúster de usuario.

Los clústeres de Anthos en equipos físicos generan el archivo kubeconfig en la estación de trabajo de administrador cuando creas un clúster. De forma predeterminada, el archivo está en el directorio bmctl-workspace/USER_CLUSTER_NAME.
Verifica que el archivo kubeconfig sea el archivo kubeconfig del clúster de usuario correcto:
```
kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE
```
Reemplaza PATH_TO_GENERATED_FILE por la ruta de acceso al archivo kubeconfig del clúster de usuario. En la respuesta, se muestran detalles sobre los nodos para el clúster de usuario. Confirma que los nombres de las máquinas sean correctos para tu clúster.
Ejecuta el siguiente comando para borrar el archivo kubeconfig dañado en el clúster de administrador:
```
kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
```

Ejecuta el siguiente comando para guardar el secret de kubeconfig correcto en el clúster de administrador:

kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE

Restablecimiento/eliminación

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. La compatibilidad con la rotación a pedido es una función de vista previa.

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 la CA del clúster (función de vista previa)

Después de realizar una rotación de autoridad certificadora (CA) de clúster de usuario en un clúster, todos los flujos de autenticación de 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 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 que 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.

Herramientas de redes

IP de origen del cliente con balanceo de cargas de capa 2 en paquetes

Configurar la política de tráfico externo como Local puede causar errores de enrutamiento, como No route to host, para el balanceo de cargas de capa 2 en paquetes. La política de tráfico externo se establece como Cluster (externalTrafficPolicy: Cluster) de forma predeterminada. Con esta configuración, Kubernetes maneja el tráfico de todo el clúster. Los servicios de tipo LoadBalancer o NodePort pueden usar externalTrafficPolicy: Local para conservar la dirección IP de origen del cliente. Sin embargo, con esta configuración, Kubernetes solo controla el tráfico local de los nodos.

Si deseas conservar la dirección IP de origen del cliente, es posible que se requiera una configuración adicional para garantizar que se pueda acceder a las IP del servicio. Para obtener detalles sobre la configuración, consulta Preserva la dirección IP de origen del cliente en Configura el balanceo de cargas en paquetes.

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 debido al tiempo de espera de E/S y al filtrado de ruta de acceso inversa

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

Las fallas de conectividad que se comunican con las direcciones IP del Service de Kubernetes son un síntoma de este problema. A continuación, se muestran algunos ejemplos de los tipos de errores que puedes ver:

Si todos los Pods de un nodo determinado no se pueden comunicar con las direcciones IP del Service, es posible que el Pod istiod informe un error como el siguiente:

 {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

Para el conjunto de daemon localpv que se ejecuta en cada nodo, el registro puede mostrar un tiempo de espera como el siguiente:

 I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

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). El comando sysctl 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. El comando sysctl puede anular la configuración del filtrado de la ruta de acceso inversa.

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. Se iniciará un Pod anetd nuevo 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.

Para configurar net.ipv4.conf.all.rp_filter de forma manual, ejecuta el siguiente comando:

sysctl -w net.ipv4.conf.all.rp_filter = 0

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 validación para las direcciones IP superpuestas en diferentes clústeres durante la actualización. La validación solo se aplica durante la creación del grupo de nodos o clúster.

Sistema operativo

La creación o actualización de clústeres falla en CentOS

En diciembre de 2020, la comunidad de CentOS y Red Hat anunciaron la desactivación de CentOS. El 31 de enero de 2022, CentOS 8 llegó al final del ciclo de vida (EOL). Como resultado del EOL, los repositorios yum dejaron de funcionar para CentOS, lo que hace que las operaciones de creación y actualización del clústeres fallen. Esto se aplica a todas las versiones compatibles de CentOS y afecta a todas las versiones de los clústeres de Anthos en equipos físicos.

Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivos:

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

Como solución a largo plazo, considera migrar a otro sistema operativo compatible.

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.

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.

Registro y supervisión

`stackdriver-log-forwarder` Se detuvo el reinicio del Pod

En el caso de los clústeres de Anthos en versiones de equipos físicos anteriores a la 1.9, si un nodo se cierra de manera forzada, es posible que el Pod stackdriver-log-forwarder se quede atascado en un estado de reinicio. En este caso, es posible que veas una entrada de registro como la que se muestra a continuación:

[error] [input:storage_backlog:storage_backlog.7] chunk validation failed, data might
be corrupted. Found 0 valid records, failed content starts right after byte 0.

Cuando el Pod stackdriver-log-forwarder está atascado, la mayoría de los registros no pueden enviar a Cloud Logging y se pierden los datos sin vaciar. Para resolver este problema, restablece la canalización de registros.

Para restablecer la canalización de registros, haz lo siguiente:

Reduce verticalmente la escala de stackdriver-operator.

kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=0

Borra el DaemonSet stackdriver-log-forwarder:
```
kubectl --kubeconfig KUBECONFIG -n kube-system delete daemonset \
    stackdriver-log-forwarder
```
Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso.

Implementa el siguiente DaemonSet para limpiar los datos dañados en los búferes fluent-bit:

kubectl --kubeconfig 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

Asegúrate de que el DaemonSet limpió todos los nodos.

El resultado de los siguientes comandos debe ser igual a la cantidad de nodos de tu clúster.

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

Borra el DaemonSet de limpieza:

kubectl --kubeconfig KUBECONFIG -n kube-system delete ds fluent-bit-cleanup

Escala verticalmente el operador y espera a que vuelva a implementar la canalización de registro.

kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=1

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

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

Instalación

La creación del clúster falla cuando se usan varias NIC, containerd y un proxy

Incompatibilidad del grupo de control v2

Mensajes de error benignos durante la instalación

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

Comprobaciones previas y permisos denegados

Credenciales predeterminadas de la aplicación y bmctl

LTS de Ubuntu 20.04 y bmctl

Servicio de Docker

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

Containerd requiere /usr/local/bin en la RUTA

Realiza la instalación en vSphere

Oscilación de preparación de nodo

Containerd de Ubuntu

Docker de Ubuntu

Containerd de CentOS/RHEL

Docker de CentOS/RHEL

Revisiones y actualizaciones

bmctl update cluster falla si falta el directorio .manifests

La actualización se detuvo en error during manifests operations

Las actualizaciones fallan para los clústeres de la versión 1.8 en modo de mantenimiento

bmctl update no quita los bloques de mantenimiento

Las actualizaciones del clúster de la versión 1.7.x fallan para ciertas opciones de configuración del balanceador de cargas

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

Actualizaciones a las versiones 1.8.3 o 1.8.4

Limitación de la actualización del parche del clúster de usuario

Incompatibilidad de Ubuntu 18.04 y 18.04.1

Actualiza los clústeres 1.7.x que usan containerd

Fallas de actualización de SELinux

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

Operación

Se reemplazó el secret de kubeconfig

Restablecimiento/eliminación

Eliminación del espacio de nombres

servicio de containerd

Seguridad

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

Herramientas de redes

IP de origen del cliente con balanceo de cargas de capa 2 en paquetes

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

Direcciones egressSourceIP duplicadas

Fallas de conectividad del Pod debido al tiempo de espera de E/S y al filtrado de ruta de acceso inversa

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

Cómo superponer direcciones IP en diferentes clústeres

Sistema operativo

La creación o actualización de clústeres falla en CentOS

Limitaciones del extremo del sistema operativo

Configuración

Especificaciones del plano de control y el balanceador de cargas

Entorno de ejecución de VM de Anthos

SELinux

Errores de SELinux durante la creación de Pods

Instantáneas

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

GKE Connect

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

Registro y supervisión

stackdriver-log-forwarder Se detuvo el reinicio del Pod

La creación del clúster falla cuando se usan varias NIC, `containerd` y un proxy

Credenciales predeterminadas de la aplicación y `bmctl`

LTS de Ubuntu 20.04 y `bmctl`

Containerd requiere `/usr/local/bin` en la RUTA

`bmctl update cluster` falla si falta el directorio `.manifests`

La actualización se detuvo en `error during manifests operations`

`bmctl update` no quita los bloques de mantenimiento

Direcciones `egressSourceIP` duplicadas

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

`stackdriver-log-forwarder` Se detuvo el reinicio del Pod