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

Selecciona tus clústeres de Anthos en versión Bare Metal:

Selecciona la categoría del problema:

O bien, busca tu problema:

Categoría Versiones identificadas Problema y solución alternativa
Instalación 1.10, 1.11.0, 1.11.1, 1.11.2

El detector de problemas de nodo falla en el clúster de usuario 1.10.4

El detector de problemas de Node puede fallar en los clústeres de Anthos en clústeres de usuario de Bare Metal 1.10.x, cuando los clústeres de Anthos en los clústeres de administrador de Bare Metal 1.11.0, 1.11.1 o 1.11.2 administran clústeres de usuario 1.10.x. Cuando el detector de problemas de Node falla, el registro se actualiza con el siguiente mensaje de error:


Error - NPD not supported for anthos baremetal version 1.10.4: anthos version
      1.10.4 not supported.

Solución alternativa

Actualiza el clúster de administrador a 1.11.3 para resolver el problema.
Operación 1.14

1.14 nodos del clúster de IPv4 en modo isla tienen un tamaño de máscara CIDR de Pod de 24

En la versión 1.14, la configuración de maxPodsPerNode no se tiene en cuenta para los clústeres en modo de isla, por lo que se asigna un tamaño de máscara CIDR de pod de 24 (256 direcciones IP) a los nodos. Esto puede provocar que el clúster se quede sin direcciones IP del pod antes de lo esperado. Por ejemplo, si tu clúster tiene una máscara CIDR de pod de 22, a cada nodo se le asignará una máscara CIDR de pod de 24 y el clúster solo podrá admitir hasta 4 nodos. Es posible que tu clúster también experimente inestabilidad de la red en un período de deserción de pod alto cuando maxPodsPerNode esté configurado en 129 o más y no haya suficiente sobrecarga en el CIDR del pod para cada nodo.

Si tu clúster se ve afectado, el pod anetd informa el siguiente error cuando agregas un nodo nuevo al clúster y no hay podCIDR disponibles:


error="required IPv4 PodCIDR not available"

Solución alternativa

Sigue estos pasos para solucionar el problema:

  1. Actualiza a la versión 1.14.1 o posterior.
  2. Quita los nodos trabajadores y vuelve a agregarlos.
  3. Quita los nodos del plano de control y vuelve a agregarlos, preferentemente, uno por uno para evitar el tiempo de inactividad del clúster.
Revisiones y actualizaciones 1.14.0, 1.14.1

Error de reversión de la actualización del clúster

Una reversión de actualización puede fallar en los clústeres de Anthos en equipos físicos 1.14.0 a 1.14.1. Si actualizas un clúster de 1.14.0 a 1.14.1 y, luego, intentas revertir a la versión 1.14.0 mediante el comando bmctl restore cluster, es posible que se muestre un error como el del siguiente ejemplo:


I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck"
cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Solución alternativa:

Borra todos los recursos healthchecks.baremetal.cluster.gke.io en el espacio de nombres del clúster y, luego, vuelve a ejecutar el comando bmctl restore cluster:

  1. Enumera todos los recursos healthchecks.baremetal.cluster.gke.io: 
    kubectl get healthchecks.baremetal.cluster.gke.io \
  --namespace=CLUSTER_NAMESPACE \
  --kubeconfig=ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: El espacio de nombres del clúster.
    • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  2. Borra todos los recursos healthchecks.baremetal.cluster.gke.io que se muestran en el paso anterior: 
    kubectl delete healthchecks.baremetal.cluster.gke.io HEALTHCHECK_RESOURCE_NAME
  --namespace=CLUSTER_NAMESPACE \
  --kubeconfig=ADMIN_KUBECONFIG
     Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de la verificación de estado.
  3. Vuelve a ejecutar el comando bmctl restore cluster.
Herramientas de redes 1.12.0

La dirección IP externa del servicio no funciona en modo plano

En un clúster que tiene flatIPv4 configurado como true, no se puede acceder a los servicios de tipo LoadBalancer por sus direcciones IP externas.

Este problema se solucionó en la versión 1.12.1.


Solución alternativa:

En el ConfigMap de cilium-config, establece enable-415 en "true" y, luego, reinicia los pods anetd.
Revisiones y actualizaciones 1.13.0, 1.14

Las actualizaciones in situ de 1.13.0 a 1.14.x nunca finalizan

Cuando intentas realizar una actualización in situ de 1.13.0 a 1.14.x mediante bmctl 1.14.0 y la marca --use-bootstrap=false, la actualización nunca finaliza.

Un error con el operador preflight-check hace que el clúster nunca programe las verificaciones requeridas, lo que significa que la verificación previa nunca finaliza.


Solución alternativa:

Actualiza a la versión 1.13.1 antes de actualizar a la versión 1.14.x. Una actualización in situ debería funcionar de 1.13.0 a 1.13.1. También puedes actualizar de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.
Actualizaciones y actualizaciones, Seguridad 1.13 y 1.14

Los clústeres actualizados a la versión 1.14.0 pierden taints principales

Los nodos del plano de control requieren uno de dos taints específicos para evitar que los pods de la carga de trabajo se programen en ellos. Cuando actualizas los clústeres de Anthos a la versión 1.14.0, los nodos del plano de control pierden los siguientes taints obligatorios:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Este problema no causa fallas de actualización, pero los pods que no deben ejecutarse en los nodos del plano de control pueden comenzar a hacerlo. Estos pods de carga de trabajo pueden abrumar los nodos del plano de control y generar inestabilidad del clúster.

