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

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.

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.

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.

LTS de Ubuntu 20.04 y `bmctl`

En las versiones anteriores a la versión 1.8.2 de los clústeres de Anthos en equipos físicos, algunas distribuciones de LTS de Ubuntu 20.04 con un kernel de Linux más reciente (incluidas las imágenes de LTS de Ubuntu 20.04 de GCP en el kernel 5.8) realizaron /proc/sys/net/netfilter/nf_conntrack_max de solo lectura en espacios de nombres de red que no sean init. Esto evita que bmctl establezca el tamaño máximo de la tabla de seguimiento de conexiones, lo que evita que el clúster de arranque se inicie. Un síntoma del tamaño incorrecto de la tabla es que el Pod kube-proxy del clúster de arranque se bloqueará, como se muestra en el siguiente registro de error de muestra:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

La solución alternativa es configurar net/netfilter/nf_conntrack_max de forma manual en el valor necesario en el host: sudo sysctl net.netfilter.nf_conntrack_max=393216. Ten en cuenta que el valor necesario depende de la cantidad de núcleos del nodo. Usa el comando kubectl logs que se muestra arriba para confirmar el valor deseado de los registros kube-proxy.

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

Ubuntu 20.04.3+ LTS y HWE

Ubuntu 20.04.3 habilitó el kernel 5.11 en su paquete de habilitación de hardware (HWE). Los clústeres de Anthos en la versión 1.7.x de equipos físicos no son compatibles con este kernel. Si deseas usar el kernel 5.11, descarga y actualiza los clústeres de Anthos en la versión 1.8.0 o posterior de Bare Metal.

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.

Containerd requiere `/usr/local/bin` en la RUTA

Los clústeres con el entorno de ejecución de containerd requieren que /usr/local/bin esté en la RUTA del usuario SSH para que el comando kubeadm init encuentre el objeto binario crictl. Si no se puede encontrar crictl, la creación del clúster fallará.

Cuando no accedes como el usuario raíz, sudo se usa para ejecutar el comando kubeadm init. La RUTA sudo puede diferir del perfil raíz y puede no contener /usr/local/bin.

Para corregir este error, actualiza secure_path en /etc/sudoers a fin de incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.

A partir de la versión 1.8.2, los clústeres de Anthos en equipos físicos agregan /usr/local/bin a la RUTA cuando se ejecutan comandos. Sin embargo, la ejecución de la instantánea como usuario no raíz seguirá conteniendo crictl: command not found (que se puede solucionar mediante la solución alternativa anterior).

Oscilación de preparación de nodo

En ocasiones, los clústeres pueden presentar una preparación de nodos inestable (el estado de los nodos cambia con rapidez entre el comportamiento de Ready y NotReady). Un generador de eventos de ciclo de vida del Pod (PLEG) en mal estado causa este comportamiento. PLEG es un módulo de kubelet.

Para confirmar que un PLEG en mal estado está causando este comportamiento, usa el siguiente comando de journalctl a fin de verificar las entradas de registro del PLEG:

journalctl -f | grep -i pleg

Las entradas de registro como las siguientes indican que el PLEG está en mal estado:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Una condición de carrera runc conocida es la causa probable del PLEG en mal estado. Los procesos runc atascados son un síntoma de la condición de carrera. Usa el siguiente comando para verificar el estado del proceso runc init:

ps aux | grep 'runc init'

Para solucionar este problema, haz lo siguiente:

Ejecuta los siguientes comandos en cada nodo para instalar el último containerd.io y extraer la última herramienta de línea de comandos de runc:

Ubuntu

sudo apt update
sudo apt install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc

# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

CentOS/RHEL

sudo dnf install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc

# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

Reinicia el nodo si hay procesos runc init atascados.

Como alternativa, puedes limpiar de manera manual cualquier proceso atascado.

Revisiones y actualizaciones

`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.

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.

`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.

La actualización de clústeres a la versión 1.7.6 de la versión 1.7.5 está bloqueada

