Versión 1.9. 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.10, consulta Actualiza Anthos en Bare Metal en la documentación de 1.10.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

Se usó la API de Cloud Translation para traducir esta página.

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

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.

Instalación

La creación del clúster falla cuando se usan varias NIC, `containerd` y un proxy HTTPS

La creación de clústeres falla cuando tienes la siguiente combinación de condiciones:

El clúster está configurado para usar containerd como el entorno de ejecución del contenedor (nodeConfig.containerRuntime configurado como containerd en el archivo de configuración del clúster, la opción predeterminada para la versión 1.9 de los clústeres de Anthos en equipos físicos).
El clúster está configurado a fin de proporcionar interfaces de red múltiples, varias NIC, para los Pods (clusterNetwork.multipleNetworkInterfaces configurado como true en el archivo de configuración del clúster).
El clúster se configura para usar un proxy (spec.proxy.url se especifica en el archivo de configuración del clúster). Aunque la creación de clústeres 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 la configuración de containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Como solución alternativa a este problema, agrega los CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodos.

Si `containerRuntime` no se especifica, no se establece en containerd de forma predeterminada

En los clústeres de Anthos alojados en equipos físicos en la versión 1.9.0, el valor predeterminado containerRuntime se actualizó de docker a containerd en el archivo de configuración del clúster generado. Si el campo containerRuntime no se establece o se quita del archivo de configuración del clúster, containerRuntime se establece en docker cuando creas clústeres. El valor containerRuntime debe ser containerd, a menos que se establezca de forma explícita en docker. Este problema se aplica solo a las versiones 1.9.0 y 1.9.1.

Para determinar qué entorno de ejecución del contenedor usa el clúster, sigue los pasos que se indican en Recupera información del clúster. Verifica el valor de containerRuntime en la sección cluster.spec.nodeConfig.

La única forma de cambiar el entorno de ejecución del contenedor es actualizar los clústeres. Para obtener más información, consulta Cambia el entorno de ejecución del contenedor.

Este problema se solucionó en los clústeres de Anthos alojados en equipos físicos en la versión 1.9.2.

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible de forma oficial con los clústeres de Anthos en equipos físicos 1.9. La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.

Las comprobaciones previas verifican que cgroup v2 no está en uso en la máquina de clúster.

Mensajes de error benignos durante la instalación

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.

Comprobaciones previas y permisos denegados

Durante la instalación, es posible que veas errores sobre /bin/sh: /tmp/disks_check.sh: Permission denied. Estos mensajes de error se generan porque /tmp está activado con la opción noexec. Para que bmctl funcione, debes quitar la opción noexec del punto de activación /tmp.

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.

Realiza la instalación en vSphere

Cuando instalas clústeres de Anthos en equipos físicos en las VM de vSphere, debes desactivar las marcas tx-udp_tnl-segmentation y tx-udp_tnl-csum-segmentation. Estas marcas están relacionadas con la descarga de segmentación de hardware que realiza el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de clústeres de Anthos en equipos físicos.

Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de estas marcas. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.

En ocasiones, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas, pero no lo están. Para desactivar estas marcas de manera explícita, activa y desactiva las marcas con los siguientes comandos.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Este cambio de marca no persiste en los reinicios. Configura las secuencias de comandos de inicio para que establezcan de forma explícita estas marcas cuando se inicie el sistema.

Revisiones y actualizaciones

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

Si se quita el directorio .manifests 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, primero ejecuta bmctl check cluster, que volverá a crear el directorio .manifests.

Este problema se aplica a los clústeres de Anthos en equipos físicos 1.10 y versiones anteriores, y se corrige en la versión 1.11 y versiones posteriores.

`bmctl` no puede crear, actualizar ni restablecer clústeres de usuario de versión inferior

La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria inferior, sin importar la versión del clúster de administrador. Por ejemplo, no puedes usar bmctl con una versión de 1.N.X para restablecer un clúster de usuario de versión 1.N-1.Y, incluso si el clúster de administrador también está en la versión 1.N.X.

Si te afecta este problema, deberías ver los registros similares al siguiente cuando uses bmctl:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
    * cluster version 1.8.1 is not supported in bmctl version 1.9.5, only
