Versión 1.6. 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.7, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.7.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

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

Instalación

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible con los clústeres de Anthos en equipos físicos 1.6. Kubernetes 1.18 no es compatible con cgroup v2. Además, Docker solo ofrece asistencia experimental a partir de 20.10. systemd pasó a cgroup v2 de forma predeterminada en la versión 247.2-2. La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.

A partir de los clústeres de Anthos en un equipo físico 1.6.2, las verificaciones previas verifican que cgroup v2 no esté en uso en la máquina del clúster.

Mensajes de error benignos durante la instalación

Durante la instalación del clúster con alta disponibilidad (HA), es posible que veas errores sobre etcdserver leader change. Estos mensajes de error son benignos y se pueden ignorar.

Cuando usas bmctl para la instalación del clúster, es posible que veas un mensaje de registro Log streamer failed to get BareMetalMachine al final del create-cluster.log. Este mensaje de error es benigno y se puede ignorar.

Cuando examinas los registros de creación de clústeres, puedes notar fallas transitorias sobre el registro de clústeres o la llamada a webhooks. Estos errores se pueden ignorar sin problemas, ya que la instalación reintentará estas operaciones hasta que tengan éxito.

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

Para las instalaciones activadas por clústeres híbridos o de administrador (en otras palabras, clústeres no creados con bmctl, como clústeres de usuarios), la verificación de comprobación previa no verifica las credenciales de la cuenta de servicio de Google Cloud Platform o sus permisos asociados.

Credenciales predeterminadas de la aplicación y `bmctl`

bmctl usa credenciales predeterminadas de la aplicación (ADC) para validar el valor de ubicación de la operación del clúster en cluster spec cuando no está configurado en global.

Para que ADC funcione, debes apuntar la variable de entorno GOOGLE_APPLICATION_CREDENTIALS a un archivo de credenciales de la cuenta de servicio o ejecutar gcloud auth application-default login.

Servicio de Docker

En las máquinas de nodo del clúster, si el ejecutable de Docker está presente en la variable de entorno PATH, pero el servicio de Docker no está activo, la verificación de comprobación previa fallará y, además, informará que Docker service is not active. Para solucionar este error, quita Docker o habilita el servicio de Docker.

Revisiones y actualizaciones

La actualización no está disponible en los clústeres de Anthos en las versiones de equipos físicos 1.6.x.

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

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

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

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

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

`bmctl update` no quita los bloques de mantenimiento

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

Operación

Se reemplazó el secret de kubeconfig

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

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

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

Reemplaza lo siguiente:

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

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

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

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

Ubica el archivo kubeconfig del clúster de usuario.

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

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

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

Restablecimiento/eliminación

Credenciales de clúster de usuario

El comando bmctl reset se basa en la sección de credenciales de nivel superior en el archivo de configuración del clúster. En el caso de los clústeres de usuarios, deberás actualizar manualmente el archivo para agregar la sección de credenciales.

Puntos de activación y `fstab`

El restablecimiento no desactiva los puntos de activación en /mnt/anthos-system y /mnt/localpv-share/. Tampoco se limpian las entradas correspondientes en /etc/fstab.

Eliminación del espacio de nombres

Borrar un espacio de nombres evitará que se creen recursos nuevos en ese espacio de nombres, incluidos los trabajos para restablecer máquinas. Cuando borras un clúster de usuario, primero debes borrar el objeto del clúster antes de borrar su espacio de nombres. De lo contrario, los trabajos para restablecer máquinas no se pueden crear y el proceso de eliminación omitirá el paso de limpieza de la máquina.

Seguridad

El certificado/CA del clúster se rotará durante la actualización. Por el momento, la compatibilidad con la rotación a pedido no está disponible.

Anthos en un equipo físico rota automáticamente los certificados de entrega kubelet. Cada agente de nodo kubelet puede enviar una solicitud de firma de certificado (CSR) cuando un certificado está cerca del vencimiento. Un controlador en tus clústeres de administrador valida y aprueba la CSR.

Herramientas de redes

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

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

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

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

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

