Versión 1.10. 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.11, consulta Actualiza Anthos en Bare Metal en la documentación de la versión 1.11.
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:
Actualiza a la versión 1.14.1 o posterior.
Quita los nodos trabajadores y vuelve a agregarlos.
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:
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.
Borra todos los recursos healthchecks.baremetal.cluster.gke.io que se muestran en el paso anterior:
Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de la verificación de estado.
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
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
Para verificar la lista de taints en un nodo, usa el siguiente comando:
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.
Busca pods sin la tolerancia node-role.kubernetes.io/master:NoSchedule:
kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
-o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
--kubeconfig KUBECONFIG_PATH | \
grep -v "node-role.kubernetes.io/master" | uniq
Borra los pods que no tengan la tolerancia node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
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:
Crea una copia de seguridad de todos los recursos personalizados de PodMonitoring existentes.
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:
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:
Ver pasos para solucionarlos
Para borrar artefactos de clúster y restablecer la máquina de nodo, ejecuta el siguiente comando:
bmctl reset -c USER_CLUSTER_NAME
Para iniciar la operación de creación de clústeres, ejecuta el siguiente comando:
La marca --keep-bootstrap-cluster es importante si este comando falla.
Si el comando de creación de clústeres se ejecuta de forma correcta, puedes omitir los pasos restantes. De lo contrario, continúa.
Ejecuta el siguiente comando para obtener la versión del clúster de arranque:
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.10 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
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):
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:
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:
Edita el recurso personalizado VMRuntime:
kubectl edit vmruntime
Establece enabled como false en la especificación:
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:
Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso contenido en el mensaje de registro.
Guarda los cambios y aplícalos al recurso.
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:
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:
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.
Mediante 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 se encuentra 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. 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.
Ejecuta el siguiente comando para borrar el archivo kubeconfig dañado en el clúster de administrador:
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:
Ver pasos para solucionarlos
Actualiza los clústeres de Anthos en Bare Metal a la versión 1.11.0 o posterior.
Si no puedes actualizar los clústeres de inmediato, sigue estos pasos para actualizar la regex de análisis de CRI:
Para evitar que los siguientes cambios se reviertan, reduce la escala de stackdriver-operator:
[PARSER]
# https://rubular.com/r/Vn30bO78GlkvyB
Name cri
Format regex
# The timestamp is described in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex ^(?
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Reinicia los Pods del agente de reenvío de registros:
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)
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:
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"'
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.
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:
En Google Cloud Console, selecciona Monitoring o haz clic en el siguiente botón: Ir a Monitoring
En el panel de navegación, selecciona
Paneles y borra el panel Estado del nodo del clúster de Anthos.
Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel Estado del nodo del clúster de Anthos.
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.
Finaliza todos los Pods stackdriver-log-forwarder:
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):
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.
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:
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:
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:
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
Ver pasos para solucionarlos
Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivo:
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-*
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:
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.
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:
Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
Usa el comando SSH y conéctate al nodo.
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.
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:
Ejecútalos en nodos trabajadores (no en los nodos del plano de control).
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:
Ejecuta los siguientes comandos en la estación de trabajo de administrador:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2023-02-10 (UTC)"],[],[]]
Paneles y borra el panel Estado del nodo del clúster de Anthos.