cluster version 1.9.5 is supported

Para solucionar el problema, usa kubectl a fin de crear, editar o borrar el recurso personalizado del clúster de usuario del clúster de administrador.

La capacidad de actualizar los clústeres de usuario no se ve afectada.

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 un recurso actualizado de forma incorrecta. Para determinar si este problema te afecta y para corregirlo, sigue estos pasos:

Verifica los registros anthos-cluster-operator y busca errores similares a las siguientes entradas:
```
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
```
Estas entradas son un síntoma de un recurso actualizado de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso del problema.
Si encuentras estos errores en tus registros, usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso que el mensaje de registro contiene.
Guarda los cambios y aplícalos al recurso.
Vuelve a intentar la actualización del clúster.

Las actualizaciones fallan para los clústeres de la versión 1.8 en modo de mantenimiento

El intento de actualizar un clúster de la versión 1.8.x a la versión 1.9.x falla si alguna máquina de nodo se encuentra en modo de mantenimiento. Esto se debe a una anotación que permanece en estos nodos.

Para determinar si este problema te afectará, sigue estos pasos:

Obtén la versión del clúster que deseas actualizar mediante la ejecución del siguiente comando:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"
```
Si el valor de la versión que se muestra es para la versión secundaria de 1.8, como 1.8.3, continúa. De lo contrario, este problema no se aplica a tu caso.
Ejecuta el siguiente comando para verificar si el clúster tiene nodos que hayan estado en modo de mantenimiento:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"
```
Si las anotaciones que se muestran contienen baremetal.cluster.gke.io/maintenance-mode-duration, te verás afectado por este problema conocido.

A fin de desbloquear la actualización del clúster, ejecuta el siguiente comando para cada máquina de nodo afectada a fin de quitar la anotación baremetal.cluster.gke.io/maintenance-mode-duration:

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

`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 Colocar los nodos en modo de mantenimiento.

Limitación de la actualización del parche del clúster de usuario

Los clústeres de usuario que administra un clúster de administrador deben estar en la misma versión de los clústeres de Anthos en equipos físicos o una versión inferior y dentro de una actualización secundaria. Por ejemplo, se acepta un clúster de administrador de versión 1.9.0 (anthosBareMetalVersion: 1.9.0) que administra los clústeres de usuario de versión 1.8.4.

Una limitación de actualización te impide actualizar tus clústeres de usuario a un nuevo parche de seguridad cuando el parche se lanza después de la versión de actualización que usa el clúster de administrador. Por ejemplo, si tu clúster de administrador se encuentra en la versión 1.7.2, que se lanzó el 2 de junio de 2021, no puedes actualizar tus clústeres de usuario a la versión 1.6.4 porque se lanzó el 13 de agosto de 2021.

El desvío de nodos no puede iniciarse cuando el nodo está fuera de alcance

El proceso de desvío para nodos no comenzará si el nodo está fuera del alcance de los clústeres de Anthos en equipos físicos. Por ejemplo, si un nodo se desconecta durante un proceso de actualización de clústeres, es posible que la actualización deje de responder. Este caso es poco frecuente. Para minimizar la probabilidad de encontrar este problema, asegúrate de que tus nodos funcionen de forma correcta antes de iniciar una actualización.

Operación

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.

Este problema se aplica a los clústeres de Anthos en equipos físicos 1.9.x, 1.10.0 y 1.10.1, y se corrige en la versión 1.10.2 y en versiones posteriores.

Nodos acordonados si no usas el procedimiento de modo de mantenimiento

Si usas kubectl cordon de forma manual en un nodo, es posible que los clústeres de Anthos en equipos físicos desacordonen el nodo antes de estar listo para conciliar el estado esperado. Para los clústeres de Anthos en la versión 1.12.0 de Bare Metal y versiones 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 en equipos físicos no desacordonarán tus nodos de forma inesperada cuando uses kubectl cordon.

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

Captura una instantánea como usuario no raíz de acceso

Si usas containerd como entorno de ejecución del contenedor, la ejecución de la instantánea como usuario no raíz requiere que /usr/local/bin esté en la RUTA del usuario. De lo contrario, fallará con un error crictl: command not found.

Cuando no accedes como el usuario raíz, sudo se usa para ejecutar los comandos de la instantánea. La RUTA sudo puede diferir del perfil raíz y puede no contener /usr/local/bin.

Puedes corregir este error si actualizas secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.

Entorno de ejecución de VM de Anthos

Reiniciar un Pod hace que las VM del Pod cambien de dirección IP o pierdan su 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. Si se pierde la dirección IP, debes ejecutar dhclient desde la VM para adquirir una dirección IP para la VM.

Registro y supervisión

Faltan registros después de la interrupción de la red

En algunos casos, cuando el clúster se recupera de una interrupción de red, es posible que veas que los registros nuevos no aparecen en Cloud Logging. También puedes ver varios mensajes como los siguientes en tus registros de stackdriver-log-forwarder:

re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds

Para volver a activar el reenvío de registros, reinicia el Pod stackdriver-log-forwarder. Si el servidor de reenvío de registros se reinicia en un plazo de 4.5 horas después de la interrupción, los registros almacenados en búfer se reenvían a Cloud Logging. Los registros de más de 4.5 horas se descartan.

Interrupciones intermitentes en la exportación de métricas

Los clústeres de Anthos en la versión 1.9.x y 1.10.x de equipos físicos pueden experimentar interrupciones en la exportación normal, en la exportación continua de métricas o en la falta de métricas en algunos nodos. Si este problema afecta tus clústeres, es posible que veas vacíos en los datos de las siguientes métricas (como mínimo):

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

Para solucionar este problema, actualiza tus clústeres a la versión 1.10.3 o posterior.

Si no puedes actualizar, realiza los siguientes pasos como una solución alternativa:

Abre tu recurso stackdriver para editarlo:

kubectl -n kube-system edit stackdriver stackdriver

Para aumentar el límite de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver:

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

El recurso editado debe ser similar al siguiente:

spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Guarda los cambios y cierra el editor de texto.
Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:
```
kubectl -n kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
El comando encuentra cpu: 50m si tus ediciones se aplicaron.
Para evitar que los cambios se reviertan, reduce verticalmente la escala de stackdriver-operator:
```
kubectl -n kube-system scale deploy stackdriver-operator --replicas=0
```