Cómo determinar si se ve afectado

  1. Busca los nodos del plano de control con el siguiente comando: 
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. Para verificar la lista de taints en un nodo, usa el siguiente comando: 
    kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    Si no aparece ninguno de los taints requeridos, entonces se ve afectado.

Solución alternativa

Usa los siguientes pasos para cada nodo del plano de control del clúster de la versión 1.14.0 afectado a fin de restablecer la función adecuada. Estos pasos son para el taint node-role.kubernetes.io/master:NoSchedule y los pods relacionados. Si deseas que los nodos del plano de control usen el taint PreferNoSchedule, ajusta los pasos según corresponda.

Operación, entorno de ejecución de VM de Anthos 1.11, 1.12, 1.13 y 1.14

La creación de una VM falla de forma intermitente con errores de carga

La creación de una nueva máquina virtual (VM) con el comando “kubectl virt create vm” falla con poca frecuencia durante la carga de imágenes. Este problema se aplica a las VM de Linux y Windows. El error se parece al siguiente ejemplo: 

PVC default/heritage-linux-vm-boot-dv not found
DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready...
Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,
...

Solución alternativa

Vuelve a ejecutar el comando kubectl virt create vm para crear tu VM.
Actualizaciones, registros y supervisión 1.11

Los componentes de la colección administrada en los clústeres 1.11 no se conservan en las actualizaciones a la versión 1.12

Los componentes de la colección administrada forman parte del servicio administrado para Prometheus. Si implementaste de forma manual los componentes de la colección administrada en el espacio de nombres gmp-system de los clústeres de la versión 1.11 de Anthos, los recursos asociados no se conservarán cuando actualices a la versión 1.12.

A partir de los clústeres de Anthos en la versión 1.12.0 de Bare Metal, el servicio administrado para componentes de Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionados se administran mediante stackdriver-operator con el campo enableGMPForApplications. El valor predeterminado del campo enableGMPForApplications es true, por lo que si implementas de forma manual el servicio administrado para los componentes de Prometheus en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver-operator borra los recursos.

Solución alternativa

Para conservar recursos de colección administrados manualmente, haz lo siguiente:

  1. Crea una copia de seguridad de todos los recursos personalizados de PodMonitoring existentes.
  2. Actualiza el clúster a la versión 1.12 y habilita el servicio administrado para Prometheus.
  3. Vuelve a implementar los recursos personalizados de PodMonitoring en el clúster actualizado.
Revisiones y actualizaciones 1.13

Algunos clústeres de la versión 1.12 con el entorno de ejecución del contenedor de Docker no se pueden actualizar a la versión 1.13

Si a un clúster de la versión 1.12 que usa el entorno de ejecución de contenedores de Docker le falta la siguiente anotación, no se puede actualizar a la versión 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Si este problema te afecta, bmctl escribe el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:


Operation failed, retrying with backoff. Cause: error creating
"baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime:
Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime
to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools
until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker-
container-runtime: true" to the cluster configuration file.

Esto es más probable que ocurra con los clústeres de Docker de la versión 1.12 que se actualizaron desde la versión 1.11, ya que esa actualización no requiere la anotación para mantener el entorno de ejecución del contenedor de Docker. En este caso, los clústeres no tienen la anotación cuando se actualizan a la versión 1.13. Ten en cuenta que, a partir de la versión 1.13, containerd es el único entorno de ejecución de contenedores permitido.

Solución alternativa:

Si te afecta este problema, actualiza el recurso del clúster con la anotación que falta. Puedes agregar la anotación mientras se ejecuta la actualización o después de cancelarla y antes de reintentarla.
Instalación 1.11

bmctl finaliza antes de que se complete la creación del clúster.

La creación de clústeres puede fallar en los clústeres de Anthos a partir de la versión 1.11.0 de Bare Metal (este problema se soluciona en los clústeres de Anthos en la versión 1.11.1 de Bare Metal). En algunos casos, el comando bmctl create cluster se cierra de manera anticipada y escribe errores como los siguientes en los registros:


Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Solución alternativa

La operación con errores produce artefactos, pero el clúster no está operativo. Si este problema te afecta, sigue estos pasos para limpiar los artefactos y crear un clúster:
Instalación, entorno de ejecución de VM de Anthos 1.11 a 1.12

Errores de conciliación de los informes de instalación del entorno de ejecución de VM

La operación de creación de clústeres puede informar un error similar al siguiente:


I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Solución alternativa

Este error es benigno y puedes ignorarlo.
Instalación 1.10, 1.11, 1.12

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

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, el valor predeterminado para clústeres de Anthos en la versión 1.14 de Bare Metal).
  • El clúster está configurado a fin de proporcionar interfaces de red múltiples, varias NIC para los pods (clusterNetwork.multipleNetworkInterfaces establecido en true en el archivo de configuración del clúster).
  • El clúster está configurado para usar un proxy (spec.proxy.url se especifica en el archivo de configuración del clúster). Aunque la creación del clúster falla, esta configuración se propaga cuando intentas crear un clúster. Puedes ver esta configuración de proxy como una variable de entorno HTTPS_PROXY o en tu configuración containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Solución alternativa

Agrega los CIDR del servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodo.
Instalación 1.10, 1.11, 1.12

Errores en sistemas con una configuración de umask restrictiva

