Versión 1.11. 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.12, consulta Actualiza Anthos en Bare Metal en la documentación de la versión 1.12.
En esta página, se enumeran todos los problemas conocidos de los clústeres de Anthos alojados en Bare Metal. Para filtrar los problemas conocidos por categoría o versión de producto, selecciona los filtros que desees en los siguientes menús desplegables.
Selecciona tus versiones de clústeres de Anthos alojados en Bare Metal:
Selecciona la categoría del problema:
También puedes buscar el problema:
Categoría
Versiones identificadas
Problema y solución alternativa
Herramientas de redes
1.15.0-1.15.2
No se reconoció el CoreDNS orderPolicy
OrderPolicy no se reconoce como parámetro y no se usa. En cambio, los clústeres de Anthos alojados en Bare Metal siempre usan Random.
Este problema ocurre porque la plantilla de CoreDNS no se actualizó, lo que hace que se ignore orderPolicy.
Solución alternativa:
Actualiza la plantilla de CoreDNS y aplica la corrección. Esta corrección persiste hasta
que se realice una actualización.
Edite la plantilla existente:
kubectleditcm-nkube-systemcoredns-template
Reemplaza el contenido de la plantilla por lo siguiente:
Componentes de la puerta de enlace de red de Anthos expulsados o pendientes debido a que falta una clase de prioridad
Los Pods de la puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted, como se muestra en el siguiente resultado condensado de ejemplo:
Estos errores indican eventos de expulsión o una incapacidad para programar Pods debido a los recursos de nodos. Dado que los Pods de la puerta de enlace de red de Anthos no tienen
PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo.
Cuando los nodos tienen restricciones de recursos, los Pods de la puerta de enlace de la red pueden expulsarse. Este comportamiento es especialmente inadecuado para el DaemonSet de ang-node, ya que esos Pods deben estar programados en un nodo específico y no se pueden migrar.
Solución alternativa:
Actualiza a la versión 1.15 o posterior.
Como solución a corto plazo, puedes asignar una PriorityClass de forma manual a los componentes de la puerta de enlace de Anthos Network. El controlador de clústeres de Anthos alojados en Bare Metal reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.
Asigna la clase system-cluster-critical PriorityClass a los objetos Deployment del controlador de clústeres ang-controller-manager y autoscaler.
Asigna la Prioridad system-node-critical al DaemonSet de nodo ang-daemon.
Instalación, actualizaciones y actualizaciones
1.15.0, 1.15.1, 1.15.2
No se pueden crear ni actualizar clústeres debido a la longitud del nombre del clúster
La creación de los clústeres de las versiones 1.15.0, 1.15.1 o 1.15.2, o su actualización a las versiones 1.15.0, 1.15.1 o 1.15.2 falla cuando el nombre del clúster tiene más de 48 caracteres (versión 1.15.0) o 45 caracteres (versión 1.11.1 o 1). Durante las operaciones de creación y actualización de clústeres, los clústeres de Anthos alojados en Bare Metal crean un recurso de verificación de estado con un nombre que incorpora el nombre y la versión del clúster:
Para los clústeres de la versión 1.15.0, el nombre del recurso de la verificación de estado es CLUSTER_NAME-add-ons-CLUSTER_VER.
Para los clústeres de las versiones 1.15.1 o 1.15.2, el nombre del recurso de la verificación de estado es CLUSTER_NAME-kubernetes-CLUSTER_VER.
Para desbloquear la creación o actualización del clúster, puedes omitir la
verificación de estado. Usa el siguiente comando para aplicar un parche al recurso personalizado de la verificación de estado con el estado “pass”: (status: {pass: true})
Los clústeres de las versiones 1.14.0 y 1.14.1 con funciones de vista previa no se pueden actualizar a la versión 1.15.x
Si los clústeres de las versiones 1.14.0 y 1.14.1 tienen habilitada una función de vista previa, se bloquea la actualización correcta a la versión 1.15.x. Esto se aplica a las funciones de vista previa, como la capacidad de crear un clúster sin kube-proxy, que está habilitada con la siguiente anotación en el archivo de configuración del clúster:
Este problema se solucionó en los clústeres de Anthos en la versión 1.14.2 y posteriores de Bare Metal.
Solución alternativa:
Si no puedes actualizar tus clústeres a la versión 1.14.2 o superior
antes de actualizar a la versión 1.15.x, puedes actualizarla a la versión 1.15.x
directamente mediante un clúster de arranque:
bmctlupgradecluster--use-bootstrap=true
Operación
1.15
Los clústeres de la versión 1.15 no aceptan direcciones IP flotantes duplicadas.
La puerta de enlace de red de Anthos no te permite crear nuevos recursos personalizados de NetworkGatewayGroup que contengan direcciones IP en spec.floatingIPs que ya se usen en los recursos personalizados de NetworkGatewayGroup existentes. Un webhook de Anthos aplica de manera forzosa esta regla en los clústeres de Bare Metal
1.15.0 y versiones posteriores. Las direcciones IP flotantes duplicadas preexistentes no generan errores. El webhook solo impide la creación de nuevos recursos personalizados de NetworkGatewayGroups que contengan direcciones IP duplicadas.
El mensaje de error de webhook identifica la dirección IP en conflicto y el recurso personalizado existente que ya la usa:
IPaddressexistsinothergatewaywithnamedefault
En la documentación inicial para las funciones de red avanzadas, como la puerta de enlace de salida de NAT, no se advierten las direcciones IP duplicadas.
Inicialmente, el conciliador reconoció solo el recurso NetworkGatewayGroup llamado default. La puerta de enlace de red de Anthos ahora reconoce todos los recursos personalizados de NetworkGatewayGroup en el espacio de nombres del sistema. Se respetan los recursos personalizados
NetworkGatewayGroup existentes, tal como están.
Solución alternativa:
Solo se producen errores cuando se crea un nuevo recurso personalizado NetworkGatewayGroup.
Para solucionar el error, haz lo siguiente:
Usa el siguiente comando para enumerar NetworkGatewayGroups recursos personalizados:
Para aplicar los cambios, cierra y guarda los recursos personalizados editados.
Entorno de ejecución de VM de Anthos
1.13.7
Es posible que las VM no se inicien en clústeres 1.13.7 que usen un registro privado.
Cuando habilitas Anthos VM Runtime en un clúster de la versión 1.13.7 nuevo o actualizado que usa un registro privado, es posible que las VM que se conectan a la red del nodo o usen una GPU no se inicien de forma correcta. Este problema se debe a que algunos Pods del sistema en el espacio de nombres vm-system obtienen errores de extracción de imagen. Por ejemplo, si tu VM usa la red de nodos, algunos Pods pueden informar errores de extracción de imágenes como los siguientes:
macvtap-4x9zp0/1Init:ImagePullBackOff070m
Este problema se solucionó en los clústeres de Anthos en la versión 1.14.0 y posteriores de Bare Metal.
Solución alternativa
Si no puedes actualizar tus clústeres de inmediato, puedes extraer imágenes de forma manual. Los siguientes comandos obtienen la imagen del complemento de CNI de macvtap para tu VM y la envían a tu registro privado:
Reemplaza REG_HOST por el nombre de dominio de un host que duplicas de forma local.
Instalación
1.11, 1.12
Durante la creación del clúster en el clúster de tipo, el Pod de gke-metric-agent no puede iniciarse.
Durante la creación del clúster en el clúster de tipo, el Pod de gke-metrics-agent no se inicia debido a un error de extracción de imagen de la siguiente manera:
error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Además, en el registro containerd del clúster de arranque, verás la siguiente entrada:
Sep1323:54:20bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:20.378172743Z"level=infomsg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" "Sep1323:54:21bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:21.057247258Z"level=errormsg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed"error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Verá el siguiente error “failing pull” en el Pod:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Solución alternativa
A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el
propósito del Pod de gke-metrics-agent en el clúster de similares es facilitar la
tasa de éxito de la creación del clúster y el seguimiento y la supervisión internos.
Por lo tanto, puedes ignorar este error.
Solución alternativa
A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el
propósito del Pod de gke-metrics-agent en el clúster de similares es facilitar la
tasa de éxito de la creación del clúster y el seguimiento y la supervisión internos.
Por lo tanto, puedes ignorar este error.
Operación, Herramientas de redes
1.12, 1.13, 1.14, 1.15
El acceso a un extremo del servicio de IPv6 falla el nodo LoadBalancer en
CentOS o RHEL
Cuando accedes a un servicio de pila doble (un servicio que tiene extremos IPv4 e IPv6) y usas el extremo IPv6, el nodo LoadBalancer que entrega el servicio puede fallar. Este problema afecta a los clientes que usan servicios de pila doble con CentOS o RHEL y a la versión de kernel anterior a kernel-4.18.0-372.46.1.el8_6.
Si crees que este problema te afecta, verifica la versión de kernel en el nodo LoadBalancer con el comando uname -a.
Solución alternativa:
Actualiza el nodo LoadBalancer a la versión kernel-4.18.0-372.46.1.el8_6 del kernel o una posterior. Esta versión de kernel está disponible de forma predeterminada en CentOS, RHEL 8.6 y versiones posteriores.
Herramientas de redes
1.11, 1.12, 1.13, 1.14.0
Problemas de conectividad intermitente después de reiniciar el nodo
Después de reiniciar un nodo, es posible que veas problemas de conectividad intermitentes para un servicio NodePort o LoadBalancer. Por ejemplo, es posible que tengas un protocolo de enlace TLS intermitente o errores de restablecimiento de la conexión. Este problema se solucionó para los clústeres de Anthos en las versiones 1.14.1 y posteriores de Bare Metal.
Para verificar si este problema te afecta, observa las reglas de reenvío de iptables en los nodos en los que se ejecuta el Pod de backend para el Service afectado:
sudoiptables-LFORWARD
Si ves la regla KUBE-FORWARD antes de la regla CILIUM_FORWARD en iptables, es posible que este problema te afecte. En el siguiente resultado de ejemplo, se muestra un nodo en el que existe el problema:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Solución alternativa:
Reinicie el anetd Pod en el nodo con una configuración incorrecta. Después de reiniciar el Pod anetd, la regla de reenvío en iptables debe configurarse de forma correcta.
En el siguiente resultado de ejemplo, se muestra que la regla CILIUM_FORWARD ahora está configurada de forma correcta antes de la regla KUBE-FORWARD:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Revisiones y actualizaciones
1.9, 1.10
La función de vista previa no conserva el permiso original ni la información del propietario
La función de vista previa del clúster 1.9.x que usa bmctl 1.9.x no conserva el permiso original ni la información del propietario. Para verificar si esta función te afecta, extrae el archivo con copia de seguridad con el siguiente comando:
tar-xzvfBACKUP_FILE
Solución alternativa
Verifica si metadata.json está presente y si bmctlVersion es 1.9.x. Si metadata.json no está presente, actualiza al clúster a la versión 1.10.x y usa bmctl 1.10.x para crear una copia de seguridad o restablecer.
Actualizaciones y creaciones
1.14.2
clientconfig-operator se detuvo en un estado pendiente con CreateContainerConfigError
Si actualizaste a un clúster de la versión 1.14.2 o lo creaste con una configuración de OIDC/LDAP, es posible que veas el Pod clientconfig-operator atascado en estado pendiente. Con este problema, hay dos Pods clientconfig-operator, uno en estado de ejecución y el otro en estado pendiente.
Este problema se aplica solo a los clústeres de Anthos en la versión 1.14.2 de Bare Metal. Las versiones anteriores, como 1.14.0 y 1.14.1, no se ven afectadas. Este problema se solucionó en la versión 1.14.3 y en todas las versiones posteriores, incluida la 1.15.0 y posteriores.
Solución alternativa:
Como solución alternativa, puedes aplicar un parche a la implementación clientconfig-operator para agregar contexto de seguridad adicional y asegurarte de que la implementación esté lista.
Usa el siguiente comando para aplicar un parche a clientconfig-operator en el clúster de destino:
CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de destino.
Operación
1.11, 1.12, 1.13, 1.14, 1.15
La rotación de la autoridad certificadora falla en los clústeres sin balanceo de cargas en paquetes
Para los clústeres sin balanceo de cargas en paquetes (spec.loadBalancer.mode configurado como manual), el comando bmctl update credentials certificate-authorities rotate puede dejar de responder y fallar con el siguiente error: x509: certificate signed by unknown authority.
Si este problema te afecta, es posible que el comando bmctl muestre el siguiente mensaje antes de dejar de responder:
SigningCAcompletedin3/0control-planenodes
En este caso, el comando falla con el tiempo. El registro de autoridad certificadora para un clúster con tres planos de control puede incluir entradas como las siguientes:
ipam-controller-manager bucles de falla en los clústeres de doble pila
Cuando implementas un clúster de pila doble (un clúster con direcciones IPv4 y, también, IPv6), es posible que los Pods ipam-controller-manager fallen. Este comportamiento hace que los nodos circulen entre los estados Ready y NotReady, y puede hacer que la instalación del clúster falle. Este problema puede ocurrir cuando el servidor de la API tiene una carga alta.
Para ver si este problema te afecta, verifica si los Pods de ipam-controller-manager fallan con errores CrashLoopBackOff:
Los clústeres que ejecutan la versión 3.4.13 o versiones anteriores de etcd pueden experimentar escasez de relojes y relojes de recursos no operativos, lo que puede generar los siguientes problemas:
Se interrumpió la programación del Pod
No se pueden registrar los nodos
kubelet no observa cambios en el Pod
Estos problemas pueden hacer que el clúster no funcione.
Este problema se solucionó en los clústeres de Anthos en las versiones 1.12.9, 1.13.6, 1.14.3 y posteriores de Anthos Bare Metal. Estas versiones más recientes utilizan la versión 3.4.21 de etcd. Este problema afecta a todas las versiones anteriores de clústeres de Anthos alojados en Bare Metal.
Solución alternativa
Si no puedes actualizar de inmediato, puedes mitigar el riesgo de que el clúster falle mediante la reducción de la cantidad de nodos en el clúster. Quita los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MBps.
Para ver esta métrica en el Explorador de métricas, sigue estos pasos:
Ve al Explorador de métricas en la consola de Google Cloud:
Expande la opción Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, usa los submenús para seleccionarla:
En el menú Recursos activos, selecciona Contenedor de Kubernetes.
En el menú Categorías de métricas activas, selecciona Anthos.
En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
Haga clic en Aplicar.
Herramientas de redes
1.11.6, 1.12.3
Estado "Fallido" del modo vfio-pci del operador SR-IOV
El syncStatus del objeto SriovNetworkNodeState puede informar el valor “Con errores” para un nodo configurado. Para ver el estado de un nodo y determinar si el problema te afecta, ejecuta el siguiente comando:
Reemplaza NODE_NAME por el nombre del nodo que deseas verificar.
Solución alternativa:
Si el estado del objeto SriovNetworkNodeState es “Con errores”, actualiza a los clústeres de Anthos en la versión 1.11.7 o posterior de Anthos o a la versión 1.12.4 o posterior.
Revisiones y actualizaciones
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
Algunos nodos trabajadores no tienen el estado Listo después de la actualización
Una vez finalizada la actualización, es posible que algunos nodos trabajadores tengan su condición Listo configurada en false. En el recurso Node, verá un error junto a la condición "Ready" similar al siguiente:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Cuando accedes a la máquina detenida, la configuración de la CNI en la máquina está vacía:
sudols/etc/cni/net.d/
Solución alternativa
Para reiniciar el Pod anetd del nodo, bórralo.
Actualizaciones y actualizaciones, seguridad
1.10
Varias rotaciones de certificados de cert-manager generan inconsistencias
Después de varias rotaciones manuales o automáticas de certificados, el Pod de webhook, como anthos-cluster-operator, no se actualiza con los certificados nuevos emitidos por cert-manager. Cualquier actualización del recurso personalizado del clúster falla y genera un error similar al siguiente:
Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Este problema puede ocurrir en las siguientes circunstancias:
Si realizaste dos rotaciones de certificados manuales emitidas por cert en un clúster de más de 180 días o más, y nunca reiniciaste el anthos-cluster-operator.
Si realizaste una rotación manual de certificados con cert-manager en un clúster de más de 90 días o más, y nunca reiniciaste el operador de anthos-cluster.
Solución alternativa
Reinicia el Pod finalizando el anthos-cluster-operator.
Revisiones y actualizaciones
1.14.0
Pods de implementador del controlador del ciclo de vida desactualizados creados durante la actualización del clúster de usuario
En la versión 1.14.0, se pueden crear uno o más Pods obsoletos
para el controlador del ciclo de vida durante las actualizaciones del clúster de usuario.
Este problema se aplica a los clústeres de usuario que se crearon inicialmente en versiones anteriores a la 1.12. Los Pods creados de forma no intencional impiden las operaciones de actualización, pero es posible que se encuentren en un estado anormal. Te recomendamos que quites los Pods desactualizados.
Este problema se corrigió en la versión 1.14.1.
Solución alternativa:
Para quitar los Pods obsoletos del implementador del controlador del ciclo de vida, haz lo siguiente:
El estado BGPSession cambia constantemente debido a la gran cantidad de rutas entrantes
Los clústeres de Anthos alojados en Bare Metal Advanced no pueden administrar las sesiones de BGP correctamente
cuando los pares externos promocionan una gran cantidad de rutas (aproximadamente 100
o más). Con una gran cantidad de rutas entrantes, el controlador de BGP local del nodo tarda demasiado en conciliar sesiones de BGP y no puede actualizar el estado. La falta de actualizaciones de estado, o una verificación de estado, hace que la sesión se borre por estar inactiva.
Entre los comportamientos no deseados de las sesiones de BGP que podrías observar o que indiques que hay un problema, se incluyen los siguientes:
Eliminación y recreación continuas de bgpsession
bgpsession.status.state nunca se convierte en Established.
Rutas que no se anuncian o se retiran y anuncian de forma reiterada.
Los problemas de balanceo de cargas de BGP pueden notarse con problemas de conectividad en los servicios de LoadBalancer.
Es posible que el problema de BGP FlatIP sea notorio con problemas de conectividad con los Pods.
Para determinar si los problemas de BGP se deben a que los pares remotos
anuncian demasiadas rutas, usa los siguientes comandos para revisar los
estados y los resultados asociados:
Usa kubectl get bgpsessions en el clúster afectado.
El resultado muestra bgpsessions con el estado "Not Established" (No establecido) y el último tiempo del informe cuenta de manera continua hasta 10-12 segundos antes de que parezca restablecerse a cero.
El resultado de kubectl get bgpsessions muestra que las sesiones afectadas se vuelven a crear de forma repetida:
Los mensajes de registro indican que se están borrando las sesiones de BGP inactivas:
kubectllogsang-controller-manager-POD_NUMBER
Reemplaza POD_NUMBER por el Pod líder en el clúster.
Solución alternativa:
Reduce o borra la cantidad de rutas anunciadas desde el intercambio de tráfico
remoto al clúster con una política de exportación.
En los clústeres de Anthos alojados en Bare Metal versión 1.14.2 y posteriores, también puedes inhabilitar la
función que procesa las rutas recibidas mediante un
AddOnConfiguration. Agrega el argumento --disable-received-routes al contenedor bgpd del daemonset de ang-daemon.
Herramientas de redes
1.14, 1.15
Tiempos de espera de la aplicación causados por fallas de la inserción de la tabla de conntrack
Los clústeres que se ejecutan en un SO Ubuntu que usa el kernel 5.15 o superior son susceptibles a fallas de inserción de la tabla de seguimiento de conexión (conntrack) de netfilter. Los errores de inserción pueden ocurrir incluso cuando la tabla de conntrack tiene espacio para entradas nuevas. Las fallas se producen por cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas en función de la longitud de la cadena.
Para ver si este problema te afecta, puedes verificar las estadísticas del sistema de seguimiento de conexiones en el kernel con el siguiente comando:
sudoconntrack-S
La respuesta es similar a la que se muestra a continuación:
Si un valor de chaintoolong en la respuesta es un número distinto de cero, este problema te afecta.
Solución alternativa
La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets) y la tabla de seguimiento de conexión de netfilter (nf_conntrack_max). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas:
Reemplaza TABLE_SIZE por el tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos en el nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.
No se pueden restablecer las copias de seguridad del clúster con bmctl para algunas versiones
Te recomendamos que crees una copia de seguridad de los clústeres antes de realizar la actualización, de modo que puedas restablecer la versión anterior si la actualización no se realiza de forma correcta.
Un problema con el comando bmctl restore cluster hace que no pueda restablecer las copias de seguridad de los clústeres con las versiones identificadas. Este problema es específico de las actualizaciones, en las que restableces una copia de seguridad de una versión anterior.
Si tu clúster se ve afectado, el registro bmctl restore cluster contiene el siguiente error:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Solución alternativa:
Hasta que se corrija este problema, te recomendamos que uses las instrucciones que aparecen en Cómo crear una copia de seguridad y restablecer clústeres para crear una copia de seguridad de tus clústeres y restablecerlos de forma manual, si es necesario.
Herramientas de redes
1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2
NetworkGatewayGroup falla si no hay una dirección IP en la interfaz.
NetworkGatewayGroup no puede crear daemons para los nodos que no tienen interfaces IPv4 e IPv6. Esto hace que fallen funciones como
el balanceador de cargas de BGP y la salida de NAT. Si verificas los registros del Pod ang-node con errores en el espacio de nombres kube-system, se muestran errores similares al siguiente ejemplo cuando falta una dirección IPv6:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
En el ejemplo anterior, no hay una dirección IPv6 en la interfaz ens192. Se muestran errores de ARP similares si al nodo le falta una dirección IPv4.
NetworkGatewayGroup intenta establecer una conexión ARP y una conexión NDP a la dirección IP de vínculo local. Si la dirección IP no existe (IPv4 para ARP, IPv6 para NDP), falla la conexión y el daemon no continúa.
Este problema se corrigió en la versión 1.14.3.
Solución alternativa:
Conéctate al nodo mediante SSH y agrega una dirección IPv4 o IPv6 al
vínculo que contiene la IP del nodo. En la entrada de registro del ejemplo anterior, esta interfaz era ens192:
ipaddressadddevINTERFACEscopelinkADDRESS
Reemplaza lo siguiente:
INTERFACE: Es la interfaz para tu nodo, como ens192.
ADDRESS: Es la dirección IP y la máscara de subred que se aplicarán a la interfaz.
Restablecimiento/eliminación
1.10, 1.11, 1.12, 1.13.0-1.13.2
anthos-cluster-operator bucle de falla cuando se quita un
nodo del plano de control
Cuando intentas quitar un nodo del plano de control quitando la dirección IP de Cluster.Spec, anthos-cluster-operator entra en un estado de bucle de falla que bloquea cualquier otra operación.
Solución alternativa:
El problema se corrigió en las versiones 1.13.3, 1.14.0 y posteriores. Afecta a todas las demás versiones. Actualiza a una de las versiones corregidas
Como solución alternativa, ejecuta el siguiente comando:
IP_ADDRESS: la dirección IP del nodo en estado de bucle de falla.
CLUSTER_NAMESPACE: El espacio de nombres del clúster.
Instalación
1.13.1, 1.13.2 y 1.13.3
kubeadm join falla en clústeres grandes debido a una discrepancia de
token
Cuando instalas clústeres de Anthos alojados en Bare Metal con una gran cantidad de nodos, es posible que veas un mensaje de error kubeadmin join similar al siguiente ejemplo:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Solución alternativa:
Este problema se resuelve en los clústeres de Anthos en la versión 1.13.4 y posteriores de Bare Metal.
Si necesitas usar una versión afectada, primero crea un clúster con menos de 20 nodos y, luego, cambia el tamaño del clúster para agregar nodos adicionales después de que se complete la instalación.
Registro y supervisión
1.10, 1.11, 1.12, 1.13.0
Límite de CPU bajo para metrics-server en clústeres de Edge
En los clústeres de Anthos alojados en Edge de Bare Metal, los límites bajos de CPU para
metrics-server pueden causar reinicios frecuentes de
metrics-server. El ajuste de escala automático horizontal de Pods (HPA) no funciona
debido a que metrics-server está en mal estado.
Si el límite de CPU de metrics-server es inferior a 40m,
tus clústeres pueden verse afectados. Para verificar los límites de CPU de metrics-server, revisa uno de los siguientes archivos:
Clústeres de Anthos alojados en Bare Metal versión 1.x-1.12:
Este problema se resuelve en los clústeres de Anthos en la versión 1.13.1 o posterior de Bare Metal. Para
solucionar este problema, actualiza los clústeres.
Una solución a corto plazo hasta que puedas actualizar los clústeres es aumentar
de forma manual los límites de CPU para metrics-server de la siguiente manera:
Reduce verticalmente la escala de metrics-server-operator:
Quita la línea --config-dir=/etc/config y aumenta los límites de CPU, como se muestra en el siguiente ejemplo:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true>
Guarda y cierra metrics-server para aplicar los cambios.
Herramientas de redes
1.14, 1.15
No funciona la conexión directa de NodePort al Pod de hostNetwork
La conexión a un Pod habilitado con hostNetwork a través del Service NodePort falla cuando el Pod de backend se encuentra en el mismo nodo que el NodePort objetivo. Este problema afecta a los objetos Service LoadBalancer cuando se usan con Pods alojados en hostNetwork. Con varios backends, puede haber una falla de conexión esporádica.
Este problema se debe a un error en el programa de eBPF.
Solución alternativa:
Cuando uses un Service de Nodeport, no orientes al nodo en el que se ejecuta el Pod de backend. Cuando uses el Service LoadBalancer, asegúrate de que los Pods de hostNetworked no se ejecuten en los nodos LoadBalancer.
Revisiones y actualizaciones
1.12.3, 1.13.0
Los clústeres de administrador de la versión 1.13.0 no pueden administrar los clústeres de usuario 1.12.3.
Los clústeres de administrador que ejecutan la versión 1.13.0 no pueden administrar los clústeres de usuario que ejecutan la versión 1.12.3. Las operaciones en un clúster de usuario de la versión 1.12.3 fallan.
Solución alternativa:
Actualiza el clúster de administrador a la versión 1.13.1 o actualízalo a la misma versión que el clúster de administrador.
Revisiones y actualizaciones
1.12
La actualización a la versión 1.13.x está bloqueada para los clústeres de administrador con grupos de nodo trabajador.
La versión 1.13.0 y las superiores no pueden contener grupos de nodo trabajador.
Las actualizaciones a la versión 1.13.0 o superior para los clústeres de administrador con grupos de nodo trabajadors están bloqueadas. Si la actualización del clúster de administrador está detenida, puedes confirmar el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace para confirmar si son los grupos de nodo trabajador:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Solución alternativa:
Antes de actualizar, mueve todos los grupos de nodo trabajador a los clústeres de usuario. Si deseas obtener instrucciones para agregar y quitar grupos de nodos, consulta Administra grupos de nodos en un clúster.
Revisiones y actualizaciones
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Errores en la actualización de recursos con kubectl apply
Si actualizas recursos existentes, como los recursos personalizados ClientConfig o Stackdriver con kubectl apply, el controlador podría mostrar un error o revertir la entrada y los cambios deseados.
Por ejemplo, puedes intentar editar el recurso personalizado Stackdriver de la siguiente manera. Para ello, primero debes obtener el recurso y, luego, aplicar una versión actualizada.
Habilita funciones o actualiza la configuración en el archivo YAML.
Vuelva a aplicar el archivo YAML actualizado:
kubectlapply-fstackdriver.yaml
El último paso para kubectl apply es cuando tengas problemas.
Solución alternativa:
No uses kubectl apply para hacer cambios en los recursos existentes. En su lugar, usa kubectl edit o kubectl patch como se muestra en los siguientes ejemplos:
Edita el recurso personalizado Stackdriver:
kubectleditstackdriver-nkube-systemstackdriver
Habilita funciones o actualiza la configuración en el archivo YAML.
Los fragmentos dañados de tareas pendientes causan un bucle de fallas de stackdriver-log-forwarder
El bucle de fallas stackdriver-log-forwarder si intenta procesar un fragmento de trabajo pendiente dañado Los siguientes errores de ejemplo se muestran en los registros del contenedor:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Cuando se produce este bloqueo, no puedes ver los registros en Cloud Logging.
Solución alternativa:
Para resolver estos errores, completa los siguientes pasos:
Identifica los fragmentos de trabajos pendientes dañados. Revisa los siguientes mensajes de error de ejemplo:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
En este ejemplo, se produce un error en el archivo tail.1/1-1659339894.252926599.flb almacenado en var/log/fluent-bit-buffers/tail.1/. Se deben quitar todos los archivos *.flb con una verificación de formato con errores.
Finaliza los Pods en ejecución para stackdriver-log-forwarder:
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.
Verifica que se borren los Pods de stackdriver-log-forwarder antes de continuar con el siguiente paso.
Conéctate al nodo mediante SSH, en el que se ejecuta stackdriver-log-forwarder.
En el nodo, borra todos los archivos *.flb dañados de var/log/fluent-bit-buffers/tail.1/.
Si hay demasiados archivos dañados y quieres aplicar una secuencia de comandos para limpiar todos los fragmentos de tareas pendientes, usa las siguientes secuencias de comandos:
Implementa un DaemonSet para limpiar todos los datos sucios de los búferes de fluent-bit:
Asegúrate de que el DaemonSet haya limpiado todos los nodos. El resultado de los siguientes dos comandos debe ser igual al número de nodos del clúster:
Herramientas de redes, entorno de ejecución de VM de Anthos
1.14.0
Reiniciar Dataplane V2 (anetd) en clústeres puede provocar
que las VMs existentes no se puedan conectar a una red que no sea un Pod
En clústeres de varias NIC, reiniciar Dataplane V2 (anetd) puede provocar que las máquinas virtuales no se puedan conectar a las redes. Es posible que se observe un error similar al siguiente en los registros del Pod anetd:
could not find an allocator to allocate the IP of the multi-nic endpoint
Solución alternativa:
Puedes reiniciar la VM como una solución rápida. Para evitar que se repita el problema, actualiza a los clústeres de Anthos alojados en Bare Metal 1.14.1 o versiones posteriores.
Operación
1.13, 1.14.0, 1.14.1
gke-metrics-agent no tiene límite de memoria en los clústeres de perfil de Edge
Según la carga de trabajo del clúster, el gke-metrics-agent podría usar más de 4,608 MiB de memoria. Este problema solo afecta a los clústeres de Anthos en los clústeres de perfiles perimetrales de Bare Metal. Los clústeres de perfil predeterminados no se verán afectados.
Solución alternativa:
Actualiza el clúster a la versión 1.14.2 o posterior.
Instalación
1.12 a 1.13
La creación del clúster puede fallar debido a condiciones de carrera
Cuando creas clústeres con kubectl, debido a las condiciones de carrera, la verificación previa podría no finalizar. Como resultado, la creación del clúster puede fallar en ciertos casos.
El conciliador de verificación previa crea un SecretForwarder para copiar el secreto ssh-key predeterminado en el espacio de nombres de destino.
Por lo general, la verificación previa aprovecha las referencias del propietario y se concilia una vez que se completa el SecretForwarder. Sin embargo, en casos excepcionales, el propietario de las referencias de SecretForwarder puede perder la referencia a la verificación previa, lo que provoca que la verificación previa se detenga. Como resultado, la creación del clúster falla. Para continuar con la conciliación de la verificación previa controlada por el controlador, borra el Pod del operador de clúster o el recurso de verificación previa. Cuando
borras el recurso de comprobación previa, se crea otro y continúa
la conciliación. De forma alternativa, puedes actualizar los clústeres existentes
(que se crearon con una versión anterior) a una versión fija.
Herramientas de redes
1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Las direcciones IP reservadas no se liberan cuando se usa el complemento de ubicaciones con la función de varias NIC
En la función de varios NIC, si usas el complemento de ubicación de CNI y usas la operación CNI DEL para borrar una interfaz de red de un Pod, es posible que algunas direcciones IP reservadas no se liberen correctamente. Esto sucede cuando se interrumpe la operación de CNI DEL.
Para verificar las reservas de direcciones IP
no utilizadas de los Pods, ejecuta el siguiente comando:
kubectlgetippools-A--kubeconfigKUBECONFIG_PATH
Solución:
Borra de forma manual las direcciones IP (grupos) que no se usan.
Instalación
1.10, 1.11.0, 1.11.1, 1.11.2
El detector de problemas de nodos falla en el clúster de usuario 1.10.4
El detector de problemas de nodos puede fallar en los clústeres de Anthos alojados en clústeres de usuario de Bare Metal 1.10.x, cuando los clústeres de Anthos alojados en Bare Metal 1.11.0, 1.11.1 o 1.11.2 administran clústeres de usuario 1.10.x. Cuando falla el detector de problemas de nodos, el registro se actualiza con el siguiente mensaje de error:
Actualiza el clúster de administrador a la versión 1.11.3 para resolver el problema.
Operación
1.14
Los nodos del clúster de IPv4 en modo isla 1.14 tienen un tamaño de máscara CIDR de Pod de 24
En la versión 1.14, el parámetro de configuración maxPodsPerNode no se tiene en cuenta para los clústeres en modo isla, por lo que a los nodos se les asigna un tamaño de máscara CIDR de Pod de 24 (256 direcciones IP).Esto podría provocar que el clúster se quede sin direcciones IP antes de lo esperado. Por ejemplo, si tu clúster tiene una máscara de CIDR de Pod de 22, a cada nodo se le asignará una máscara de 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 Pods 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 disponible:
error="required IPv4 PodCIDR not available"
Solución alternativa
Sigue estos pasos para resolver el problema:
Actualiza a la versión 1.14.1 o una 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
No se pudo revertir la actualización del clúster
Una reversión de actualización puede fallar en los clústeres de Anthos alojados en Bare Metal 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:
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:
Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de 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 mediante 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 con 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 no finaliza nunca.
Solución alternativa:
Actualiza a la versión 1.13.1 antes de actualizar a 1.14.x. Una actualización in situ de 1.13.0 a 1.13.1 debería funcionar. 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 de instancia principal.
Los nodos del plano de control requieren uno de dos taints específicos para evitar que se programen
Pods de carga de trabajo en ellos. Cuando actualizas la versión 1.13 de 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 genera 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 cargas de trabajo pueden abrumar los nodos del plano de control y generar inestabilidad
del clúster.
Determine si el problema lo afecta
Busca los nodos del plano de control con el siguiente comando:
Si no aparece ninguno de los taints obligatorios, se verá 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.
La creación de una VM falla de forma intermitente con errores de carga
La creación de una máquina virtual (VM) nueva con el comando kubectl virt create vm falla con poca frecuencia durante la carga de la imagen. Este problema se aplica a las VM de Linux y de Windows. El error es similar al siguiente ejemplo:
Vuelve a intentar el comando kubectl virt create vm para crear tu VM.
Actualizaciones y registros, registro 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 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 Anthos versión 1.11, los recursos asociados no se conservan cuando actualizas 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 los componentes de Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionadas 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 los componentes del servicio administrado para 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 colecciones administrados de forma manual, haz lo siguiente:
Crear una copia de seguridad de todos los recursos personalizados existentes de PodMonitoring.
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 del contenedor de Docker le falta la siguiente anotación, no se puede actualizar a la versión 1.13:
Es más probable que esto 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 actualiza 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 este problema te afecta, actualiza el recurso del clúster con la anotación faltante. 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 alojados en la versión 1.11.0
de Bare Metal (este problema se solucionó en los clústeres de Anthos en la versión 1.11.1 de Bare Metal). En algunos casos, el comando bmctl create cluster sale antes y escribe errores como los siguientes en los registros:
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 alternativos
Para borrar artefactos de clúster y restablecer la máquina de nodos, ejecuta el siguiente comando:
bmctlreset-cUSER_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 funciona correctamente, puedes omitir los pasos restantes. De lo contrario, continúa.
Ejecuta el siguiente comando para obtener la versión del clúster de arranque:
Para borrar el clúster, ejecuta el siguiente comando:
bmctlresetbootstrap
Instalación, entorno de ejecución de VM de Anthos
1.11, 1.12
Error de conciliación del informe de instalación de entorno de ejecución de VM
La operación de creación de clústeres puede informar un error similar al
siguiente:
I042301:17:20.8956403935589logs.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 del clúster 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 los clústeres de Anthos alojados en Bare Metal versión 1.11).
El clúster está configurado a fin de proporcionar varias interfaces de red, 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. Es posible que veas 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 CIDR de 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
Error en sistemas con el parámetro de configuración umask restrictivo
La versión 1.10.0 de los clústeres de Anthos alojados en Bare Metal presenta una función
del plano de control sin permisos de administrador que ejecuta todos los componentes del plano de control como un usuario
no raíz. Ejecutar todos los componentes como un usuario no raíz puede causar fallas en la instalación o la actualización de los sistemas con un parámetro de configuración umask más restrictivo de 0077.
Solución alternativa
Restablece los nodos del plano de control y cambia el parámetro de configuración umask a 0022 en todas las máquinas del plano de control. Una vez actualizadas las máquinas, vuelve a intentar la instalación.
Como alternativa, puedes cambiar los permisos del directorio y del archivo de
/etc/kubernetes en las máquinas del plano de control para que la
instalación o actualización continúe.
Haz que /etc/kubernetes y todos sus subdirectorios sean legibles por el mundo: chmod o+rx.
Haz que todos los archivos del usuario root en el directorio /etc/kubernetes de manera recurrente sean legibles por el mundo (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 en todo el mundo.
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 alojados en Bare Metal. Sin embargo, la versión 1.14 es compatible con cgroup v2 como una función de 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 alojados en Bare Metal.
Instalación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Verificaciones de comprobación previa y credenciales de cuentas de servicio
Para las instalaciones activadas por clústeres híbridos o de administrador (en otras palabras, clústeres no creados con bmctl, como clústeres de 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, 1.15
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 cuenta de servicio o ejecutar gcloud auth application-default login.
Instalación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
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 de Docker.
Instalación
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Realiza la instalación en vSphere
Cuando instalas clústeres de Anthos alojados en Bare Metal en las VM de vSphere, debes desactivar las marcas tx-udp_tnl-segmentation y tx-udp_tnl-csum-segmentation. Estas marcas están relacionadas con la descarga de segmentación de hardware realizada por el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de clústeres de Anthos alojados en Bare Metal.
Solución alternativa
Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de
estas marcas:
ethtool-kNET_INTFC|grepsegm
Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.
La respuesta debe tener entradas como las siguientes:
A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas cuando no lo están. Para desactivar o inhabilitar estas marcas de forma explícita, activa y desactiva las siguientes marcas con los siguientes comandos:
Este cambio de marca no persiste en los reinicios. Configura las secuencias de comandos de inicio para establecer de forma explícita estas marcas cuando se inicia el sistema.
Revisiones y actualizaciones
1.10
bmctl no puede crear, actualizar ni restablecer clústeres de usuario de versiones anteriores.
La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria inferior, independientemente de 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 este problema te afecta, deberías ver registros similares a los siguientes cuando uses bmctl:
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
Es posible que las actualizaciones del clúster a la versión 1.12.1 se detengan
La actualización de clústeres a la versión 1.12.1 a veces se detiene debido a que el servidor de la API deja de estar disponible. Este problema afecta a todos los tipos de clústeres y 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 las verificaciones previas.
Solución alternativa
Puedes verificar los 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:
WordCount y Keepalive deben ejecutarse en cada nodo del plano de control antes de que intentes 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 se están ejecutando los contenedores haproxy y keepalived:
Si Run o Keepalive no se ejecutan en un nodo, reinicia kubelet en él:
systemctlrestartkubelet
Actualizaciones y actualizaciones, entorno de ejecución de VM de Anthos
1.11, 1.12
La actualización de clústeres a la versión 1.12.0 o superior falla cuando
el entorno de ejecución de VM de Anthos está habilitado.
En la versión 1.12.0 de los clústeres de Anthos alojados en 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 DG de la VM de Anthos. 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 primero inhabilites el entorno de ejecución de VM de Anthos. 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:
kubectleditvmruntime
Establece enabled como false en la especificación:
La actualización se detuvo en error during manifests operations
En algunas situaciones, las actualizaciones del clúster no se completan y la CLI de bmctl deja de responder. Este problema puede deberse a la actualización incorrecta de un recurso. Para determinar si este problema te afecta y corregirlo, revisa los registros anthos-cluster-operator y busca errores similares a las siguientes entradas:
controllers/Cluster"msg"="error during manifests operations""error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Estas entradas son un síntoma de un recurso actualizado de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso del problema.
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 funciones que usan Anthos Network Gateway.
Las actualizaciones del clúster 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 de Waiting for upgrade to complete... y los errores de registro anthos-cluster-operator como se muestra a continuación:
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:
No se puede iniciar el desvío del nodo cuando el nodo está fuera del alcance
El proceso de desvío de nodos no se iniciará si el nodo está fuera del alcance
de los clústeres de Anthos alojados en Bare Metal. 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 los clústeres de Anthos alojados en Bare Metal se envía con la versión 1.5.13 de containerd y esta versión de containerd requiere la versión libseccomp 2.5 o una posterior.
Si tu sistema no tiene instalada la versión 2.5 de libseccomp o una posterior, 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:
sudoapt-getinstalllibseccomp-dev
Para instalar la versión más reciente de libseccomp en CentOS o RHEL, ejecuta el siguiente comando:
sudodnf-yinstalllibseccomp-devel
Operación
1.10, 1.11, 1.12
Nodos acordonados 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) o versiones anteriores de Bare Metal y usas kubectl cordon en un nodo, los clústeres de Anthos alojados en Bare Metal podrían desacordonar el nodo antes de que estés listo para conciliar el estado esperado.
Solución alternativa
En el caso de los clústeres de Anthos alojados en Bare Metal versión 1.12.0 y anteriores, usa el modo de mantenimiento para 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 alojados en Bare Metal 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 un duplicado de registro, no podrá administrar 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 del clúster, como crear, actualizar o restablecer. Estos registros se encuentran en la carpeta bmctl-workspace/CLUSTER_NAME/ de forma predeterminada. Si el problema te afecta, tus registros contienen el siguiente mensaje de error:
flag provided but not defined: -registry-mirror-host-to-endpoints
Operación
1.10 a 1.11
Secreto de kubeconfig reemplazado
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 hace que las operaciones
de clúster estándar, como actualizar y actualizar, fallen para los clústeres de usuario
afectados. Este problema se aplica a los clústeres de Anthos en las 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: Es el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos alojados en Bare Metal son el nombre del clúster precedido por
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 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.
Los siguientes pasos restablecen 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 alojados en Bare Metal 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:
Reemplaza PATH_TO_GENERATED_FILE por la ruta de acceso al archivo kubeconfig del clúster de usuario. En la respuesta, se muestran detalles sobre los nodos del clúster de usuario. Confirma que los nombres de las máquinas sean
correctos para tu clúster.
Ejecuta el siguiente comando para borrar el archivo kubeconfig dañado en el clúster de administrador:
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 un 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 el usuario raíz, se usa sudo para ejecutar los comandos de instantánea. La ruta de acceso sudo puede diferir del perfil raíz y puede no 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, 1.15
Anthos VM Runtime: El reinicio de un Pod hace que las VMs del Pod
cambien de dirección IP o pierdan la dirección IP por completo.
Si la dirección IP de una VM cambia, esto no afecta la accesibilidad de las aplicaciones de VM expuestas como un servicio de Kubernetes.
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:
[PARSER]# https://rubular.com/r/Vn30bO78GlkvyBNamecri
Formatregex
# The timestamp is described inhttps://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt][0-9]{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]{2}:[0-9]{2}))(?<stream>stdout|stderr)(?<logtag>[^]*)(?<log>.*)$Time_KeytimeTime_Format%Y-%m-%dT%H:%M:%S.%L%z
Time_Keepoff
Reinicia los Pods del agente de reenvío de registros:
En el caso de los clústeres de Anthos alojados en Bare Metal versión 1.10 o una versión más reciente, algunos clientes
encontraron una facturación inesperadamente alta para Metrics volume en la
página Facturación. Este problema solo te afecta cuando se aplican todas las siguientes circunstancias:
La supervisión de aplicaciones está habilitada (enableStackdriverForApplications=true)
Si este problema te afecta, te recomendamos que actualices los clústeres a la versión 1.12 y cambie a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que resuelve este problema:
Marcas separadas para controlar la recopilación de registros de la aplicación frente a las métricas de la aplicación
Google Cloud Managed Service para Prometheus
Si no puedes actualizar a la versión 1.12, sigue estos pasos:
Busca los Pods y servicios de origen que tienen la facturación no deseada:
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, 1.15
Las modificaciones en metrics-server-config no se conservan
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 a fin de que se siga ejecutando el servidor de métricas. Sin embargo, debido a la conciliación, las ediciones realizadas en metrics-server-config se pueden revertir al valor predeterminado durante una actualización del clúster o una operación de actualización.
El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, detecta el ConfigMap revertido y es vulnerable a una sobrecarga excesiva.
Solución alternativa
En la versión 1.11.x, puedes crear una secuencia de comandos de la edición de ConfigMap y realizarla con actualizaciones o actualizaciones del clúster. Para obtener la versión 1.12 y posteriores, comunícate con el equipo de asistencia.
Registro y supervisión
1.11, 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 alojados 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 las versiones de clústeres de Anthos alojados en Bare Metal antes de la versión 1.11, el archivo de definición de la política para la alerta recomendada de Anthos on baremetal node cpu usage exceeds
80 percent (critical) 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 la consola de Google Cloud, 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 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, no son compatibles con gke-metrics-agent en este momento.
Registro y supervisión
1.10 a 1.11
Interrupciones intermitentes en la exportación de métricas
Es posible que los clústeres de Anthos alojados en Bare Metal experimenten interrupciones en la exportación normal
continua de métricas o que falten métricas en algunos nodos. Si este
problema afecta a los clústeres, es posible que veas vacíos en los datos para las siguientes
métricas (como mínimo):
El comando encuentra 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 generar una conectividad dañada desde un Pod a extremos externos, como google.com.
Para determinar si este problema te afecta, ejecuta el siguiente comando en el nodo:
iprouteshow
Varias instancias de default en la respuesta indican que estás afectado.
Herramientas de redes
1.12
Se reemplazan los cambios personalizados de los recursos de red en los clústeres de usuario
Los clústeres de Anthos alojados en Bare Metal versión 1.12.x no te impiden editar de forma manual los recursos personalizados de herramientas de redes en tu clúster de usuario. Los clústeres de Anthos alojados en Bare Metal concilian los recursos personalizados
de los clústeres de usuario con los recursos personalizados de tu clúster de administrador
durante las actualizaciones. Esta conciliación reemplaza cualquier edición realizada
directamente a 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 alojados en Bare Metal versión 1.12.x no aplican este requisito.
Debes editar 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 tu 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 alojados en Bare Metal 1.13.0 y versiones posteriores evitan que modifiques directamente los recursos personalizados de red en los clústeres de usuario.
Herramientas de redes
1.11, 1.12, 1.13, 1.14, 1.15
Error de NAT con demasiadas conexiones paralelas
Para un nodo determinado en tu clúster, la dirección IP del nodo proporciona la traducción
de direcciones de red (NAT) de paquetes enrutados a una dirección fuera del
clúster. De manera similar, cuando los paquetes entrantes ingresan a un nodo de balanceo de cargas configurado para usar 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 clústeres de Anthos alojados 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 del nodo problemático:
IP de origen del cliente con balanceo de cargas de capa 2
Establecer la política de tráfico externo en Local puede causar errores de enrutamiento, como No route to
host para el balanceo de cargas de 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 controla el tráfico local de nodos.
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 se pueda acceder a las IP de servicio. Para obtener más información sobre la configuración, consulta la sección sobre cómo conservar la dirección IP de origen del cliente en la sección sobre cómo configurar el balanceo de cargas en paquetes.
Herramientas de redes
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Si modificas firewalld, se borrarán las cadenas de política de iptable de Cilium.
Cuando se ejecutan clústeres de Anthos alojados en Bare Metal 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 hace que el Pod en el nodo pierda conectividad de red fuera del nodo.
Los cambios en firewalld que quitarán las cadenas iptables incluyen, entre otros:
Reinicio de firewalld con systemctl
Volver 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, es posible establecer 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 a fin de determinar qué direcciones IP flotantes están disponibles para su uso 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, 1.15
Fallas de conectividad del Pod y filtrado de la ruta de acceso inversa
Los clústeres de Anthos alojados en Bare Metal configuran el filtrado inverso en los nodos para
inhabilitar la validación de origen (net.ipv4.conf.all.rp_filter=0).
Si la configuración rp_filter se cambia a 1 o
2, los Pods fallarán debido a que se agota el tiempo de espera de la comunicación
fuera de los nodos.
El filtrado de rutas inversas 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 filtrado de rutas de acceso inversas 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 configurar 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 Pod anetd nuevo en su lugar:
Las direcciones IP del clúster de arranque (tipo) y las direcciones IP del nodo del clúster se superponen
192.168.122.0/24 y 10.96.0.0/27 son los
CIDR predeterminados de Pods y servicios que usa el clúster de arranque (similares).
Las verificaciones previas fallarán si se superponen con las direcciones IP de
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 clústeres de Anthos alojados en Bare Metal no son compatibles con Ubuntu 18.04.6 en el kernel de Google Analytics (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 que indica que el programa BPF es demasiado grande 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 Pods. Este problema no se aplica a los kernels de Ubuntu Hardware Enablement (HWE).
Solución alternativa
Te recomendamos que obtengas el kernel de HWE y lo actualices a la última versión de HWE compatible con Ubuntu 18.04.
Sistema operativo
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
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 ciclo de vida
(EOL). Como resultado del EOL, los repositorios yum dejaron de funcionar para CentOS, lo que provoca que fallen las operaciones de creación y actualización de clústeres. Esto se aplica a todas las versiones compatibles de CentOS y
afecta a todas las versiones de clústeres de Anthos alojados en Bare Metal.
Solución alternativa
Ver pasos alternativos
Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivo:
En RHEL y CentOS, hay un límite 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 de extremos. La implementación subyacente de nftable en RHEL y CentOS provoca esta limitación; no es una limitación intrínseca de clústeres de Anthos alojados en Bare Metal.
Seguridad
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
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 creados 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-mavc
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, 1.15
Errores de SELinux durante la creación de Pods
A veces, la creación de Pods falla cuando SELinux evita que el entorno de ejecución del contenedor configure etiquetas en las activaciones tmpfs. Esta falla es poco frecuente, pero puede ocurrir cuando SELinux está en modo Enforcing y en algunos kernels.
Para verificar que SELinux sea la causa de las fallas de creación de Pods, usa el siguiente comando a fin de verificar si hay errores en los registros kubelet:
journalctl-ukubelet
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-mavc
Este comando busca errores de permiso de caché de vector de acceso (AVC) en los registros de auditoría. El avc: denied de la siguiente respuesta de muestra confirma que las fallas de creación de Pods 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 del kernel.
Restablecimiento/eliminación
1.10, 1.11, 1.12
Eliminación del espacio de nombres
Si borras un espacio de nombres, no se crearán recursos nuevos 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 del clúster
antes de borrar su espacio de nombres. De lo contrario, los trabajos para restablecer 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, 1.15
servicio de containerd
El comando bmctl reset no borra ningún archivo binario o archivo de configuración 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 nodos no está habilitado de forma predeterminada después de las actualizaciones de clústeres
Cuando actualizas clústeres de Anthos alojados en Bare Metal, el detector de problemas de nodos no está habilitado
de forma predeterminada. Este problema se aplica 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 nodos:
Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
Usa el comando SSH y conéctate al nodo.
Comprueba si el servicio node-problem-detector systemd se está ejecutando en el nodo:
systemctlis-activenode-problem-detector
Si el resultado del comando muestra inactive, significa que el nodo-problema-detector no se está ejecutando en el nodo.
Para habilitar el detector de problemas de Node, usa el comando kubectl edit y edita el ConfigMap node-problem-detector-config. Para obtener más información, consulta Detector de problemas de nodos.
Operación
1.9, 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 no raíz.]
Solución alternativa:
Este problema se aplica a los clústeres de Anthos alojados en Bare Metal 1.9.x, 1.10.0 y 1.10.1, y se solucionó en las versiones 1.10.2 y 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 LoadBalancer si los Pods de backend se ejecutan en el nodo del plano de control y usan el campo hostNetwork: true en la especificación del contenedor.
El error no está presente en la versión 1.13 ni en versiones posteriores.
Solución alternativa:
Las siguientes soluciones pueden ayudarte si usas un Service LoadBalancer respaldado por los Pods de hostNetwork:
Ejecútalos en nodos trabajadores (no en nodos de plano de control).
Un Pod anthos-version-$version$ huérfano no puede extraer la imagen
Es posible que el clúster que se actualice de 1.12.x a 1.13.x observe un error de anthos-version-$version$ con el error ImagePullBackOff.
Esto sucede debido a que la condición de carrera de anthos-cluster-operator se actualiza y no debería afectar ninguna funcionalidad del clúster normal.
El error no está presente después de la versión 1.13 o posterior.
Solución alternativa:
Borra el trabajo de dynamic-version-installer antes del kubectl delete job anthos-version-$version$ -n kube-system
.
Revisiones y actualizaciones
1.13
Los clústeres 1.12 actualizados de 1.11 no se pueden actualizar a 1.13.0
Los clústeres de la versión 1.12 que se actualizaron desde 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 creados en la versión 1.12.
Para determinar si te ves afectado, verifica 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, esto te afecta.
[[["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-08-16 (UTC)"],[],[]]
Paneles y borra el panel Estado del nodo del clúster de Anthos.