Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, y ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos en equipos físicos. Para obtener más detalles, consulta las notas de la versión 1.7. Esta es la versión más reciente. Para obtener una lista completa de cada versión secundaria y de parche en orden cronológico, consulta las notas de la versión combinadas.

Versiones disponibles: 1.7  |   1.6

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.

Crea un lugar de trabajo de supervisión en la nube antes de visualizar los paneles

Debes crear un lugar de trabajo de Cloud Monitoring a través de Google Cloud Console antes de poder ver los clústeres de Anthos en paneles de supervisión de equipos físicos.

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.

Actualizar clústeres de Anthos alojados en equipos físicos

La actualización no está disponible en la versión 1.6.0.

Restablecimiento/eliminación

Compatibilidad con clústeres de usuarios

No puedes restablecer clústeres de usuarios con el comando bmctl reset.

Puntos de activación y fstab

El restablecimiento no desactiva los puntos de activación en /mnt/localpv-share/ y no limpia 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.

servicio de containerd

El comando bmctl reset no borra ningún archivo de configuración containerd u objeto binario. El servicio containerd systemd está en funcionamiento. El comando borra los contenedores que ejecutan pods programados en el nodo.

Seguridad

El certificado/CA del clúster se rotará durante la actualización. 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.

Redes

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 (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). 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. Configurar rp_filter de nuevo en 0 debe restablecer la conectividad del pod.

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.

Limitaciones del extremo del sistema operativo

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

Configuración

Especificaciones del plano de control y el balanceador de cargas

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

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

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

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