La versión 1.10.0 de los clústeres de Anthos en Bare Metal introdujo una función del plano de control sin raíz que ejecuta todos los componentes del plano de control como un usuario no raíz. Ejecutar todos los componentes como usuario no raíz puede causar fallas en la instalación o actualización en sistemas con una configuración de umask más restringida de 0077.


Solución alternativa

Restablece los nodos del plano de control y cambia la configuración de umask a 0022 en todas las máquinas del plano de control. Después de actualizar las máquinas, vuelve a intentar la instalación.

Como alternativa, puedes cambiar los permisos de directorio y archivo de /etc/kubernetes en las máquinas del plano de control para que la instalación o actualización se realicen.

  • Haz que /etc/kubernetes y todos sus subdirectorios sean legibles: chmod o+rx.
  • Haz que todos los archivos del usuario root en el directorio (de manera recurrente) /etc/kubernetes sean legibles para todos (chmod o+r). Excluye los archivos de claves privadas (.key) de estos cambios porque ya se crearon con la propiedad y los permisos correctos.
  • Haz que /usr/local/etc/haproxy/haproxy.cfg sea legible.
  • Haz que /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml sea legible en todo el mundo.
Instalación 1.10, 1.11, 1.12, 1.13

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible con las versiones 1.13 y anteriores de los clústeres de Anthos en Bare Metal. Sin embargo, la versión 1.14 admite cgroup v2 como función Vista previa. La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.


Solución alternativa

Si tu sistema usa cgroup v2, actualiza a la versión 1.14 de los clústeres de Anthos en Bare Metal.
Instalación 1.10, 1.11, 1.12, 1.13, 1.14

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 que no se crearon con bmctl, como clústeres de usuario), la verificación previa no verifica las credenciales de la cuenta de servicio de Google Cloud ni sus permisos asociados.
Instalación 1.10, 1.11, 1.12, 1.13, 1.14

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 se establece en global.


Solución alternativa

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.
Instalación 1.10, 1.11, 1.12, 1.13, 1.14

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 previa fallará y se informará que Docker service is not active.


Solución alternativa

Quita Docker o habilita el servicio Docker.
Instalación 1.10, 1.11, 1.12, 1.13, 1.14

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 por hardware realizada por el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de los clústeres de Anthos en Bare Metal.


Solución alternativa

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. A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas cuando no lo están. Para desactivar estas marcas de forma 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 configurar de manera explícita estas marcas cuando se inicia el sistema.
Revisiones y actualizaciones 1.10

bmctl no puede crear, actualizar ni restablecer clústeres de usuarios de la versión anterior.

La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria inferior, sin importar la versión del clúster de administrador. Por ejemplo, no puedes usar bmctl con una versión de 1.N.X para restablecer un clúster de usuario de la versión 1.N-1.Y, incluso si el clúster de administrador también está en la versión 1.N.X.

Si te afecta este problema, deberías ver registros similares a los siguientes cuando uses bmctl:


[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
    * cluster version 1.8.1 is not supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Solución alternativa:

Usa kubectl para crear, editar o borrar el recurso personalizado del clúster de usuario dentro del clúster de administrador.

La capacidad de actualizar los clústeres de usuario no se ve afectada.
Revisiones y actualizaciones 1.12

Las actualizaciones del clúster a la versión 1.12.1 podrían detenerse

A veces, la actualización de los clústeres a la versión 1.12.1 se bloquea debido a que el servidor de la API no está disponible. Este problema afecta a todos los tipos de clústeres y a todos los sistemas operativos compatibles. Cuando se produce este problema, el comando bmctl upgrade cluster puede fallar en varios puntos, incluso durante la segunda fase de verificaciones previas.


Solución alternativa

Puedes verificar tus registros de actualización para determinar si este problema te afecta. Los registros de actualización se encuentran en /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP de forma predeterminada. upgrade-cluster.log puede contener errores como los siguientes: 


Failed to upgrade cluster: preflight checks failed: preflight check failed
El registro de la máquina puede contener errores como los siguientes (las fallas repetidas indican que este problema te afecta): 

FAILED - RETRYING: Query CNI health endpoint (30 retries left).
FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left).
...
HAProxy y Keepalived deben ejecutarse en cada nodo del plano de control antes de volver a intentar actualizar tu clúster a la versión 1.12.1. Usa la interfaz de línea de comandos de crictl en cada nodo para verificar si los contenedores haproxy y keepalived están en ejecución: 
docker/crictl ps | grep haproxy
docker/crictl ps | grep keepalived
 Si HAProxy o Keepalived no están en ejecución en un nodo, reinicia kubelet en el nodo:

systemctl restart kubelet
Actualizaciones y actualizaciones, Anthos VM Runtime 1.11 a 1.12

La actualización de clústeres a la versión 1.12.0 o superior falla cuando está habilitado el entorno de ejecución de VM de Anthos

En los clústeres de Anthos en la versión 1.12.0 de Bare Metal, todos los recursos relacionados con el entorno de ejecución de VM de Anthos se migran al espacio de nombres vm-system para admitir mejor la versión de disponibilidad general de Anthos VM. Si tienes habilitado el entorno de ejecución de VM de Anthos en un clúster de la versión 1.11.x o inferior, la actualización a la versión 1.12.0 o superior falla, a menos que inhabilites el entorno de ejecución de VM de Anthos por primera vez. Cuando este problema te afecta, la operación de actualización informa el siguiente error:


Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version

Solución alternativa

