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.