No puedes actualizar Anthos en los equipos físicos de la versión 1.7.5 a la versión 1.7.6. Este bloqueo no afecta a ninguna otra versión de los clústeres de Anthos en equipos físicos. Por ejemplo, puedes actualizar los clústeres de la versión 1.7.4 a la versión 1.7.6. Si tienes la versión 1.7.5 de clústeres, para obtener las correcciones de vulnerabilidades de seguridad que se abordan en la versión 1.7.6, debes actualizar a una versión posterior cuando esté disponible.

Actualiza desde 1.6.0

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

Actualiza de 1.7.0 a 1.7.x

Cuando se actualiza de 1.7.0 a 1.7.x, es posible que el clúster se detenga en la actualización del nodo del plano de control. Es posible que veas que los trabajos de MACHINE-IP-machine-upgrade se ejecutan y fallan de forma periódica. Este problema afecta a los clústeres 1.7.0 que tienen lo siguiente:

Docker preinstalado en los nodos del plano de control.
containerd seleccionado como el entorno de ejecución.

Este problema se debe a que los clústeres de Anthos en equipos físicos configuran de forma incorrecta el cri-socket en Docker en lugar de containerd. A fin de resolver este problema, debes configurar las credenciales de extracción de imágenes para Docker:

Accede a Docker:
```
docker login gcr.io
```
Esto crea un archivo $HOME/.docker/config.json.
Enumera las direcciones IP de todos los nodos del plano de control, separados por un espacio:
```
IPs=(NODE_IP1 NODE_IP2 ...)
```
Copia la configuración de Docker en los nodos:
```
for ip in "${IPs[@]}"; do
  scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
```
Reemplaza USER_NAME por el nombre de usuario configurado en el archivo de configuración del clúster de administrador.

Configura las credenciales de extracción de imágenes para Docker:

ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"

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, un clúster de administrador de la versión 1.8.1 (anthosBareMetalVersion: 1.8.1) que administra los clústeres de usuario de la versión 1.7.2 es aceptable, pero los clústeres de usuario de la versión 1.6.3 no están dentro de una versión secundaria.

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.8.2, que se lanzó el 29 de julio de 2021, no puedes actualizar tus clústeres de usuario a la versión 1.7.3 porque se lanzó el 16 de agosto de 2021.

El controlador del grupo de control está mal configurado en `cgroupfs`

Si tienes problemas relacionados con el controlador del grupo de control (cgroup), esto puede deberse a que los clústeres de Anthos en el equipo físico lo configuraron de forma incorrecta como cgroupfs en lugar de systemd.

Para solucionar este problema, haz lo siguiente:

Accede a tus máquinas y abre /etc/containerd/config.toml.

En [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options], agrega SystemdCgroup = true:

...
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
       runtime_type = "io.containerd.runc.v2"
       runtime_engine = ""
       runtime_root = ""
       privileged_without_host_devices = false
       base_runtime_spec = ""
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
         SystemdCgroup = true
 [plugins."io.containerd.grpc.v1.cri".cni]
   bin_dir = "/opt/cni/bin"
   conf_dir = "/etc/cni/net.d"
   max_conf_num = 1
   conf_template = ""
...

Guarda los cambios y cierra el archivo.
Abre /etc/systemd/system/kubelet.service.d/10-kubeadm.conf.

Al final del archivo, agrega --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service:

[Service]
Environment="HOME=/root"
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service

Guarda los cambios y reinicia el servidor.
Para verificar que systemd sea el controlador del grupo de control, ejecuta el siguiente comando:
```
systemd-cgls
```
Verifica que haya una sección kubepods.slice y que todos los Pods estén en ella.

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

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.

Logging y Monitoring

Los registros de nodos no se exportan a Cloud Logging

Los registros de nodos de los nodos con un punto (“.”) en su nombre no se exportan a Cloud Logging. Como solución alternativa, usa las siguientes instrucciones para agregar un filtro al recurso stackdriver-log-forwarder-config a fin de permitir que el operador de Stackdriver reconozca y exporte estos registros.

Disminuye el tamaño del operador de Stackdriver, stackdriver-operator:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system scale \
    deploy stackdriver-operator --replicas=0