Para inhabilitar el entorno de ejecución de VM de Anthos, sigue estos pasos:

  1. Edita el recurso personalizado VMRuntime: 
    kubectl edit vmruntime
  2. Establece enabled como false en la especificación: 
    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
...
  3. Guarda el recurso personalizado en tu editor.
  4. Una vez que se complete la actualización del clúster, vuelve a habilitar Anthos VM Runtime.

Para obtener más información, consulta Trabaja con cargas de trabajo basadas en VM.
Revisiones y actualizaciones 1.10, 1.11, 1.12

Actualización atascada 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 incorrectamente. Para determinar si te afecta este problema y corregirlo, 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 que se actualizó de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso del problema.


Solución alternativa

Si encuentras estos errores en tus registros, completa los siguientes pasos:

  1. Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso contenido en el mensaje de registro.
  2. Guarda los cambios y aplícalos al recurso.
  3. Vuelve a intentar la actualización del clúster.
Revisiones y actualizaciones 1.10, 1.11, 1.12

Las actualizaciones están bloqueadas para los clústeres con características que usan la puerta de enlace de red de Anthos

Las actualizaciones de clústeres de 1.10.x a 1.11.x fallan para los clústeres que usan la puerta de enlace NAT de salida o el balanceo de cargas en paquetes con BGP. Ambas funciones usan Anthos Network Gateway. Las actualizaciones del clúster se atascan en el mensaje de línea de comandos Waiting for upgrade to complete... y los errores de registro anthos-cluster-operator como el siguiente:


apply run failed ...
MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable...

Solución alternativa

Para desbloquear la actualización, ejecuta los siguientes comandos en el clúster que deseas actualizar:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler

kubectl -n kube-system delete deployment \
    ang-controller-manager

kubectl -n kube-system delete ds ang-node
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14

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.


Solución alternativa

Para obtener más información, incluidas las instrucciones para quitar nodos del modo de mantenimiento, consulta Cómo poner nodos en modo de mantenimiento.
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14

El vaciado de nodos no puede iniciarse cuando el nodo está fuera del alcance

El proceso de desvío de los nodos no comenzará si el nodo está fuera del alcance de los clústeres de Anthos en un equipo físico. Por ejemplo, si un nodo se desconecta durante un proceso de actualización del clúster, es posible que la actualización deje de responder. Esto es poco frecuente.


Solución alternativa

Para minimizar la probabilidad de encontrar este problema, asegúrate de que tus nodos funcionen correctamente antes de iniciar una actualización.
Revisiones y actualizaciones 1.12

containerd 1.5.13 requiere libseccomp 2.5 o una versión posterior

La versión 1.12.1 de Anthos en clústeres físicos se envía con la versión 1.5.13 de containerd, y esta versión de containerd requiere libseccomp versión 2.5 o posterior.

Si tu sistema no tiene instalada la versión 2.5 o superior de libseccomp, actualízala antes de actualizar los clústeres existentes a la versión 1.12.1. De lo contrario, es posible que veas errores en los pods cplb-update de los nodos del balanceador de cargas, como los siguientes:


runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond

Solución alternativa

Para instalar la versión más reciente de libseccomp en Ubuntu, ejecuta el siguiente comando:

sudo apt-get install  libseccomp-dev

Para instalar la versión más reciente de libseccomp en CentOS o RHEL, ejecuta el siguiente comando:

sudo dnf -y install libseccomp-devel
Operación 1.10, 1.11, 1.12

No se acordonan los nodos si no usas el procedimiento del modo de mantenimiento

Si ejecutas clústeres de Anthos en la versión 1.12.0 (anthosBareMetalVersion: 1.12.0) de Bare Metal o una versión anterior y usas kubectl cordon de forma manual en un nodo, es posible que los clústeres de Anthos en Bare Metal desacorden el nodo antes de que estés listo para conciliar el estado esperado.


Solución alternativa

Para los clústeres de Anthos en la versión 1.12.0 de Bare Metal y versiones anteriores, usa el modo de mantenimiento a fin de acordonar y desviar los nodos de forma segura.

En la versión 1.12.1 (anthosBareMetalVersion: 1.12.1) o superior, los clústeres de Anthos en equipos físicos no desacordonarán tus nodos de forma inesperada cuando uses kubectl cordon.
Operación 1.11

Los clústeres de administrador de la versión 11 mediante una duplicación de registro no pueden administrar los clústeres de la versión 1.10

Si tu clúster de administrador está en la versión 1.11 y usa una duplicación de registro, no podrá administrar los clústeres de usuario que estén en una versión secundaria inferior. Este problema afecta las operaciones de restablecimiento, actualización y actualización del clúster de usuario.

Para determinar si este problema te afecta, revisa tus registros en busca de operaciones de clúster, como crear, actualizar o restablecer. Estos registros se encuentran en la carpeta bmctl-workspace/CLUSTER_NAME/ de forma predeterminada. Si te afecta el problema, tus registros contendrán el siguiente mensaje de error:


flag provided but not defined: -registry-mirror-host-to-endpoints
Operación 1.10, 1.11

Se reemplazó el secreto del kubeconfig

El comando bmctl check cluster, cuando se ejecuta en clústeres de usuario, reemplaza el secreto kubeconfig del clúster de usuario por el kubeconfig del clúster de administrador. Reemplazar el archivo provoca que las operaciones de clúster estándar, como la actualización y la actualización, fallen por los clústeres de usuario afectados. Este problema se aplica a los clústeres de Anthos en versiones 1.11.1 y anteriores de Bare Metal.