El filtrado de ruta de acceso inversa se establece con los archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). También es posible que sysctl anule este valor, que almacena la configuración del filtrado de la ruta de acceso inversa en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.

Para restablecer la conectividad del Pod, vuelve a establecer net.ipv4.conf.all.rp_filter en 0 de forma manual o reinicia el Pod anetd para volver a configurar net.ipv4.conf.all.rp_filter en 0. A fin de reiniciar el Pod anetd, usa los siguientes comandos para ubicar y borrar el pod anetd, y se iniciará un nuevo Pod anetd en su lugar:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Reemplaza ANETD_XYZ con el nombre del pod anetd.

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

192.168.122.0/24 y 10.96.0.0/27 son los CIDR predeterminados del pod y del servicio que usa el clúster de arranque (kind). Las verificaciones de comprobación previa fallarán si se superponen con las direcciones IP de la máquina del nodo del clúster. A fin de evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl para especificar valores diferentes.

Cómo superponer direcciones IP en diferentes clústeres

No hay verificación previa para validar direcciones IP superpuestas en diferentes clústeres.

Función `hostport` en clústeres de Anthos en equipos físicos

Actualmente, no se admite la función hostport de ContainerPort.

Sistema operativo

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

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

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

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

Como solución a largo plazo, considera migrar a otro sistema operativo compatible, como Ubuntu o RHEL.

Limitaciones del extremo del sistema operativo

En RHEL y CentOS, existe una limitación de nivel de clúster de 100,000 extremos. Servicio de Kubernetes Si 2 servicios hacen referencia al mismo conjunto de pods, esto cuenta como 2 conjuntos de extremos separados. La implementación subyacente de nftable en RHEL y CentOS genera esta limitación. no es una limitación intrínseca de Anthos en el equipo físico.

Configuración

Especificaciones del plano de control y el balanceador de cargas

Las especificaciones del plano de control y el grupo de nodos del balanceador de cargas son especiales. Estas especificaciones declaran y controlan los recursos críticos del clúster. La fuente canónica de estos recursos es sus respectivas secciones en el archivo de configuración del clúster:

spec.controlPlane.nodePoolSpec
spec.LoadBalancer.nodePoolSpec

En consecuencia, no modifiques el plano de control de nivel superior ni los recursos del grupo de nodos del balanceador de cargas directamente. En su lugar, modifica las secciones asociadas en el archivo de configuración del clúster.

Campos mutables en la especificación del clúster y el grupo de nodos

Actualmente, solo los siguientes campos de especificación grupo de nodos y clúster del archivo de configuración del clúster se pueden actualizar después de la creación del clúster (son campos mutables):

Para el objeto Cluster (kind: Cluster), los siguientes campos son mutables:
- spec.anthosBareMetalVersion
- spec.bypassPreflightCheck
- spec.controlPlane.nodePoolSpec.nodes
- spec.loadBalancer.nodePoolSpec.nodes
- spec.maintenanceBlocks
- spec.nodeAccess.loginUser
Para el objeto NodePool (kind: NodePool), los siguientes campos son mutables:
- spec.nodes

El nodo muestra el estado `NotReady`

Bajo ciertas condiciones de carga, los nodos de clústeres de Anthos en equipos físicos versión 1.6.x pueden mostrar un estado NotReady debido a que el Generador de eventos de ciclo de vida del Pod (PLEG) está en mal estado. El estado del nodo contendrá la siguiente entrada:

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

¿Cómo puedo saber si me afecta?

Una causa probable de este problema es la versión binaria runc. Para confirmar si tienes la versión problemática instalada, conéctate a una de las máquinas del clúster mediante SSH y ejecuta lo siguiente:

/usr/bin/runc -v

Si el resultado es 1.0.0-rc93, significa que tienes instalada la versión problemática.

Posibles soluciones

Para resolver este problema, recomendamos actualizar a los clústeres de Anthos en un equipo físico 1.7.0 o una versión posterior.

Si la actualización no es una opción, puedes revertir el paquete containerd.io a una versión anterior en las máquinas de nodo problemáticas. Para hacerlo, conéctate a la máquina de nodo mediante SSH y ejecuta lo siguiente:

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.