Abre gke-metrics-agent-conf para editarla:

kubectl -n kube-system edit configmap gke-metrics-agent-conf

Edita la configuración para cambiar todas las instancias de probe_interval: 0.1s a probe_interval: 13s:

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Guarda los cambios y cierra el editor de texto.

Reinicia el conjunto de daemon gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

Seguridad

El contenedor no puede escribir en el `VOLUME` definido en el Dockerfile con containerd y SELinux

Si usas containerd como entorno de ejecución del contenedor y tu sistema operativo tiene SELinux habilitado, es posible que no se pueda escribir en el VOLUME definido en el Dockerfile de la aplicación. Por ejemplo, los contenedores compilados con el siguiente Dockerfile no pueden escribir en la carpeta /tmp.

FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp

Para verificar si este problema te afecta, ejecuta el siguiente comando en el nodo que aloja el contenedor problemático:

ausearch -m avc

Si te afecta este problema, verás un error denied como el siguiente:

time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979):
proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6
items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC
msg=audit(1649106092.768:10979): avc:  denied {
write } for  pid=76042 comm="bash"
name="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:container_t:s0:c701,c935
tcontext=system_u:object_r:container_ro_file_t:s0 tclass=dir permissive=0

Para solucionar el problema, realiza uno de los siguientes cambios:

Desactiva SELinux.
No uses la función VOLUME dentro de Dockerfile.

Rotación de la CA del clúster (función de vista previa)

El certificado/CA del clúster se rotará durante la actualización. La compatibilidad con la rotación a pedido es una función de vista previa.

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.

Después de realizar una rotación de autoridad certificadora (CA) de clúster de usuario en un clúster, todos los flujos de autenticación de usuario fallan. Estas fallas ocurren porque el recurso personalizado ClientConfig que se usa en los flujos de autenticación no se actualiza con los nuevos datos de CA durante la rotación de CA. Si realizaste una rotación de CA en tu clúster, comprueba si el campo certificateAuthorityData en el ClientConfig de default del espacio de nombres kube-public que contiene la CA del clúster más antigua.