Para determinar si este problema afecta a un clúster de usuario, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

  • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  • USER_CLUSTER_NAMESPACE: El espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en Bare Metal son el nombre del clúster precedido de cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres predeterminado es cluster-test.
  • USER_CLUSTER_NAME: Es el nombre del clúster de usuario que se debe 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, entonces el clúster de usuario especificado se ve 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-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Solución alternativa

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

  1. 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 se encuentra en el directorio bmctl-workspace/USER_CLUSTER_NAME.
  2. 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. La respuesta muestra detalles sobre los nodos del clúster de usuario. Confirma que los nombres de máquina sean correctos para tu clúster.
  3. 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
  4. Ejecuta el siguiente comando para volver a guardar el secreto 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
Operación 1.10, 1.11, 1.12, 1.13, 1.14

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

Si usas containerd como entorno de ejecución del contenedor, la ejecución de la instantánea como usuario no raíz requiere que /usr/local/bin esté en la ruta de acceso del usuario. De lo contrario, fallará con un error crictl: command not found.

Cuando no accedes como usuario raíz, se usa sudo para ejecutar los comandos de instantáneas. La ruta de acceso sudo puede ser diferente del perfil raíz y no puede contener /usr/local/bin.


Solución alternativa

Actualiza secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.
Operación, entorno de ejecución de VM de Anthos 1.10, 1.11, 1.12, 1.13, 1.14

Anthos VM Runtime: Cuando reinicias un pod, las VM del pod cambian las direcciones IP o pierden sus direcciones 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.


Solución alternativa

Si se pierde la dirección IP, debes ejecutar dhclient desde la VM a fin de adquirir una dirección IP para la VM.
Registro y supervisión 1.10

stackdriver-log-forwarder tiene [parser:cri] invalid time format registros de advertencia

Si el analizador de entornos de ejecución del contenedor (CRI) usa una expresión regular incorrecta para el tiempo de análisis, los registros del pod stackdriver-log-forwarder contienen errores y advertencias como los siguientes:


[2022/03/04 17:47:54] [error] [parser] time string length is too long
[2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Solución alternativa:
Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14

Facturación inesperada de Monitoring

Para los clústeres de Anthos en las versiones 1.10 de Bare Metal a la versión más reciente, algunos clientes notaron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo afecta a las siguientes circunstancias:

  • Se habilitó la supervisión de la aplicación (enableStackdriverForApplications=true)
  • Servicio administrado para Prometheus no está habilitado (enableGMPForApplications)
  • Los pods de la aplicación tienen la anotación prometheus.io/scrap=true.

Para confirmar si te afecta este problema, enumera las métricas definidas por el usuario. Si ves la facturación de métricas no deseadas, este problema se aplica a ti.


Solución alternativa

Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 y cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que abordan este problema:

  • Marcas separadas para controlar la recopilación de registros de la aplicación en comparación con las métricas de la aplicación
  • Paquete de Google Cloud Managed Service para Prometheus

    • Si no puedes actualizar a la versión 1.12, sigue estos pasos:

    1. Encuentra los servicios y los pods de origen que tienen la facturación no deseada 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del Pod o del Service.
    Registro y supervisión 1.11, 1.12, 1.13, 1.14

    No se mantienen las modificaciones en metrics-server-config

    En casos extremos, la alta densidad de pods puede generar una sobrecarga excesiva de registro y supervisión, lo que puede hacer que el servidor de métricas se detenga y se reinicie. Puedes editar el ConfigMap de metrics-server-config para asignar más recursos y mantener el servidor de métricas en ejecución. Sin embargo, debido a la conciliación, las modificaciones que se realicen en metrics-server-config se pueden revertir al valor predeterminado durante una operación de actualización o actualización del clúster. El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, recoge el ConfigMap revertido y es vulnerable a una sobrecarga excesiva.


    Solución alternativa

    Para la versión 1.11.x, puedes crear una secuencia de comandos del cambio de ConfigMap y realizarlo junto con las actualizaciones o las actualizaciones del clúster. Si tu versión es de 1.12 en adelante, comunícate con el equipo de asistencia.
    Registro y supervisión 1.11 a 1.12

    Las métricas obsoletas afectan al panel de Cloud Monitoring.

    Varias métricas de Anthos dejaron de estar disponibles y, a partir de los clústeres de Anthos en la versión 1.11 de Bare Metal, ya no se recopilan datos para estas métricas obsoletas. Si usas estas métricas en cualquiera de tus políticas de alertas, no habrá datos para activar la condición de alerta.

    En la siguiente tabla, se enumeran las métricas individuales que dejaron de estar disponibles y la métrica que las reemplaza.

    Métricas obsoletas Métrica de reemplazo
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity

    En los clústeres de Anthos en versiones Bare Metal anteriores a la 1.11, el archivo de definición de políticas para la alerta Anthos on baremetal node cpu usage exceeds 80 percent (critical) recomendada usa las métricas obsoletas. El archivo de definición JSON node-cpu-usage-high.json se actualiza para las versiones 1.11.0 y posteriores.


    Solución alternativa

    Sigue estos pasos para migrar a las métricas de reemplazo:

    1. En Google Cloud Console, selecciona Monitoring o haz clic en el siguiente botón:
      Ir a Monitoring
    2. En el panel de navegación, selecciona Paneles y borra el panel Estado del nodo del clúster de Anthos.
    3. Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel Estado del nodo del clúster de Anthos.
    4. Sigue las instrucciones en Crea políticas de alertas para crear una política con el archivo de definición de política node-cpu-usage-high.json actualizado.
    Registro y supervisión 1.10, 1.11

    stackdriver-log-forwarder tiene errores CrashloopBackOff

    En algunas situaciones, el agente de registro fluent-bit puede atascarse en el procesamiento de fragmentos dañados. Cuando el agente de Logging no puede omitir los fragmentos dañados, puedes observar que stackdriver-log-forwarder sigue fallando con un error CrashloopBackOff. Si tienes este problema, tus registros tienen entradas como las siguientes:

    
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV)
#0  0x5590aa24bdd5      in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117
#5  0xffffffffffffffff  in  ???() at ???:0

    Solución alternativa:

    Limpia los fragmentos de búfer para el reenvío de registros de Stackdriver.

    Nota: En los siguientes comandos, reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.

    1. Finaliza todos los Pods stackdriver-log-forwarder: 
          kubectl --kubeconfig 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.
    2. 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
    3. Usa los siguientes comandos para verificar que el DaemonSet limpió todos los nodos: 
      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
       El resultado de los dos comandos debe ser igual a la cantidad de nodos en el clúster.
    4. Borra el DaemonSet de limpieza: 
      kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. Reinicia los Pods del agente de reenvío de registros: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14

    Datos de métricas desconocidos en Cloud Monitoring

    Los datos en los clústeres de la versión 1.10.x de Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Entre otros tipos de métricas que pueden tener métricas de resumen irrelevantes, se incluyen los siguientes:

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen están en la lista de métricas, gke-metrics-agent no las admite en este momento.
    Registro y supervisión 1.10, 1.11

    Interrupciones intermitentes en la exportación de métricas

    Los clústeres de Anthos en equipos físicos pueden experimentar interrupciones en la exportación normal y normal de las métricas, o bien métricas faltantes en algunos nodos. Si este problema afecta a tus clústeres, es posible que veas brechas en los datos para las siguientes métricas (como mínimo):

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solución alternativa

    Actualiza tus clústeres a la versión 1.11.1 o posterior.

    Si no puedes actualizar, realiza los siguientes pasos como una solución alternativa:

    1. Abre tu recurso stackdriver para editarlo: 
      kubectl -n kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
       El recurso editado debe ser similar al siguiente: 
      spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que los cambios se aplicaron, ejecuta el siguiente comando: 
      kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
       El comando busca cpu: 50m si se realizaron las modificaciones.
    Herramientas de redes 1.10

    Múltiples puertas de enlace predeterminadas interrumpen la conectividad a extremos externos

    Tener varias puertas de enlace predeterminadas en un nodo puede provocar una conectividad interrumpida desde un pod hasta extremos externos, como google.com.

    Para determinar si este problema te afecta, ejecuta el siguiente comando en el nodo:

    ip route show

    Varias instancias de default en la respuesta indican que estás afectado.
    Herramientas de redes 1.12

    Se reemplazan las ediciones personalizadas de las herramientas de redes en los clústeres de usuario.

    La versión 1.12.x de Anthos en clústeres físicos no te impide editar de forma manual los recursos personalizados de herramientas de redes en tu clúster de usuario. Los clústeres de Anthos en equipos físicos concilian los recursos personalizados de los clústeres de usuario con los recursos personalizados de tu clúster de administrador durante las actualizaciones del clúster. Esta conciliación sobrescribe las modificaciones realizadas directamente en los recursos personalizados de red en el clúster de usuario. Los recursos personalizados de red deben modificarse solo en el clúster de administrador, pero los clústeres de Anthos en la versión 1.12.x de Bare Metal no aplican este requisito.

    Las características de red avanzadas, como el balanceo de cargas en paquetes con BGP, la puerta de enlace NAT de salida, las redes SR-IOV, el modo plano con BGP y la varias NIC para pods usan los siguientes recursos personalizados:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Edita estos recursos personalizados en el clúster de administrador y el paso de conciliación aplica los cambios a los clústeres de usuario.


    Solución alternativa

    Si modificaste alguno de los recursos personalizados mencionados anteriormente en un clúster de usuario, modifica los recursos personalizados correspondientes en el clúster de administrador para que coincidan antes de la actualización. Este paso garantiza que se conserven los cambios de configuración. Los clústeres de Anthos en equipos físicos 1.13.0 y versiones posteriores impiden que modifiques los recursos personalizados de red en tus clústeres de usuario directamente.
    Herramientas de redes 1.11, 1.12, 1.13, 1.14

    Falla de NAT con demasiadas conexiones paralelas

    Para un nodo determinado en tu clúster, la dirección IP del nodo proporciona traducción de direcciones de red (NAT) para los paquetes enrutados a una dirección fuera del clúster. Del mismo modo, cuando los paquetes entrantes ingresan a un nodo de balanceo de cargas configurado para usar el balanceo de cargas en paquetes (spec.loadBalancer.mode: bundled), la traducción de direcciones de red de origen (SNAT) enruta los paquetes a la dirección IP del nodo antes de que se reenvíen a un pod de backend.

    El rango de puertos para NAT que usan los clústeres de Anthos en Bare Metal es de 32768 a 65535. Este rango limita la cantidad de conexiones paralelas a 32,767 por protocolo en ese nodo. Cada conexión necesita una entrada en la tabla de conntrack. Si tienes demasiadas conexiones de corta duración, la tabla de conntrack se queda sin puertos para NAT. Un recolector de elementos no utilizados limpia las entradas inactivas, pero la limpieza no es inmediata.

    Cuando la cantidad de conexiones en tu nodo se acerque a 32,767, comenzarás a ver disminuciones de paquetes para conexiones que necesitan NAT.

    Para identificar este problema, ejecuta el siguiente comando en el pod anetd en el nodo problemático: 

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    Deberías ver los siguientes errores:

    
No mapping for NAT masquerade DROPPED

    Solución alternativa

    Redistribuye tu tráfico a otros nodos.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

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

    Si estableces la política de tráfico externo en Local, se pueden generar errores de enrutamiento, como No route to host, para el balanceo de cargas de la capa 2. La política de tráfico externo se establece en Cluster (externalTrafficPolicy: Cluster) de forma predeterminada. Con esta configuración, Kubernetes controla el tráfico en 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 maneja el tráfico local del nodo.


    Solución alternativa

    Si deseas conservar la dirección IP de origen del cliente, es posible que se requiera una configuración adicional para garantizar que las IP de servicio sean accesibles. Para obtener más información sobre la configuración, consulta la sección sobre la preservación de la dirección IP de origen del cliente en la configuración del balanceo de cargas en paquetes.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

    Si se modifica firewalld, se borrarán las cadenas de política de iptable 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 iptables de Cilium en la red host. El Pod anetd agrega las cadenas iptables cuando se inicia. La pérdida de las cadenas iptables de Cilium provoca que el pod en el nodo pierda la conectividad de red fuera del nodo.

    Los cambios en firewalld que quitarán las cadenas iptables incluyen, entre otros:

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

    Solución alternativa

    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 por el nombre del Pod anetd.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

    Direcciones egressSourceIP duplicadas

    Cuando se usa la vista previa de la función de puerta de enlace NAT de salida, se pueden configurar reglas de selección de tráfico que especifiquen una dirección egressSourceIP que ya esté en uso para otro objeto EgressNATPolicy. Esto puede causar conflictos en el enrutamiento del tráfico de salida.


    Solución alternativa

    Coordina con tu equipo de desarrollo para determinar qué direcciones IP flotantes están disponibles antes de especificar la dirección egressSourceIP en tu recurso personalizado EgressNATPolicy.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

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

    Los clústeres de Anthos en Bare Metal configuran el filtrado de rutas de acceso inverso en los nodos para inhabilitar la validación de la fuente (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 inverso se establece con archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). Este valor también puede ser anulado por sysctl, que almacena la configuración de filtro de ruta de acceso inversa en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.


    Solución alternativa

    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 establecer net.ipv4.conf.all.rp_filter en 0. Para reiniciar el pod anetd, usa los siguientes comandos a fin de 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 por el nombre del Pod anetd.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

    Las direcciones IP del clúster de arranque (tipo) y las del nodo del clúster se superponen

    192.168.122.0/24 y 10.96.0.0/27 son los Pods de servicio y Pod predeterminados que usa el clúster de arranque (similares). Las comprobaciones previas fallarán si se superponen con las direcciones IP de la máquina del nodo del clúster.


    Solución alternativa

    Para evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl a fin de especificar valores diferentes.
    Sistema operativo 1.11

    Incompatibilidad con Ubuntu 18.04.6 en el kernel de Google Analytics

    Las versiones 1.11.0 y 1.11.1 de los clústeres de Anthos en equipos físicos no son compatibles con Ubuntu 18.04.6 en el kernel de GA (de 4.15.0-144-generic a 4.15.0-176-generic). La incompatibilidad hace que el agente de red no pueda configurar la red del clúster con un error “BPF program is too large” en los registros anetd. Es posible que veas pods atascados en el estado ContainerCreating con un error networkPlugin cni failed to set up pod en el registro de eventos de los pods. Este problema no se aplica a los kernels de habilitación de hardware de Ubuntu (HWE).


    Solución alternativa

    Te recomendamos que obtengas el kernel de HWE y lo actualices a la versión de HWE compatible más reciente para Ubuntu 18.04.
    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14

    La creación o actualización del clúster falla en CentOS

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


    Solución alternativa
    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14

    Limitaciones del extremo del sistema operativo

    En RHEL y CentOS, hay una limitación a nivel de clúster de 100,000 extremos. Servicio de Kubernetes Si 2 servicios hacen referencia al mismo conjunto de pods, se cuenta como 2 conjuntos separados de extremos. La implementación subyacente de nftable en RHEL y CentOS provoca esta limitación; no es una limitación intrínseca de los clústeres de Anthos en equipos físicos.
    Seguridad 1.10, 1.11, 1.12, 1.13, 1.14

    El contenedor no puede escribir en VOLUME definido en Dockerfile con containerd y SELinux

    Si usas containerd como entorno de ejecución del contenedor y tu sistema operativo tiene SELinux habilitado, es posible que no se pueda escribir en el VOLUME definido en el Dockerfile de la aplicación. Por ejemplo, los contenedores compilados con el siguiente Dockerfile no pueden escribir en la carpeta /tmp.

    
FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp

    Para verificar si este problema te afecta, ejecuta el siguiente comando en el nodo que aloja el contenedor problemático:

    ausearch -m avc

    Si este problema te afecta, verás un error denied como el siguiente:

    
time->Mon Apr  4 21:01:32 2022 type=PROCTITLE
msg=audit(1649106092.768:10979): proctitle="bash"
type=SYSCALL msg=audit(1649106092.768:10979):
arch=c000003e syscall=257 success=no exit=-13
a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0
ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935
key=(null) type=AVC msg=audit(1649106092.768:10979):
avc:  denied { write }
for  pid=76042 comm="bash"
name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:
container_t:s0:c701,c935 tcontext=system_u:object_r:
container_ro_file_t:s0 tclass=dir permissive=0

    Solución alternativa

    Para solucionar el problema, realiza uno de los siguientes cambios:

    • Desactiva SELinux.
    • No uses la función VOLUME dentro del Dockerfile.
    Seguridad 1.10, 1.11, 1.12, 1.13, 1.14

    Errores de SELinux durante la creación de Pods

    A veces, la creación del Pod falla cuando SELinux evita que el entorno de ejecución del contenedor configure etiquetas en las activaciones tmpfs. Esta falla es poco común, pero puede ocurrir cuando SELinux está en modo Enforcing y en algunos kernels.

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

    journalctl -u kubelet

    Si SELinux hace que la creación del pod falle, 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 permiso de la caché de vectores de acceso (AVC) en los registros de auditoría. El avc: denied en la siguiente respuesta de muestra confirma que las fallas de creación del pod 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

    Solución alternativa

    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 una versión posterior, ya que esas versiones corrigieron el error de kernel.
    Restablecimiento/eliminación 1.10, 1.11, 1.12

    Eliminación del espacio de nombres

    Borrar un espacio de nombres evitará que se creen nuevos recursos en ese espacio de nombres, incluidos los trabajos para restablecer máquinas.


    Solución alternativa

    Cuando borras un clúster de usuario, primero debes borrar el objeto de clúster antes de borrar su espacio de nombres. De lo contrario, los trabajos para restablecer las máquinas no se podrán crear, y el proceso de eliminación omitirá el paso de limpieza de la máquina.
    Restablecimiento/eliminación 1.10, 1.11, 1.12, 1.13, 1.14

    servicio de containerd

    El comando bmctl reset no borra los archivos de configuración ni los objetos binarios de containerd. El servicio containerd systemd queda en funcionamiento. El comando borra los contenedores que ejecutan pods programados en el nodo.
    Revisiones y actualizaciones 1.10, 1.11, 1.12

    El detector de problemas de nodo no está habilitado de forma predeterminada después de las actualizaciones del clúster

    Cuando actualizas los clústeres de Anthos en Bare Metal, el detector de problemas de nodos no está habilitado de forma predeterminada. Este problema es aplicable a las actualizaciones de la versión 1.10 a la 1.12.1 y se corrigió en la versión 1.12.2.


    Solución alternativa:

    Para habilitar el detector de problemas de nodo, haz lo siguiente:

    1. Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
      1. Usa el comando SSH y conéctate al nodo.
      2. Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo: 
        systemctl is-active node-problem-detector
         Si el resultado del comando muestra inactive, entonces el node-problem-detector no está en ejecución en el nodo.
    2. Para habilitar el detector de problemas de Node, usa el comando kubectl edit y edita el ConfigMap de node-problem-detector-config. Para obtener más información, consulta Detector de problemas de nodo.
    Operación 1.9 a 1.10

    La copia de seguridad del clúster falla cuando se usa el acceso no raíz

    El comando bmctl backup cluster falla si nodeAccess.loginUser se configura como un nombre de usuario que no es raíz.


    Solución alternativa:

    Este problema se aplica a los clústeres de Anthos en equipos físicos 1.9.x, 1.10.0 y 1.10.1, y se corrigió en la versión 1.10.2 y en versiones posteriores.
    Herramientas de redes 1.10, 1.11, 1.12

    Los servicios del balanceador de cargas no funcionan con contenedores en la red host del plano de control.

    Hay un error en anetd en el que los paquetes se descartan para los servicios de LoadBalancer si los pods de backend se ejecutan en el nodo del plano de control y usan el campo hostNetwork: true en las especificaciones del contenedor.

    El error no está presente en la versión 1.13 o posterior.


    Solución alternativa:

    Las siguientes soluciones alternativas pueden ser útiles si usas un servicio LoadBalancer respaldado por pods hostNetwork:

    1. Ejecútalos en nodos trabajadores (no en los nodos del plano de control).
    2. Usa externalTrafficPolicy: local en las especificaciones del servicio y asegúrate de que las cargas de trabajo se ejecuten en los nodos del balanceador de cargas.
    Revisiones y actualizaciones 1.13

    Los clústeres 1.12 actualizados a la versión 1.11 no se pueden actualizar a la versión 1.13.0

    Los clústeres de la versión 1.12 que se actualizaron de la versión 1.11 no se pueden actualizar a la versión 1.13.0. Este problema de actualización no se aplica a los clústeres que se crearon en la versión 1.12.

    Para determinar si te ves afectado, revisa los registros del trabajo de actualización que contiene la string upgrade-first-no* en el clúster de administrador. Si ves el siguiente mensaje de error, te verás afectado.

    
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...

    Solución alternativa:

    Para solucionar este problema:

    1. Ejecuta los siguientes comandos en la estación de trabajo de administrador: 
      echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. Vuelve a intentar la actualización del clúster.
    Si necesitas asistencia adicional, comunícate con la Asistencia de Google.