Edita el configmap de reenvío de registros, stackdriver-log-forwarder-config:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
    stackdriver-log-forwarder-config

Agrega el siguiente filtro al final de la sección input-systemd.conf del configmap:

   [FILTER]
       Name    lua
       Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
       script  replace_dot.lua
       call    replace

 replace_dot.lua: |
   function replace(tag, timestamp, record)
       new_record = record

       local local_resource_id_key = "logging.googleapis.com/local_resource_id"

       -- Locate the local_resource_id
       local local_resource_id = record[local_resource_id_key]

       local first = 1
       local new_local_resource_id = ""
       for s in string.gmatch(local_resource_id, "[^.]+") do
           new_local_resource_id = new_local_resource_id .. s
           if first == 1 then
               new_local_resource_id = new_local_resource_id .. "."
               first = 0
           else
               new_local_resource_id = new_local_resource_id .. "_"
           end
       end

       -- Remove the trailing underscore
       new_local_resource_id = new_local_resource_id:sub(1, -2)
       new_record[local_resource_id_key] = new_local_resource_id
       return 1, timestamp, new_record
   end

Borra todos los Pods del servidor de reenvío de registros:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso.

Implementa un daemonset para limpiar todos los datos procesados sin procesar en búferes en bits de bits:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system apply -f - << EOF
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: fluent-bit-cleanup
      namespace: kube-system
    spec:
      selector:
        matchLabels:
          app: fluent-bit-cleanup
      template:
        metadata:
          labels:
            app: fluent-bit-cleanup
        spec:
          containers:
          - name: fluent-bit-cleanup
            image: debian:10-slim
            command: ["bash", "-c"]
            args:
            - |
              rm -rf /var/log/fluent-bit-buffers/
              echo "Fluent Bit local buffer is cleaned up."
              sleep 3600
            volumeMounts:
            - name: varlog
              mountPath: /var/log
            securityContext:
              privileged: true
          tolerations:
          - key: "CriticalAddonsOnly"
            operator: "Exists"
          - key: node-role.kubernetes.io/master
            effect: NoSchedule
          - key: node-role.gke.io/observability
            effect: NoSchedule
          volumes:
          - name: varlog
            hostPath:
              path: /var/log
EOF

Verifica que el daemonset limpió todos los nodos con los siguientes comandos.

kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
    -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
    -l app=fluent-bit-cleanup --no-headers | wc -l

El resultado de los dos comandos debe ser igual al número de nodo en el clúster

Borra el DaemonSet de limpieza.

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system delete ds fluent-bit-cleanup

Reinicia Pods:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
    daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

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.

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.

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 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. 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

Instantáneas

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

En el caso de la versión 1.8.1 y anteriores de los clústeres de Anthos en equipos físicos, si no accediste a tu cuenta como raíz, no puedes tomar una instantánea de clúster con el comando bmctl. A partir de la versión 1.8.2, los clústeres de Anthos en equipos físicos respetarán nodeAccess.loginUser en las especificaciones del clúster. Si no se puede acceder al clúster de administrador, puedes especificar el usuario de acceso con la marca --login-user.

Ten en cuenta que, si usas containerd como entorno de ejecución del contenedor, la instantánea no podrá ejecutar comandos crictl. Consulta Containerd requiere /usr/local/bin en PATH para obtener una solución alternativa. La configuración de PATH que se usó para SUDO causa este problema.

GKE Connect

Falla de repetición de Pod `gke-connect-agent`

El uso intensivo de la puerta de enlace de GKE Connect a veces puede causar problemas de falta de memoria en el Pod gke-connect-agent. Los síntomas de estos problemas de memoria insuficiente son los siguientes:

El Pod gke-connect-agent muestra una gran cantidad de reinicios o termina en un estado de fallas de repetición.
La puerta de enlace de conexión deja de funcionar.

Para solucionar este problema de memoria insuficiente, edita la implementación con el prefijo gke-connect-agent en el espacio de nombres gke-connect y aumenta el límite de memoria a 256 MiB o más.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'