Para resolver el problema de forma manual, actualiza el campo certificateAuthorityData con la CA actual del clúster.

Errores de SELinux durante la creación de Pods

La creación de Pods a veces falla cuando SELinux impide que el entorno de ejecución del contenedor configure etiquetas en activaciones de 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 -u kubelet

Si SELinux provoca la falla de la creación del Pod, la respuesta del comando contiene un error similar al siguiente:

error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied

Para verificar que este problema esté relacionado con la aplicación de SELinux, ejecuta el siguiente comando:

ausearch -m avc

Este comando busca errores de permisos de la caché de vector de acceso (AVC) en los registros de auditoría. avc: denied en la siguiente respuesta de muestra confirma que las fallas de creación de Pods están relacionadas con la aplicación de SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

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

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 versiones posteriores, ya que esas versiones corrigieron el error del kernel.

Herramientas de redes

Múltiples puertas de enlace predeterminadas interrumpen la conectividad a extremos externos

Tener múltiples puertas de enlace predeterminadas en un nodo puede provocar que la conectividad se interrumpa desde un Pod hacia extremos externos, como google.com.

Para determinar si este problema te afecta, ejecuta el siguiente comando en el nodo:

ip route show

Múltiples instancias de default en la respuesta indican que te afecta.

A fin de solucionar este problema, asegúrate de que la interfaz de puerta de enlace predeterminada que se usa para la IP del nodo de Kubernetes sea la primera en la lista.

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.

Si modificas firewalld, se borrarán las cadenas de políticas de iptables de Cilium

Cuando ejecutas clústeres de Anthos en equipos físicos con firewalld habilitado en CentOS o Red Had Enterprise Linux (RHEL), los cambios en firewalld pueden quitar las cadenas de iptables de Cilium en la red de host. El pod anetd agrega las cadenas de iptables cuando se inicia. La pérdida de las cadenas de iptables de Cilium hace que el pod en el nodo pierda conectividad de red fuera del nodo.

Entre los cambios en firewalld que quitarán las cadenas de iptables, se incluyen los siguientes:

Reinicio de firewalld con systemctl
Recarga de firewalld con el cliente de línea de comandos (firewall-cmd --reload)

Para solucionar este problema de conectividad, reinicia anetd en el nodo. Ubica y borra el Pod anetd con los siguientes comandos para reiniciar anetd:

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

Reemplaza ANETD_XYZ con el nombre del pod anetd.

Direcciones `egressSourceIP` duplicadas

Cuando uses la vista previa de funciones de puerta de enlace NAT de salida, es posible establecer reglas de selección de tráfico que especifiquen una dirección de egressSourceIP que ya está en uso para otro objeto EgressNATPolicy. Esto puede causar conflictos de enrutamiento de tráfico de salida. Coordina con tu equipo de desarrollo a fin de determinar qué direcciones IP flotantes están disponibles para usarse antes de especificar la dirección de egressSourceIP en tu recurso personalizado EgressNATPolicy.

Fallas de conectividad del Pod debido al tiempo de espera de E/S y al filtrado de ruta de acceso inversa

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

Las fallas de conectividad que se comunican con las direcciones IP del Service de Kubernetes son un síntoma de este problema. A continuación, se muestran algunos ejemplos de los tipos de errores que puedes ver:

Si todos los Pods de un nodo determinado no se pueden comunicar con las direcciones IP del Service, es posible que el Pod istiod informe un error como el siguiente:

 {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

Para el conjunto de daemon localpv que se ejecuta en cada nodo, el registro puede mostrar un tiempo de espera como el siguiente:

 I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

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). El comando sysctl 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. El comando sysctl puede anular la configuración del filtrado de la ruta de acceso inversa.

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. Se iniciará un Pod anetd nuevo 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.

Para configurar net.ipv4.conf.all.rp_filter de forma manual, ejecuta el siguiente comando:

sysctl -w net.ipv4.conf.all.rp_filter = 0

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 validación para las direcciones IP superpuestas en diferentes clústeres durante la actualización. La validación solo se aplica durante la creación del grupo de nodos o clúster.

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.

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.

Restablecimiento/eliminación

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.