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

En esta página, se enumeran todos los problemas conocidos de los clústeres de Anthos alojados en Bare Metal. Para filtrar los problemas conocidos por categoría o versión de producto, selecciona los filtros que desees en los siguientes menús desplegables.

Selecciona tus versiones de clústeres de Anthos alojados en Bare Metal:

Selecciona la categoría del problema:

También puedes buscar el problema:

Categoría Versiones identificadas Problema y solución alternativa
Herramientas de redes 1.15.0-1.15.2

No se reconoció el CoreDNS orderPolicy

OrderPolicy no se reconoce como parámetro y no se usa. En cambio, los clústeres de Anthos alojados en Bare Metal siempre usan Random.

Este problema ocurre porque la plantilla de CoreDNS no se actualizó, lo que hace que se ignore orderPolicy.


Solución alternativa:

Actualiza la plantilla de CoreDNS y aplica la corrección. Esta corrección persiste hasta que se realice una actualización.

  1. Edite la plantilla existente:
    kubectl edit cm -n kube-system coredns-template
    Reemplaza el contenido de la plantilla por lo siguiente:
    coredns-template: |-
      .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
    {{- if .PrivateGoogleAccess }}
        import zones/private.Corefile
    {{- end }}
    {{- if .RestrictedGoogleAccess }}
        import zones/restricted.Corefile
    {{- end }}
        prometheus :9153
        forward . {{ .UpstreamNameservers }} {
          max_concurrent 1000
          {{- if ne .OrderPolicy "" }}
          policy {{ .OrderPolicy }}
          {{- end }}
        }
        cache 30
    {{- if .DefaultDomainQueryLogging }}
        log
    {{- end }}
        loop
        reload
        loadbalance
    }{{ range $i, $stubdomain := .StubDomains }}
    {{ $stubdomain.Domain }}:53 {
      errors
    {{- if $stubdomain.QueryLogging }}
      log
    {{- end }}
      cache 30
      forward . {{ $stubdomain.Nameservers }} {
        max_concurrent 1000
        {{- if ne $.OrderPolicy "" }}
        policy {{ $.OrderPolicy }}
        {{- end }}
      }
    }
    {{- end }}
Herramientas de redes, operación 1.10, 1.11, 1.12, 1.13, 1.14

Componentes de la puerta de enlace de red de Anthos expulsados o pendientes debido a que falta una clase de prioridad

Los Pods de la puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted, como se muestra en el siguiente resultado condensado de ejemplo:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Estos errores indican eventos de expulsión o una incapacidad para programar Pods debido a los recursos de nodos. Dado que los Pods de la puerta de enlace de red de Anthos no tienen PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo. Cuando los nodos tienen restricciones de recursos, los Pods de la puerta de enlace de la red pueden expulsarse. Este comportamiento es especialmente inadecuado para el DaemonSet de ang-node, ya que esos Pods deben estar programados en un nodo específico y no se pueden migrar.


Solución alternativa:

Actualiza a la versión 1.15 o posterior.

Como solución a corto plazo, puedes asignar una PriorityClass de forma manual a los componentes de la puerta de enlace de Anthos Network. El controlador de clústeres de Anthos alojados en Bare Metal reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.

  • Asigna la clase system-cluster-critical PriorityClass a los objetos Deployment del controlador de clústeres ang-controller-manager y autoscaler.
  • Asigna la Prioridad system-node-critical al DaemonSet de nodo ang-daemon.
Instalación, actualizaciones y actualizaciones 1.15.0, 1.15.1, 1.15.2

No se pueden crear ni actualizar clústeres debido a la longitud del nombre del clúster

La creación de los clústeres de las versiones 1.15.0, 1.15.1 o 1.15.2, o su actualización a las versiones 1.15.0, 1.15.1 o 1.15.2 falla cuando el nombre del clúster tiene más de 48 caracteres (versión 1.15.0) o 45 caracteres (versión 1.11.1 o 1). Durante las operaciones de creación y actualización de clústeres, los clústeres de Anthos alojados en Bare Metal crean un recurso de verificación de estado con un nombre que incorpora el nombre y la versión del clúster:

  • Para los clústeres de la versión 1.15.0, el nombre del recurso de la verificación de estado es CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Para los clústeres de las versiones 1.15.1 o 1.15.2, el nombre del recurso de la verificación de estado es CLUSTER_NAME-kubernetes-CLUSTER_VER.

Para los nombres largos de clústeres, el nombre del recurso de verificación de estado excede la restricción de longitud de caracteres de Kubernetes 63 para los nombres de etiquetas, lo que impide la creación del recurso de verificación de estado. Sin una verificación de estado correcta, la operación del clúster falla.

Para ver si este problema te afecta, usa kubectl describe a fin de verificar el recurso con errores:

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Si este problema te afecta, la respuesta contiene una advertencia para una ReconcileError como la siguiente:

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Solución alternativa

Para desbloquear la creación o actualización del clúster, puedes omitir la verificación de estado. Usa el siguiente comando para aplicar un parche al recurso personalizado de la verificación de estado con el estado “pass”: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Actualizaciones y actualizaciones 1.14, 1.15

Los clústeres de las versiones 1.14.0 y 1.14.1 con funciones de vista previa no se pueden actualizar a la versión 1.15.x

Si los clústeres de las versiones 1.14.0 y 1.14.1 tienen habilitada una función de vista previa, se bloquea la actualización correcta a la versión 1.15.x. Esto se aplica a las funciones de vista previa, como la capacidad de crear un clúster sin kube-proxy, que está habilitada con la siguiente anotación en el archivo de configuración del clúster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Si este problema te afecta, recibirás un error como el siguiente durante la actualización del clúster:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Este problema se solucionó en los clústeres de Anthos en la versión 1.14.2 y posteriores de Bare Metal.


Solución alternativa:

Si no puedes actualizar tus clústeres a la versión 1.14.2 o superior antes de actualizar a la versión 1.15.x, puedes actualizarla a la versión 1.15.x directamente mediante un clúster de arranque:

bmctl upgrade cluster --use-bootstrap=true
Operación 1.15

Los clústeres de la versión 1.15 no aceptan direcciones IP flotantes duplicadas.

La puerta de enlace de red de Anthos no te permite crear nuevos recursos personalizados de NetworkGatewayGroup que contengan direcciones IP en spec.floatingIPs que ya se usen en los recursos personalizados de NetworkGatewayGroup existentes. Un webhook de Anthos aplica de manera forzosa esta regla en los clústeres de Bare Metal 1.15.0 y versiones posteriores. Las direcciones IP flotantes duplicadas preexistentes no generan errores. El webhook solo impide la creación de nuevos recursos personalizados de NetworkGatewayGroups que contengan direcciones IP duplicadas.

El mensaje de error de webhook identifica la dirección IP en conflicto y el recurso personalizado existente que ya la usa:

IP address exists in other gateway with name default

En la documentación inicial para las funciones de red avanzadas, como la puerta de enlace de salida de NAT, no se advierten las direcciones IP duplicadas. Inicialmente, el conciliador reconoció solo el recurso NetworkGatewayGroup llamado default. La puerta de enlace de red de Anthos ahora reconoce todos los recursos personalizados de NetworkGatewayGroup en el espacio de nombres del sistema. Se respetan los recursos personalizados NetworkGatewayGroup existentes, tal como están.


Solución alternativa:

Solo se producen errores cuando se crea un nuevo recurso personalizado NetworkGatewayGroup.

Para solucionar el error, haz lo siguiente:

  1. Usa el siguiente comando para enumerar NetworkGatewayGroups recursos personalizados:
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
  2. Abre los recursos personalizados NetworkGatewayGroup existentes y quita las direcciones IP flotantes en conflicto (spec.floatingIPs):
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system RESOURCE_NAME
  3. Para aplicar los cambios, cierra y guarda los recursos personalizados editados.
Entorno de ejecución de VM de Anthos 1.13.7

Es posible que las VM no se inicien en clústeres 1.13.7 que usen un registro privado.

Cuando habilitas Anthos VM Runtime en un clúster de la versión 1.13.7 nuevo o actualizado que usa un registro privado, es posible que las VM que se conectan a la red del nodo o usen una GPU no se inicien de forma correcta. Este problema se debe a que algunos Pods del sistema en el espacio de nombres vm-system obtienen errores de extracción de imagen. Por ejemplo, si tu VM usa la red de nodos, algunos Pods pueden informar errores de extracción de imágenes como los siguientes:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Este problema se solucionó en los clústeres de Anthos en la versión 1.14.0 y posteriores de Bare Metal.

Solución alternativa

Si no puedes actualizar tus clústeres de inmediato, puedes extraer imágenes de forma manual. Los siguientes comandos obtienen la imagen del complemento de CNI de macvtap para tu VM y la envían a tu registro privado:

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Reemplaza REG_HOST por el nombre de dominio de un host que duplicas de forma local.

Instalación 1.11, 1.12

Durante la creación del clúster en el clúster de tipo, el Pod de gke-metric-agent no puede iniciarse.

Durante la creación del clúster en el clúster de tipo, el Pod de gke-metrics-agent no se inicia debido a un error de extracción de imagen de la siguiente manera:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Además, en el registro containerd del clúster de arranque, verás la siguiente entrada:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Verá el siguiente error “failing pull” en el Pod:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Solución alternativa

A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de similares es facilitar la tasa de éxito de la creación del clúster y el seguimiento y la supervisión internos. Por lo tanto, puedes ignorar este error.

Solución alternativa

A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de similares es facilitar la tasa de éxito de la creación del clúster y el seguimiento y la supervisión internos. Por lo tanto, puedes ignorar este error.

Operación, Herramientas de redes 1.12, 1.13, 1.14, 1.15

El acceso a un extremo del servicio de IPv6 falla el nodo LoadBalancer en CentOS o RHEL

Cuando accedes a un servicio de pila doble (un servicio que tiene extremos IPv4 e IPv6) y usas el extremo IPv6, el nodo LoadBalancer que entrega el servicio puede fallar. Este problema afecta a los clientes que usan servicios de pila doble con CentOS o RHEL y a la versión de kernel anterior a kernel-4.18.0-372.46.1.el8_6.

Si crees que este problema te afecta, verifica la versión de kernel en el nodo LoadBalancer con el comando uname -a.


Solución alternativa:

Actualiza el nodo LoadBalancer a la versión kernel-4.18.0-372.46.1.el8_6 del kernel o una posterior. Esta versión de kernel está disponible de forma predeterminada en CentOS, RHEL 8.6 y versiones posteriores.

Herramientas de redes 1.11, 1.12, 1.13, 1.14.0

Problemas de conectividad intermitente después de reiniciar el nodo

Después de reiniciar un nodo, es posible que veas problemas de conectividad intermitentes para un servicio NodePort o LoadBalancer. Por ejemplo, es posible que tengas un protocolo de enlace TLS intermitente o errores de restablecimiento de la conexión. Este problema se solucionó para los clústeres de Anthos en las versiones 1.14.1 y posteriores de Bare Metal.

Para verificar si este problema te afecta, observa las reglas de reenvío de iptables en los nodos en los que se ejecuta el Pod de backend para el Service afectado:

sudo iptables -L FORWARD

Si ves la regla KUBE-FORWARD antes de la regla CILIUM_FORWARD en iptables, es posible que este problema te afecte. En el siguiente resultado de ejemplo, se muestra un nodo en el que existe el problema:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Solución alternativa:

Reinicie el anetd Pod en el nodo con una configuración incorrecta. Después de reiniciar el Pod anetd, la regla de reenvío en iptables debe configurarse de forma correcta.

En el siguiente resultado de ejemplo, se muestra que la regla CILIUM_FORWARD ahora está configurada de forma correcta antes de la regla KUBE-FORWARD:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Revisiones y actualizaciones 1.9, 1.10

La función de vista previa no conserva el permiso original ni la información del propietario

La función de vista previa del clúster 1.9.x que usa bmctl 1.9.x no conserva el permiso original ni la información del propietario. Para verificar si esta función te afecta, extrae el archivo con copia de seguridad con el siguiente comando:

tar -xzvf BACKUP_FILE

Solución alternativa

Verifica si metadata.json está presente y si bmctlVersion es 1.9.x. Si metadata.json no está presente, actualiza al clúster a la versión 1.10.x y usa bmctl 1.10.x para crear una copia de seguridad o restablecer.

Actualizaciones y creaciones 1.14.2

clientconfig-operator se detuvo en un estado pendiente con CreateContainerConfigError

Si actualizaste a un clúster de la versión 1.14.2 o lo creaste con una configuración de OIDC/LDAP, es posible que veas el Pod clientconfig-operator atascado en estado pendiente. Con este problema, hay dos Pods clientconfig-operator, uno en estado de ejecución y el otro en estado pendiente.

Este problema se aplica solo a los clústeres de Anthos en la versión 1.14.2 de Bare Metal. Las versiones anteriores, como 1.14.0 y 1.14.1, no se ven afectadas. Este problema se solucionó en la versión 1.14.3 y en todas las versiones posteriores, incluida la 1.15.0 y posteriores.


Solución alternativa:

Como solución alternativa, puedes aplicar un parche a la implementación clientconfig-operator para agregar contexto de seguridad adicional y asegurarte de que la implementación esté lista.

Usa el siguiente comando para aplicar un parche a clientconfig-operator en el clúster de destino:

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Reemplaza lo siguiente:

  • CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de destino.
Operación 1.11, 1.12, 1.13, 1.14, 1.15

La rotación de la autoridad certificadora falla en los clústeres sin balanceo de cargas en paquetes

Para los clústeres sin balanceo de cargas en paquetes (spec.loadBalancer.mode configurado como manual), el comando bmctl update credentials certificate-authorities rotate puede dejar de responder y fallar con el siguiente error: x509: certificate signed by unknown authority.

Si este problema te afecta, es posible que el comando bmctl muestre el siguiente mensaje antes de dejar de responder:

Signing CA completed in 3/0 control-plane nodes
En este caso, el comando falla con el tiempo. El registro de autoridad certificadora para un clúster con tres planos de control puede incluir entradas como las siguientes:

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Solución alternativa

Si necesitas más ayuda, comunícate con Atención al cliente de Google.

Instalación, Redes 1.11, 1.12, 1.13, 1.14.0-1.14.1

ipam-controller-manager bucles de falla en los clústeres de doble pila

Cuando implementas un clúster de pila doble (un clúster con direcciones IPv4 y, también, IPv6), es posible que los Pods ipam-controller-manager fallen. Este comportamiento hace que los nodos circulen entre los estados Ready y NotReady, y puede hacer que la instalación del clúster falle. Este problema puede ocurrir cuando el servidor de la API tiene una carga alta.

Para ver si este problema te afecta, verifica si los Pods de ipam-controller-manager fallan con errores CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

En el siguiente resultado de ejemplo, se muestran los Pods en estado CrashLoopBackOff:


ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Obtén detalles sobre el nodo que tiene el estado NotReady:

kubectl describe node <node-name> | grep PodCIDRs

En un clúster con este problema, un nodo no tiene ningún PodCIDR asignado, como se muestra en el siguiente resultado de ejemplo:


PodCIDRs:

En un clúster en buen estado, todos los nodos deben tener asignados CIDRD de doble pila, como se muestra en el siguiente resultado de ejemplo:


PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Solución alternativa:

Reinicia los Pods ipam-controller-manager:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Operación 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

escasez de reloj etcd

Los clústeres que ejecutan la versión 3.4.13 o versiones anteriores de etcd pueden experimentar escasez de relojes y relojes de recursos no operativos, lo que puede generar los siguientes problemas:

  • Se interrumpió la programación del Pod
  • No se pueden registrar los nodos
  • kubelet no observa cambios en el Pod

Estos problemas pueden hacer que el clúster no funcione.

Este problema se solucionó en los clústeres de Anthos en las versiones 1.12.9, 1.13.6, 1.14.3 y posteriores de Anthos Bare Metal. Estas versiones más recientes utilizan la versión 3.4.21 de etcd. Este problema afecta a todas las versiones anteriores de clústeres de Anthos alojados en Bare Metal.

Solución alternativa

Si no puedes actualizar de inmediato, puedes mitigar el riesgo de que el clúster falle mediante la reducción de la cantidad de nodos en el clúster. Quita los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MBps.

Para ver esta métrica en el Explorador de métricas, sigue estos pasos:

  1. Ve al Explorador de métricas en la consola de Google Cloud:

    Ir al Explorador de métricas

  2. Selecciona la pestaña Configuración.
  3. Expande la opción Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, usa los submenús para seleccionarla:
    1. En el menú Recursos activos, selecciona Contenedor de Kubernetes.
    2. En el menú Categorías de métricas activas, selecciona Anthos.
    3. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
    4. Haga clic en Aplicar.
Herramientas de redes 1.11.6, 1.12.3

Estado "Fallido" del modo vfio-pci del operador SR-IOV

El syncStatus del objeto SriovNetworkNodeState puede informar el valor “Con errores” para un nodo configurado. Para ver el estado de un nodo y determinar si el problema te afecta, ejecuta el siguiente comando:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Reemplaza NODE_NAME por el nombre del nodo que deseas verificar.


Solución alternativa:

Si el estado del objeto SriovNetworkNodeState es “Con errores”, actualiza a los clústeres de Anthos en la versión 1.11.7 o posterior de Anthos o a la versión 1.12.4 o posterior.

Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Algunos nodos trabajadores no tienen el estado Listo después de la actualización

Una vez finalizada la actualización, es posible que algunos nodos trabajadores tengan su condición Listo configurada en false. En el recurso Node, verá un error junto a la condición "Ready" similar al siguiente:


container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Cuando accedes a la máquina detenida, la configuración de la CNI en la máquina está vacía:

sudo ls /etc/cni/net.d/

Solución alternativa

Para reiniciar el Pod anetd del nodo, bórralo.

Actualizaciones y actualizaciones, seguridad 1.10

Varias rotaciones de certificados de cert-manager generan inconsistencias

Después de varias rotaciones manuales o automáticas de certificados, el Pod de webhook, como anthos-cluster-operator, no se actualiza con los certificados nuevos emitidos por cert-manager. Cualquier actualización del recurso personalizado del clúster falla y genera un error similar al siguiente:


Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Este problema puede ocurrir en las siguientes circunstancias:

  • Si realizaste dos rotaciones de certificados manuales emitidas por cert en un clúster de más de 180 días o más, y nunca reiniciaste el anthos-cluster-operator.
  • Si realizaste una rotación manual de certificados con cert-manager en un clúster de más de 90 días o más, y nunca reiniciaste el operador de anthos-cluster.

Solución alternativa

Reinicia el Pod finalizando el anthos-cluster-operator.

Revisiones y actualizaciones 1.14.0

Pods de implementador del controlador del ciclo de vida desactualizados creados durante la actualización del clúster de usuario

En la versión 1.14.0, se pueden crear uno o más Pods obsoletos para el controlador del ciclo de vida durante las actualizaciones del clúster de usuario. Este problema se aplica a los clústeres de usuario que se crearon inicialmente en versiones anteriores a la 1.12. Los Pods creados de forma no intencional impiden las operaciones de actualización, pero es posible que se encuentren en un estado anormal. Te recomendamos que quites los Pods desactualizados.

Este problema se corrigió en la versión 1.14.1.

Solución alternativa:

Para quitar los Pods obsoletos del implementador del controlador del ciclo de vida, haz lo siguiente:

  1. Enumera los recursos de comprobación previa:

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    El resultado se verá así:

    NAMESPACE                    NAME                      PASS   AGE
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    En el ejemplo anterior, ci-87a021b9dcbb31c es el nombre del clúster.

  2. Borra los recursos cuyo valor en la columna PASS sea true o false.

    Por ejemplo, para borrar los recursos del resultado de muestra anterior, usa los siguientes comandos:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG 
    kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG
Herramientas de redes 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

El estado BGPSession cambia constantemente debido a la gran cantidad de rutas entrantes

Los clústeres de Anthos alojados en Bare Metal Advanced no pueden administrar las sesiones de BGP correctamente cuando los pares externos promocionan una gran cantidad de rutas (aproximadamente 100 o más). Con una gran cantidad de rutas entrantes, el controlador de BGP local del nodo tarda demasiado en conciliar sesiones de BGP y no puede actualizar el estado. La falta de actualizaciones de estado, o una verificación de estado, hace que la sesión se borre por estar inactiva.

Entre los comportamientos no deseados de las sesiones de BGP que podrías observar o que indiques que hay un problema, se incluyen los siguientes:

  • Eliminación y recreación continuas de bgpsession
  • bgpsession.status.state nunca se convierte en Established.
  • Rutas que no se anuncian o se retiran y anuncian de forma reiterada.

Los problemas de balanceo de cargas de BGP pueden notarse con problemas de conectividad en los servicios de LoadBalancer.

Es posible que el problema de BGP FlatIP sea notorio con problemas de conectividad con los Pods.

Para determinar si los problemas de BGP se deben a que los pares remotos anuncian demasiadas rutas, usa los siguientes comandos para revisar los estados y los resultados asociados:

  • Usa kubectl get bgpsessions en el clúster afectado. El resultado muestra bgpsessions con el estado "Not Established" (No establecido) y el último tiempo del informe cuenta de manera continua hasta 10-12 segundos antes de que parezca restablecerse a cero.
  • El resultado de kubectl get bgpsessions muestra que las sesiones afectadas se vuelven a crear de forma repetida:

    kubectl get bgpsessions \
        -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • Los mensajes de registro indican que se están borrando las sesiones de BGP inactivas:

    kubectl logs ang-controller-manager-POD_NUMBER
    Reemplaza POD_NUMBER por el Pod líder en el clúster.


Solución alternativa:

Reduce o borra la cantidad de rutas anunciadas desde el intercambio de tráfico remoto al clúster con una política de exportación.

En los clústeres de Anthos alojados en Bare Metal versión 1.14.2 y posteriores, también puedes inhabilitar la función que procesa las rutas recibidas mediante un AddOnConfiguration. Agrega el argumento --disable-received-routes al contenedor bgpd del daemonset de ang-daemon.

Herramientas de redes 1.14, 1.15

Tiempos de espera de la aplicación causados por fallas de la inserción de la tabla de conntrack

Los clústeres que se ejecutan en un SO Ubuntu que usa el kernel 5.15 o superior son susceptibles a fallas de inserción de la tabla de seguimiento de conexión (conntrack) de netfilter. Los errores de inserción pueden ocurrir incluso cuando la tabla de conntrack tiene espacio para entradas nuevas. Las fallas se producen por cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas en función de la longitud de la cadena.

Para ver si este problema te afecta, puedes verificar las estadísticas del sistema de seguimiento de conexiones en el kernel con el siguiente comando:

sudo conntrack -S

La respuesta es similar a la que se muestra a continuación:

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Si un valor de chaintoolong en la respuesta es un número distinto de cero, este problema te afecta.

Solución alternativa

La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets) y la tabla de seguimiento de conexión de netfilter (nf_conntrack_max). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Reemplaza TABLE_SIZE por el tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos en el nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.

Revisiones y actualizaciones 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8 y 1.11.4.

No se pueden restablecer las copias de seguridad del clúster con bmctl para algunas versiones

Te recomendamos que crees una copia de seguridad de los clústeres antes de realizar la actualización, de modo que puedas restablecer la versión anterior si la actualización no se realiza de forma correcta. Un problema con el comando bmctl restore cluster hace que no pueda restablecer las copias de seguridad de los clústeres con las versiones identificadas. Este problema es específico de las actualizaciones, en las que restableces una copia de seguridad de una versión anterior.

Si tu clúster se ve afectado, el registro bmctl restore cluster contiene el siguiente error:


Error: failed to extract image paths from profile: anthos version VERSION not supported

Solución alternativa:

Hasta que se corrija este problema, te recomendamos que uses las instrucciones que aparecen en Cómo crear una copia de seguridad y restablecer clústeres para crear una copia de seguridad de tus clústeres y restablecerlos de forma manual, si es necesario.
Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2

NetworkGatewayGroup falla si no hay una dirección IP en la interfaz.

NetworkGatewayGroup no puede crear daemons para los nodos que no tienen interfaces IPv4 e IPv6. Esto hace que fallen funciones como el balanceador de cargas de BGP y la salida de NAT. Si verificas los registros del Pod ang-node con errores en el espacio de nombres kube-system, se muestran errores similares al siguiente ejemplo cuando falta una dirección IPv6:


ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

En el ejemplo anterior, no hay una dirección IPv6 en la interfaz ens192. Se muestran errores de ARP similares si al nodo le falta una dirección IPv4.

NetworkGatewayGroup intenta establecer una conexión ARP y una conexión NDP a la dirección IP de vínculo local. Si la dirección IP no existe (IPv4 para ARP, IPv6 para NDP), falla la conexión y el daemon no continúa.

Este problema se corrigió en la versión 1.14.3.


Solución alternativa:

Conéctate al nodo mediante SSH y agrega una dirección IPv4 o IPv6 al vínculo que contiene la IP del nodo. En la entrada de registro del ejemplo anterior, esta interfaz era ens192:

ip address add dev INTERFACE scope link ADDRESS

Reemplaza lo siguiente:

  • INTERFACE: Es la interfaz para tu nodo, como ens192.
  • ADDRESS: Es la dirección IP y la máscara de subred que se aplicarán a la interfaz.

Restablecimiento/eliminación 1.10, 1.11, 1.12, 1.13.0-1.13.2

anthos-cluster-operator bucle de falla cuando se quita un nodo del plano de control

Cuando intentas quitar un nodo del plano de control quitando la dirección IP de Cluster.Spec, anthos-cluster-operator entra en un estado de bucle de falla que bloquea cualquier otra operación.


Solución alternativa:

El problema se corrigió en las versiones 1.13.3, 1.14.0 y posteriores. Afecta a todas las demás versiones. Actualiza a una de las versiones corregidas

Como solución alternativa, ejecuta el siguiente comando:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Reemplaza lo siguiente:

  • IP_ADDRESS: la dirección IP del nodo en estado de bucle de falla.
  • CLUSTER_NAMESPACE: El espacio de nombres del clúster.
Instalación 1.13.1, 1.13.2 y 1.13.3

kubeadm join falla en clústeres grandes debido a una discrepancia de token

Cuando instalas clústeres de Anthos alojados en Bare Metal con una gran cantidad de nodos, es posible que veas un mensaje de error kubeadmin join similar al siguiente ejemplo:


TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Solución alternativa:

Este problema se resuelve en los clústeres de Anthos en la versión 1.13.4 y posteriores de Bare Metal.

Si necesitas usar una versión afectada, primero crea un clúster con menos de 20 nodos y, luego, cambia el tamaño del clúster para agregar nodos adicionales después de que se complete la instalación.

Registro y supervisión 1.10, 1.11, 1.12, 1.13.0

Límite de CPU bajo para metrics-server en clústeres de Edge

En los clústeres de Anthos alojados en Edge de Bare Metal, los límites bajos de CPU para metrics-server pueden causar reinicios frecuentes de metrics-server. El ajuste de escala automático horizontal de Pods (HPA) no funciona debido a que metrics-server está en mal estado.

Si el límite de CPU de metrics-server es inferior a 40m, tus clústeres pueden verse afectados. Para verificar los límites de CPU de metrics-server, revisa uno de los siguientes archivos:

  • Clústeres de Anthos alojados en Bare Metal versión 1.x-1.12:
    kubectl get deployment metrics-server -n kube-system \
        -o yaml > metrics-server.yaml
  • Clústeres de Anthos alojados en Bare Metal versión de Anthos 1.13 o versiones posteriores:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
        -o yaml > metrics-server.yaml

Solución alternativa:

Este problema se resuelve en los clústeres de Anthos en la versión 1.13.1 o posterior de Bare Metal. Para solucionar este problema, actualiza los clústeres.

Una solución a corto plazo hasta que puedas actualizar los clústeres es aumentar de forma manual los límites de CPU para metrics-server de la siguiente manera:

  1. Reduce verticalmente la escala de metrics-server-operator:
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Actualiza la configuración y aumenta los límites de CPU:
    • Clústeres de Anthos alojados en Bare Metal versión 1.x-1.12:
      kubectl -n kube-system edit deployment metrics-server
    • Clústeres de Anthos alojados en Bare Metal versión 1.13:
      kubectl -n gke-managed-metrics-server edit deployment metrics-server
    Quita la línea --config-dir=/etc/config y aumenta los límites de CPU, como se muestra en el siguiente ejemplo:
    
    [...]
    - command:
      - /pod_nanny
      # - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
    [...] Increase such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true>
  3. Guarda y cierra metrics-server para aplicar los cambios.
Herramientas de redes 1.14, 1.15

No funciona la conexión directa de NodePort al Pod de hostNetwork

La conexión a un Pod habilitado con hostNetwork a través del Service NodePort falla cuando el Pod de backend se encuentra en el mismo nodo que el NodePort objetivo. Este problema afecta a los objetos Service LoadBalancer cuando se usan con Pods alojados en hostNetwork. Con varios backends, puede haber una falla de conexión esporádica.

Este problema se debe a un error en el programa de eBPF.


Solución alternativa:

Cuando uses un Service de Nodeport, no orientes al nodo en el que se ejecuta el Pod de backend. Cuando uses el Service LoadBalancer, asegúrate de que los Pods de hostNetworked no se ejecuten en los nodos LoadBalancer.

Revisiones y actualizaciones 1.12.3, 1.13.0

Los clústeres de administrador de la versión 1.13.0 no pueden administrar los clústeres de usuario 1.12.3.

Los clústeres de administrador que ejecutan la versión 1.13.0 no pueden administrar los clústeres de usuario que ejecutan la versión 1.12.3. Las operaciones en un clúster de usuario de la versión 1.12.3 fallan.


Solución alternativa:

Actualiza el clúster de administrador a la versión 1.13.1 o actualízalo a la misma versión que el clúster de administrador.

Revisiones y actualizaciones 1.12

La actualización a la versión 1.13.x está bloqueada para los clústeres de administrador con grupos de nodo trabajador.

La versión 1.13.0 y las superiores no pueden contener grupos de nodo trabajador. Las actualizaciones a la versión 1.13.0 o superior para los clústeres de administrador con grupos de nodo trabajadors están bloqueadas. Si la actualización del clúster de administrador está detenida, puedes confirmar el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace para confirmar si son los grupos de nodo trabajador:


Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Solución alternativa:

Antes de actualizar, mueve todos los grupos de nodo trabajador a los clústeres de usuario. Si deseas obtener instrucciones para agregar y quitar grupos de nodos, consulta Administra grupos de nodos en un clúster.

Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Errores en la actualización de recursos con kubectl apply

Si actualizas recursos existentes, como los recursos personalizados ClientConfig o Stackdriver con kubectl apply, el controlador podría mostrar un error o revertir la entrada y los cambios deseados.

Por ejemplo, puedes intentar editar el recurso personalizado Stackdriver de la siguiente manera. Para ello, primero debes obtener el recurso y, luego, aplicar una versión actualizada.

  1. Obtén la definición de YAML existente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Vuelva a aplicar el archivo YAML actualizado:
    kubectl apply -f stackdriver.yaml

El último paso para kubectl apply es cuando tengas problemas.


Solución alternativa:

No uses kubectl apply para hacer cambios en los recursos existentes. En su lugar, usa kubectl edit o kubectl patch como se muestra en los siguientes ejemplos:

  1. Edita el recurso personalizado Stackdriver:
    kubectl edit stackdriver -n kube-system stackdriver
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Guardar y salir del editor

Enfoque alternativo mediante kubectl patch:

  1. Obtén la definición de YAML existente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Vuelva a aplicar el archivo YAML actualizado:
    kubectl patch stackdriver stackdriver --type merge \
        -n kube-system --patch-file stackdriver.yaml
Registro y supervisión 1.12, 1.13, 1.14, 1.15

Los fragmentos dañados de tareas pendientes causan un bucle de fallas de stackdriver-log-forwarder

El bucle de fallas stackdriver-log-forwarder si intenta procesar un fragmento de trabajo pendiente dañado Los siguientes errores de ejemplo se muestran en los registros del contenedor:


[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Cuando se produce este bloqueo, no puedes ver los registros en Cloud Logging.


Solución alternativa:

Para resolver estos errores, completa los siguientes pasos:

  1. Identifica los fragmentos de trabajos pendientes dañados. Revisa los siguientes mensajes de error de ejemplo:
    
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
    [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    
    En este ejemplo, se produce un error en el archivo tail.1/1-1659339894.252926599.flb almacenado en var/log/fluent-bit-buffers/tail.1/. Se deben quitar todos los archivos *.flb con una verificación de formato con errores.
  2. Finaliza los Pods en ejecución para stackdriver-log-forwarder:
    kubectl --kubeconfig KUBECONFIG -n kube-system \
        patch daemonset stackdriver-log-forwarder \
        -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

    Verifica que se borren los Pods de stackdriver-log-forwarder antes de continuar con el siguiente paso.
  3. Conéctate al nodo mediante SSH, en el que se ejecuta stackdriver-log-forwarder.
  4. En el nodo, borra todos los archivos *.flb dañados de var/log/fluent-bit-buffers/tail.1/.

    Si hay demasiados archivos dañados y quieres aplicar una secuencia de comandos para limpiar todos los fragmentos de tareas pendientes, usa las siguientes secuencias de comandos:
    1. Implementa un DaemonSet para limpiar todos los datos sucios de los búferes de fluent-bit:
      kubectl --kubeconfig 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
    2. Asegúrate de que el DaemonSet haya limpiado todos los nodos. El resultado de los siguientes dos comandos debe ser igual al número de nodos del clúster:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    3. Borra el DaemonSet de limpieza:
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
          fluent-bit-cleanup
    4. Reinicia los Pods stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Herramientas de redes, entorno de ejecución de VM de Anthos 1.14.0

Reiniciar Dataplane V2 (anetd) en clústeres puede provocar que las VMs existentes no se puedan conectar a una red que no sea un Pod

En clústeres de varias NIC, reiniciar Dataplane V2 (anetd) puede provocar que las máquinas virtuales no se puedan conectar a las redes. Es posible que se observe un error similar al siguiente en los registros del Pod anetd:


could not find an allocator to allocate the IP of the multi-nic endpoint

Solución alternativa:

Puedes reiniciar la VM como una solución rápida. Para evitar que se repita el problema, actualiza a los clústeres de Anthos alojados en Bare Metal 1.14.1 o versiones posteriores.

Operación 1.13, 1.14.0, 1.14.1

gke-metrics-agent no tiene límite de memoria en los clústeres de perfil de Edge

Según la carga de trabajo del clúster, el gke-metrics-agent podría usar más de 4,608 MiB de memoria. Este problema solo afecta a los clústeres de Anthos en los clústeres de perfiles perimetrales de Bare Metal. Los clústeres de perfil predeterminados no se verán afectados.


Solución alternativa:

Actualiza el clúster a la versión 1.14.2 o posterior.

Instalación 1.12 a 1.13

La creación del clúster puede fallar debido a condiciones de carrera

Cuando creas clústeres con kubectl, debido a las condiciones de carrera, la verificación previa podría no finalizar. Como resultado, la creación del clúster puede fallar en ciertos casos.

El conciliador de verificación previa crea un SecretForwarder para copiar el secreto ssh-key predeterminado en el espacio de nombres de destino. Por lo general, la verificación previa aprovecha las referencias del propietario y se concilia una vez que se completa el SecretForwarder. Sin embargo, en casos excepcionales, el propietario de las referencias de SecretForwarder puede perder la referencia a la verificación previa, lo que provoca que la verificación previa se detenga. Como resultado, la creación del clúster falla. Para continuar con la conciliación de la verificación previa controlada por el controlador, borra el Pod del operador de clúster o el recurso de verificación previa. Cuando borras el recurso de comprobación previa, se crea otro y continúa la conciliación. De forma alternativa, puedes actualizar los clústeres existentes (que se crearon con una versión anterior) a una versión fija.

Herramientas de redes 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Las direcciones IP reservadas no se liberan cuando se usa el complemento de ubicaciones con la función de varias NIC

En la función de varios NIC, si usas el complemento de ubicación de CNI y usas la operación CNI DEL para borrar una interfaz de red de un Pod, es posible que algunas direcciones IP reservadas no se liberen correctamente. Esto sucede cuando se interrumpe la operación de CNI DEL.

Para verificar las reservas de direcciones IP no utilizadas de los Pods, ejecuta el siguiente comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Solución:

Borra de forma manual las direcciones IP (grupos) que no se usan.

Instalación 1.10, 1.11.0, 1.11.1, 1.11.2

El detector de problemas de nodos falla en el clúster de usuario 1.10.4

El detector de problemas de nodos puede fallar en los clústeres de Anthos alojados en clústeres de usuario de Bare Metal 1.10.x, cuando los clústeres de Anthos alojados en Bare Metal 1.11.0, 1.11.1 o 1.11.2 administran clústeres de usuario 1.10.x. Cuando falla el detector de problemas de nodos, el registro se actualiza con el siguiente mensaje de error:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Solución alternativa

Actualiza el clúster de administrador a la versión 1.11.3 para resolver el problema.

Operación 1.14

Los nodos del clúster de IPv4 en modo isla 1.14 tienen un tamaño de máscara CIDR de Pod de 24

En la versión 1.14, el parámetro de configuración maxPodsPerNode no se tiene en cuenta para los clústeres en modo isla, por lo que a los nodos se les asigna un tamaño de máscara CIDR de Pod de 24 (256 direcciones IP).Esto podría provocar que el clúster se quede sin direcciones IP antes de lo esperado. Por ejemplo, si tu clúster tiene una máscara de CIDR de Pod de 22, a cada nodo se le asignará una máscara de CIDR de Pod de 24, y el clúster solo podrá admitir hasta 4 nodos. Es posible que tu clúster también experimente inestabilidad de la red en un período de deserción de Pods alto cuando maxPodsPerNode esté configurado en 129 o más y no haya suficiente sobrecarga en el CIDR del Pod para cada nodo.

Si tu clúster se ve afectado, el Pod anetd informa el siguiente error cuando agregas un nodo nuevo al clúster y no hay podCIDR disponible:

error="required IPv4 PodCIDR not available"

Solución alternativa

Sigue estos pasos para resolver el problema:

  1. Actualiza a la versión 1.14.1 o una posterior.
  2. Quita los nodos trabajadores y vuelve a agregarlos.
  3. Quita los nodos del plano de control y vuelve a agregarlos, preferentemente uno por uno para evitar el tiempo de inactividad del clúster.
Revisiones y actualizaciones 1.14.0, 1.14.1

No se pudo revertir la actualización del clúster

Una reversión de actualización puede fallar en los clústeres de Anthos alojados en Bare Metal 1.14.0 a 1.14.1. Si actualizas un clúster de 1.14.0 a 1.14.1 y, luego, intentas revertir a la versión 1.14.0 mediante el comando bmctl restore cluster, es posible que se muestre un error como el del siguiente ejemplo:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Solución alternativa:

Borra todos los recursos healthchecks.baremetal.cluster.gke.io en el espacio de nombres del clúster y, luego, vuelve a ejecutar el comando bmctl restore cluster:

  1. Enumera todos los recursos healthchecks.baremetal.cluster.gke.io:
    kubectl get healthchecks.baremetal.cluster.gke.io \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: Es el espacio de nombres del clúster.
    • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  2. Borra todos los recursos de healthchecks.baremetal.cluster.gke.io enumerados en el paso anterior:
    kubectl delete healthchecks.baremetal.cluster.gke.io \
        HEALTHCHECK_RESOURCE_NAME \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de verificación de estado.
  3. Vuelve a ejecutar el comando bmctl restore cluster.
Herramientas de redes 1.12.0

La dirección IP externa del servicio no funciona en modo plano

En un clúster que tiene flatIPv4 configurado como true, no se puede acceder a los servicios de tipo LoadBalancer mediante sus direcciones IP externas.

Este problema se solucionó en la versión 1.12.1.


Solución alternativa:

En el ConfigMap de cilium-config, establece enable-415 en "true" y, luego, reinicia los Pods anetd.

Revisiones y actualizaciones 1.13.0, 1.14

Las actualizaciones in situ de 1.13.0 a 1.14.x nunca finalizan

Cuando intentas realizar una actualización in situ de 1.13.0 a 1.14.x con bmctl 1.14.0 y la marca --use-bootstrap=false, la actualización nunca finaliza.

Un error con el operador preflight-check hace que el clúster nunca programe las verificaciones requeridas, lo que significa que la verificación previa no finaliza nunca.


Solución alternativa:

Actualiza a la versión 1.13.1 antes de actualizar a 1.14.x. Una actualización in situ de 1.13.0 a 1.13.1 debería funcionar. También puedes actualizar de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.

Actualizaciones y actualizaciones, seguridad 1.13 y 1.14

Los clústeres actualizados a la versión 1.14.0 pierden taints de instancia principal.

Los nodos del plano de control requieren uno de dos taints específicos para evitar que se programen Pods de carga de trabajo en ellos. Cuando actualizas la versión 1.13 de los clústeres de Anthos a la versión 1.14.0, los nodos del plano de control pierden los siguientes taints obligatorios:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Este problema no genera fallas de actualización, pero los Pods que no deben ejecutarse en los nodos del plano de control pueden comenzar a hacerlo. Estos Pods de cargas de trabajo pueden abrumar los nodos del plano de control y generar inestabilidad del clúster.

Determine si el problema lo afecta

  1. Busca los nodos del plano de control con el siguiente comando:
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
        -o name --kubeconfig KUBECONFIG_PATH
  2. Para verificar la lista de taints en un nodo, use el siguiente comando:
    kubectl describe node NODE_NAME \
        --kubeconfig KUBECONFIG_PATH

    Si no aparece ninguno de los taints obligatorios, se verá afectado.

Solución alternativa

Usa los siguientes pasos para cada nodo del plano de control del clúster de la versión 1.14.0 afectado a fin de restablecer la función adecuada. Estos pasos son para el taint node-role.kubernetes.io/master:NoSchedule y los Pods relacionados. Si deseas que los nodos del plano de control usen el taint PreferNoSchedule, ajusta los pasos según corresponda.

Operación, entorno de ejecución de VM de Anthos 1.11, 1.12, 1.13, 1.14, 1.15

La creación de una VM falla de forma intermitente con errores de carga

La creación de una máquina virtual (VM) nueva con el comando kubectl virt create vm falla con poca frecuencia durante la carga de la imagen. Este problema se aplica a las VM de Linux y de Windows. El error es similar al siguiente ejemplo:

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Solución alternativa

Vuelve a intentar el comando kubectl virt create vm para crear tu VM.

Actualizaciones y registros, registro y supervisión 1.11

Los componentes de la colección administrada en los clústeres 1.11 no se conservan en las actualizaciones a 1.12

Los componentes de la colección administrada forman parte del servicio administrado para Prometheus. Si implementaste de forma manual los componentes de la colección administrada en el espacio de nombres gmp-system de los clústeres de Anthos versión 1.11, los recursos asociados no se conservan cuando actualizas a la versión 1.12.

A partir de los clústeres de Anthos en la versión 1.12.0 de Bare Metal, el servicio administrado para los componentes de Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionadas se administran mediante stackdriver-operator con el campo enableGMPForApplications. El valor predeterminado del campo enableGMPForApplications es true, por lo que, si implementas de forma manual los componentes del servicio administrado para Prometheus en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver-operator borra los recursos.

Solución alternativa

Para conservar recursos de colecciones administrados de forma manual, haz lo siguiente:

  1. Crear una copia de seguridad de todos los recursos personalizados existentes de PodMonitoring.
  2. Actualiza el clúster a la versión 1.12 y habilita el servicio administrado para Prometheus.
  3. Vuelve a implementar los recursos personalizados de PodMonitoring en el clúster actualizado.
Revisiones y actualizaciones 1.13

Algunos clústeres de la versión 1.12 con el entorno de ejecución del contenedor de Docker no se pueden actualizar a la versión 1.13

Si a un clúster de la versión 1.12 que usa el entorno de ejecución del contenedor de Docker le falta la siguiente anotación, no se puede actualizar a la versión 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Si este problema te afecta, bmctl escribe el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Es más probable que esto ocurra con los clústeres de Docker de la versión 1.12 que se actualizaron desde la versión 1.11, ya que esa actualización no requiere la anotación para mantener el entorno de ejecución del contenedor de Docker. En este caso, los clústeres no tienen la anotación cuando se actualiza a la versión 1.13. Ten en cuenta que, a partir de la versión 1.13, containerd es el único entorno de ejecución de contenedores permitido.

Solución alternativa:

Si este problema te afecta, actualiza el recurso del clúster con la anotación faltante. Puedes agregar la anotación mientras se ejecuta la actualización, o después de cancelarla y antes de reintentarla.

Instalación 1.11

bmctl finaliza antes de que se complete la creación del clúster.

La creación de clústeres puede fallar en los clústeres de Anthos alojados en la versión 1.11.0 de Bare Metal (este problema se solucionó en los clústeres de Anthos en la versión 1.11.1 de Bare Metal). En algunos casos, el comando bmctl create cluster sale antes y escribe errores como los siguientes en los registros:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Solución alternativa

La operación con errores produce artefactos, pero el clúster no está operativo. Si este problema te afecta, sigue estos pasos para limpiar los artefactos y crear un clúster:

Instalación, entorno de ejecución de VM de Anthos 1.11, 1.12

Error de conciliación del informe de instalación de entorno de ejecución de VM

La operación de creación de clústeres puede informar un error similar al siguiente:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Solución alternativa

Este error es benigno y puedes ignorarlo.

Instalación 1.10, 1.11, 1.12

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

La creación del clúster 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, el valor predeterminado para los clústeres de Anthos alojados en Bare Metal versión 1.14).
  • El clúster está configurado a fin de proporcionar varias interfaces de red, varias NIC para los Pods (clusterNetwork.multipleNetworkInterfaces establecido en true en el archivo de configuración del clúster).
  • El clúster está configurado para usar un proxy (spec.proxy.url se especifica en el archivo de configuración del clúster). Aunque la creación del clúster 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 tu configuración containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Solución alternativa

Agrega CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodo.

Instalación 1.10, 1.11, 1.12

Error en sistemas con el parámetro de configuración umask restrictivo

La versión 1.10.0 de los clústeres de Anthos alojados en Bare Metal presenta una función del plano de control sin permisos de administrador que ejecuta todos los componentes del plano de control como un usuario no raíz. Ejecutar todos los componentes como un usuario no raíz puede causar fallas en la instalación o la actualización de los sistemas con un parámetro de configuración umask más restrictivo de 0077.


Solución alternativa

Restablece los nodos del plano de control y cambia el parámetro de configuración umask a 0022 en todas las máquinas del plano de control. Una vez actualizadas las máquinas, vuelve a intentar la instalación.

Como alternativa, puedes cambiar los permisos del directorio y del archivo de /etc/kubernetes en las máquinas del plano de control para que la instalación o actualización continúe.

  • Haz que /etc/kubernetes y todos sus subdirectorios sean legibles por el mundo: chmod o+rx.
  • Haz que todos los archivos del usuario root en el directorio /etc/kubernetes de manera recurrente sean legibles por el mundo (chmod o+r). Excluye los archivos de claves privadas (.key) de estos cambios porque ya se crearon con la propiedad y los permisos correctos.
  • Haz que /usr/local/etc/haproxy/haproxy.cfg sea legible en todo el mundo.
  • Haz que /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml sea legible en todo el mundo.
Instalación 1.10, 1.11, 1.12, 1.13

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible con las versiones 1.13 y anteriores de los clústeres de Anthos alojados en Bare Metal. Sin embargo, la versión 1.14 es compatible con cgroup v2 como una función de vista previa . La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.


Solución alternativa

Si tu sistema usa cgroup v2, actualiza a la versión 1.14 de los clústeres de Anthos alojados en Bare Metal.

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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 usuario), la verificación previa no verifica las credenciales de la cuenta de servicio de Google Cloud ni sus permisos asociados.

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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 se establece en global.


Solución alternativa

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

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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 previa fallará y se informará que Docker service is not active.


Solución alternativa

Quita Docker o habilita el servicio de Docker.

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Realiza la instalación en vSphere

Cuando instalas clústeres de Anthos alojados en Bare Metal 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 realizada por el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de clústeres de Anthos alojados en Bare Metal.


Solución alternativa

Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de estas marcas:

ethtool -k NET_INTFC | grep segm

Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.

La respuesta debe tener entradas como las siguientes:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas cuando no lo están. Para desactivar o inhabilitar estas marcas de forma explícita, activa y desactiva las siguientes 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 establecer de forma explícita estas marcas cuando se inicia el sistema.

Revisiones y actualizaciones 1.10

bmctl no puede crear, actualizar ni restablecer clústeres de usuario de versiones anteriores.

La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria inferior, independientemente de 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 la versión 1.N-1.Y, incluso si el clúster de administrador también está en la versión 1.N.X.

Si este problema te afecta, deberías ver registros similares a los siguientes 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

Solución alternativa:

Usa kubectl para crear, editar o borrar el recurso personalizado del clúster de usuario dentro del clúster de administrador.

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

Revisiones y actualizaciones 1.12

Es posible que las actualizaciones del clúster a la versión 1.12.1 se detengan

La actualización de clústeres a la versión 1.12.1 a veces se detiene debido a que el servidor de la API deja de estar disponible. Este problema afecta a todos los tipos de clústeres y todos los sistemas operativos compatibles. Cuando se produce este problema, el comando bmctl upgrade cluster puede fallar en varios puntos, incluso durante la segunda fase de las verificaciones previas.


Solución alternativa

Puedes verificar los registros de actualización para determinar si este problema te afecta. Los registros de actualización se encuentran en /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP de forma predeterminada.

upgrade-cluster.log puede contener errores como los siguientes:

Failed to upgrade cluster: preflight checks failed: preflight check failed
El registro de la máquina puede contener errores como los siguientes (las fallas repetidas indican que este problema te afecta):
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

WordCount y Keepalive deben ejecutarse en cada nodo del plano de control antes de que intentes actualizar tu clúster a la versión 1.12.1. Usa la interfaz de línea de comandos de crictl en cada nodo para verificar si se están ejecutando los contenedores haproxy y keepalived:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Si Run o Keepalive no se ejecutan en un nodo, reinicia kubelet en él:

systemctl restart kubelet
Actualizaciones y actualizaciones, entorno de ejecución de VM de Anthos 1.11, 1.12

La actualización de clústeres a la versión 1.12.0 o superior falla cuando el entorno de ejecución de VM de Anthos está habilitado.

En la versión 1.12.0 de los clústeres de Anthos alojados en Bare Metal, todos los recursos relacionados con el entorno de ejecución de VM de Anthos se migran al espacio de nombres vm-system para admitir mejor la versión de DG de la VM de Anthos. Si tienes habilitado el entorno de ejecución de VM de Anthos en un clúster de la versión 1.11.x o inferior, la actualización a la versión 1.12.0 o superior falla, a menos que primero inhabilites el entorno de ejecución de VM de Anthos. Cuando este problema te afecta, la operación de actualización informa el siguiente error:


Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Solución alternativa

Para inhabilitar el entorno de ejecución de VM de Anthos, sigue estos pasos:

  1. Edita el recurso personalizado VMRuntime:
    kubectl edit vmruntime
  2. Establece enabled como false en la especificación:
    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      ...
  3. Guarda el recurso personalizado en tu editor.
  4. Una vez que se complete la actualización del clúster, vuelve a habilitar Anthos VM Runtime.

Para obtener más información, consulta Trabaja con cargas de trabajo basadas en VM.

Revisiones y actualizaciones 1.10, 1.11, 1.12

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 la actualización incorrecta de un recurso. Para determinar si este problema te afecta y corregirlo, revisa 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.


Solución alternativa

Si encuentras estos errores en tus registros, completa los siguientes pasos:

  1. Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso contenido en el mensaje de registro.
  2. Guarda los cambios y aplícalos al recurso.
  3. Vuelve a intentar la actualización del clúster.
Revisiones y actualizaciones 1.10, 1.11, 1.12

Las actualizaciones están bloqueadas para los clústeres con funciones que usan Anthos Network Gateway.

Las actualizaciones del clúster de 1.10.x a 1.11.x fallan para los clústeres que usan la puerta de enlace NAT de salida o el balanceo de cargas en paquetes con BGP. Ambas funciones usan Anthos Network Gateway. Las actualizaciones del clúster se atascan en el mensaje de línea de comandos de Waiting for upgrade to complete... y los errores de registro anthos-cluster-operator como se muestra a continuación:


apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Solución alternativa

Para desbloquear la actualización, ejecuta los siguientes comandos en el clúster que deseas actualizar:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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.


Solución alternativa

A fin de obtener más información, incluidas las instrucciones para quitar nodos del modo de mantenimiento, consulta Cómo poner nodos en modo de mantenimiento.

Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

No se puede iniciar el desvío del nodo cuando el nodo está fuera del alcance

El proceso de desvío de nodos no se iniciará si el nodo está fuera del alcance de los clústeres de Anthos alojados en Bare Metal. Por ejemplo, si un nodo se desconecta durante un proceso de actualización del clúster, es posible que la actualización deje de responder. Esto es poco frecuente.


Solución alternativa

Para minimizar la probabilidad de encontrar este problema, asegúrate de que tus nodos funcionen correctamente antes de iniciar una actualización.

Revisiones y actualizaciones 1.12

containerd 1.5.13 requiere libseccomp 2.5 o una versión posterior

La versión 1.12.1 de los clústeres de Anthos alojados en Bare Metal se envía con la versión 1.5.13 de containerd y esta versión de containerd requiere la versión libseccomp 2.5 o una posterior.

Si tu sistema no tiene instalada la versión 2.5 de libseccomp o una posterior, actualízala antes de actualizar los clústeres existentes a la versión 1.12.1. De lo contrario, es posible que veas errores en los Pods cplb-update de los nodos del balanceador de cargas, como los siguientes:


runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond

Solución alternativa

Para instalar la versión más reciente de libseccomp en Ubuntu, ejecuta el siguiente comando:

sudo apt-get install  libseccomp-dev

Para instalar la versión más reciente de libseccomp en CentOS o RHEL, ejecuta el siguiente comando:

sudo dnf -y install libseccomp-devel
Operación 1.10, 1.11, 1.12

Nodos acordonados si no usas el procedimiento del modo de mantenimiento

Si ejecutas clústeres de Anthos en la versión 1.12.0 (anthosBareMetalVersion: 1.12.0) o versiones anteriores de Bare Metal y usas kubectl cordon en un nodo, los clústeres de Anthos alojados en Bare Metal podrían desacordonar el nodo antes de que estés listo para conciliar el estado esperado.


Solución alternativa

En el caso de los clústeres de Anthos alojados en Bare Metal versión 1.12.0 y 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 alojados en Bare Metal no desacordonarán tus nodos de forma inesperada cuando uses kubectl cordon.

Operación 1.11

Los clústeres de administrador de la versión 11 mediante una duplicación de registro no pueden administrar los clústeres de la versión 1.10

Si tu clúster de administrador está en la versión 1.11 y usa un duplicado de registro, no podrá administrar clústeres de usuario que estén en una versión secundaria inferior. Este problema afecta las operaciones de restablecimiento, actualización y actualización del clúster de usuario.

Para determinar si este problema te afecta, revisa tus registros en busca de operaciones del clúster, como crear, actualizar o restablecer. Estos registros se encuentran en la carpeta bmctl-workspace/CLUSTER_NAME/ de forma predeterminada. Si el problema te afecta, tus registros contienen el siguiente mensaje de error:


flag provided but not defined: -registry-mirror-host-to-endpoints
Operación 1.10 a 1.11

Secreto de kubeconfig reemplazado

El comando bmctl check cluster, cuando se ejecuta en clústeres de usuario, reemplaza el secreto 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 actualizar y actualizar, fallen para los clústeres de usuario afectados. Este problema se aplica a los clústeres de Anthos en las versiones 1.11.1 y anteriores de Bare Metal.

Para determinar si este problema afecta a un clúster de usuario, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

  • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  • USER_CLUSTER_NAMESPACE: Es el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos alojados en Bare Metal son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres predeterminado es cluster-test.
  • 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, entonces el clúster de usuario especificado se ve afectado.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Solución alternativa

Los siguientes pasos restablecen la función a un clúster de usuario afectado (USER_CLUSTER_NAME):

  1. Ubica el archivo kubeconfig del clúster de usuario. Los clústeres de Anthos alojados en Bare Metal generan el archivo kubeconfig en la estación de trabajo de administrador cuando creas un clúster. De forma predeterminada, el archivo se encuentra en el directorio bmctl-workspace/USER_CLUSTER_NAME.
  2. 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 del clúster de usuario. Confirma que los nombres de las máquinas sean correctos para tu clúster.
  3. 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
  4. Ejecuta el siguiente comando para volver a guardar el secreto 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
Operación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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 un usuario no raíz requiere que /usr/local/bin esté en la ruta de acceso del usuario. De lo contrario, fallará con un error crictl: command not found.

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


Solución alternativa

Actualiza secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.

Operación, entorno de ejecución de VM de Anthos 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Anthos VM Runtime: El reinicio de un Pod hace que las VMs del Pod cambien de dirección IP o pierdan la 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.


Solución alternativa

Si se pierde la dirección IP, debes ejecutar dhclient desde la VM a fin de adquirir una dirección IP para la VM.

Registro y supervisión 1.10

stackdriver-log-forwarder tiene [parser:cri] invalid time format registros de advertencia

Si el analizador de entornos de ejecución del contenedor (CRI) usa una expresión regular incorrecta para el tiempo de análisis, los registros del Pod stackdriver-log-forwarder contienen errores y advertencias como los siguientes:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Solución alternativa:

Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Facturación inesperada de supervisión

En el caso de los clústeres de Anthos alojados en Bare Metal versión 1.10 o una versión más reciente, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo te afecta cuando se aplican todas las siguientes circunstancias:

  • La supervisión de aplicaciones está habilitada (enableStackdriverForApplications=true)
  • El servicio administrado para Prometheus no está habilitado (enableGMPForApplications).
  • Los Pods de la aplicación tienen la anotación prometheus.io/scrap=true

Para confirmar si este problema te afecta, enumera las métricas definidas por el usuario. Si ves la facturación por métricas no deseadas, este problema se aplica a tu caso.


Solución alternativa

Si este problema te afecta, te recomendamos que actualices los clústeres a la versión 1.12 y cambie a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que resuelve este problema:

  • Marcas separadas para controlar la recopilación de registros de la aplicación frente a las métricas de la aplicación
  • Google Cloud Managed Service para Prometheus
  • Si no puedes actualizar a la versión 1.12, sigue estos pasos:

    1. Busca los Pods y servicios de origen que tienen la facturación no deseada:
      kubectl --kubeconfig KUBECONFIG \
          get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
      kubectl --kubeconfig KUBECONFIG get \
          services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del Pod o del Service.
    Registro y supervisión 1.11, 1.12, 1.13, 1.14, 1.15

    Las modificaciones en metrics-server-config no se conservan

    En casos extremos, la alta densidad de Pods puede generar una sobrecarga excesiva de registro y supervisión, lo que puede hacer que el servidor de métricas se detenga y se reinicie. Puedes editar el ConfigMap de metrics-server-config para asignar más recursos a fin de que se siga ejecutando el servidor de métricas. Sin embargo, debido a la conciliación, las ediciones realizadas en metrics-server-config se pueden revertir al valor predeterminado durante una actualización del clúster o una operación de actualización. El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, detecta el ConfigMap revertido y es vulnerable a una sobrecarga excesiva.


    Solución alternativa

    En la versión 1.11.x, puedes crear una secuencia de comandos de la edición de ConfigMap y realizarla con actualizaciones o actualizaciones del clúster. Para obtener la versión 1.12 y posteriores, comunícate con el equipo de asistencia.

    Registro y supervisión 1.11, 1.12

    Las métricas obsoletas afectan al panel de Cloud Monitoring

    Varias métricas de Anthos dejaron de estar disponibles y, a partir de los clústeres de Anthos alojados en la versión 1.11 de Bare Metal, ya no se recopilan datos para estas métricas obsoletas. Si usas estas métricas en cualquiera de tus políticas de alertas, no habrá datos para activar la condición de alerta.

    En la siguiente tabla, se enumeran las métricas individuales que dejaron de estar disponibles y la métrica que las reemplaza.

    Métricas obsoletas Métrica de reemplazo
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods
    kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods
    kube_node_status_capacity

    En las versiones de clústeres de Anthos alojados en Bare Metal antes de la versión 1.11, el archivo de definición de la política para la alerta recomendada de Anthos on baremetal node cpu usage exceeds 80 percent (critical) usa las métricas obsoletas. El archivo de definición JSON node-cpu-usage-high.json se actualiza para las versiones 1.11.0 y posteriores.


    Solución alternativa

    Sigue estos pasos para migrar a las métricas de reemplazo:

    1. En la consola de Google Cloud, selecciona Monitoring o haz clic en el siguiente botón:
      Ir a Monitoring
    2. En el panel de navegación, selecciona Paneles y borra el panel Estado del nodo del clúster de Anthos.
    3. Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel Estado del nodo del clúster de Anthos.
    4. Sigue las instrucciones para crear políticas de alertas a fin de crear una con el archivo de definición de políticas node-cpu-usage-high.json actualizado.
    Registro y supervisión 1.10 a 1.11

    stackdriver-log-forwarder tiene errores CrashloopBackOff

    En algunas situaciones, el agente de registro fluent-bit puede atascarse en el procesamiento de fragmentos dañados. Cuando el agente de Logging no puede omitir fragmentos dañados, puedes observar que stackdriver-log-forwarder sigue fallando con un error CrashloopBackOff. Si tienes este problema, tus registros tienen entradas como las siguientes

    
    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
    in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
    #1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
    #2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
    #3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
    #4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0
    

    Solución alternativa:

    Limpia los fragmentos de búfer para el reenvío de registros de Stackdriver.

    Nota: En los siguientes comandos, reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.

    1. Finaliza todos los Pods stackdriver-log-forwarder:
      kubectl --kubeconfig 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.
    2. Implementa el siguiente DaemonSet para limpiar los datos dañados de los búferes fluent-bit:
      kubectl --kubeconfig 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
    3. Usa los siguientes comandos para verificar que el DaemonSet limpió todos los nodos:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l \
          app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system get pods -l \
          app=fluent-bit-cleanup --no-headers | wc -l
      El resultado de ambos comandos debe ser igual a la cantidad de nodos en tu clúster.
    4. Borra el DaemonSet de limpieza:
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system delete ds fluent-bit-cleanup
    5. Reinicia los Pods del agente de reenvío de registros:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset \
          stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Datos de métricas desconocidos en Cloud Monitoring

    Los datos de los clústeres de la versión 1.10.x de Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Entre otros tipos de métricas que pueden tener métricas de resumen irrelevantes, se incluyen los siguientes:

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen están en la lista de métricas, no son compatibles con gke-metrics-agent en este momento.

    Registro y supervisión 1.10 a 1.11

    Interrupciones intermitentes en la exportación de métricas

    Es posible que los clústeres de Anthos alojados en Bare Metal experimenten interrupciones en la exportación normal continua de métricas o que falten métricas en algunos nodos. Si este problema afecta a los clústeres, es posible que veas vacíos en los datos para 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

    Solución alternativa

    Actualiza tus clústeres a la versión 1.11.1 o posterior.

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

    1. Abre tu recurso stackdriver para editarlo:
      kubectl -n kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud 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
    3. Guarda los cambios y cierra el editor de texto.
    4. 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 se realizaron las modificaciones.
    Herramientas de redes 1.10

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

    Tener varias puertas de enlace predeterminadas en un nodo puede generar una conectividad dañada desde un Pod a extremos externos, como google.com.

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

    ip route show

    Varias instancias de default en la respuesta indican que estás afectado.

    Herramientas de redes 1.12

    Se reemplazan los cambios personalizados de los recursos de red en los clústeres de usuario

    Los clústeres de Anthos alojados en Bare Metal versión 1.12.x no te impiden editar de forma manual los recursos personalizados de herramientas de redes en tu clúster de usuario. Los clústeres de Anthos alojados en Bare Metal concilian los recursos personalizados de los clústeres de usuario con los recursos personalizados de tu clúster de administrador durante las actualizaciones. Esta conciliación reemplaza cualquier edición realizada directamente a los recursos personalizados de red en el clúster de usuario. Los recursos personalizados de red deben modificarse solo en el clúster de administrador, pero los clústeres de Anthos alojados en Bare Metal versión 1.12.x no aplican este requisito.

    Las funciones avanzadas de red, como el balanceo de cargas en paquetes con BGP, la puerta de enlace NAT de salida, las redes de SR-IOV, el modo plano con BGP y las varias NIC para Pods, usan los siguientes recursos personalizados:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Debes editar estos recursos personalizados en el clúster de administrador y el paso de conciliación aplica los cambios a los clústeres de usuario.


    Solución alternativa

    Si modificaste alguno de los recursos personalizados mencionados anteriormente en un clúster de usuario, modifica los recursos personalizados correspondientes en tu clúster de administrador para que coincidan antes de la actualización. Este paso garantiza que se conserven los cambios de configuración. Los clústeres de Anthos alojados en Bare Metal 1.13.0 y versiones posteriores evitan que modifiques directamente los recursos personalizados de red en los clústeres de usuario.

    Herramientas de redes 1.11, 1.12, 1.13, 1.14, 1.15

    Error de NAT con demasiadas conexiones paralelas

    Para un nodo determinado en tu clúster, la dirección IP del nodo proporciona la traducción de direcciones de red (NAT) de paquetes enrutados a una dirección fuera del clúster. De manera similar, cuando los paquetes entrantes ingresan a un nodo de balanceo de cargas configurado para usar balanceo de cargas en paquetes (spec.loadBalancer.mode: bundled), la traducción de direcciones de red de origen (SNAT) enruta los paquetes a la dirección IP del nodo antes de que se reenvíen a un Pod de backend.

    El rango de puertos para NAT que usan clústeres de Anthos alojados en Bare Metal es de 32768 a 65535. Este rango limita la cantidad de conexiones paralelas a 32,767 por protocolo en ese nodo. Cada conexión necesita una entrada en la tabla de conntrack. Si tienes demasiadas conexiones de corta duración, la tabla de conntrack se queda sin puertos para NAT. Un recolector de elementos no utilizados limpia las entradas inactivas, pero la limpieza no es inmediata.

    Cuando la cantidad de conexiones en tu nodo se acerque a 32,767, comenzarás a ver disminuciones de paquetes para conexiones que necesitan NAT.

    Para identificar este problema, ejecuta el siguiente comando en el Pod anetd del nodo problemático:

    kubectl -n kube-system anetd-XXX -- hubble observe \
        --from-ip $IP --to-ip $IP -f

    Deberías ver los siguientes errores:

    
    No mapping for NAT masquerade DROPPED
    

    Solución alternativa

    Redistribuya su tráfico a otros nodos.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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

    Establecer la política de tráfico externo en Local puede causar errores de enrutamiento, como No route to host para el balanceo de cargas de capa 2. La política de tráfico externo se establece en Cluster (externalTrafficPolicy: Cluster) de forma predeterminada. Con esta configuración, Kubernetes controla el tráfico en 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 nodos.


    Solución alternativa

    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 de servicio. Para obtener más información sobre la configuración, consulta la sección sobre cómo conservar la dirección IP de origen del cliente en la sección sobre cómo configurar el balanceo de cargas en paquetes.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Si modificas firewalld, se borrarán las cadenas de política de iptable de Cilium.

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

    Los cambios en firewalld que quitarán las cadenas iptables incluyen, entre otros:

    • Reinicio de firewalld con systemctl
    • Volver a cargar firewalld con el cliente de línea de comandos (firewall-cmd --reload)

    Solución alternativa

    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 por el nombre del Pod anetd.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Direcciones egressSourceIP duplicadas

    Cuando se usa la vista previa de la función de puerta de enlace NAT de salida, es posible establecer reglas de selección de tráfico que especifiquen una dirección egressSourceIP que ya esté en uso para otro objeto EgressNATPolicy. Esto puede causar conflictos en el enrutamiento del tráfico de salida.


    Solución alternativa

    Coordina con tu equipo de desarrollo a fin de determinar qué direcciones IP flotantes están disponibles para su uso antes de especificar la dirección egressSourceIP en tu recurso personalizado EgressNATPolicy.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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

    Los clústeres de Anthos alojados en Bare Metal configuran el filtrado inverso 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 que se agota el tiempo de espera de la comunicación fuera de los nodos.

    El filtrado de rutas inversas se establece con archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). Este valor también puede ser anulado por sysctl, que almacena la configuración de filtrado de rutas de acceso inversas en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.


    Solución alternativa

    Para restablecer la conectividad del Pod, vuelve a configurar net.ipv4.conf.all.rp_filter en 0 de forma manual o reinicia el Pod anetd para volver a establecer net.ipv4.conf.all.rp_filter en 0. Para reiniciar el Pod anetd, usa los siguientes comandos a fin de ubicar y borrar el Pod anetd, y 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 por el nombre del Pod anetd.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Las direcciones IP del clúster de arranque (tipo) y las direcciones IP del nodo del clúster se superponen

    192.168.122.0/24 y 10.96.0.0/27 son los CIDR predeterminados de Pods y servicios que usa el clúster de arranque (similares). Las verificaciones previas fallarán si se superponen con las direcciones IP de máquina del nodo del clúster.


    Solución alternativa

    Para evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl a fin de especificar valores diferentes.

    Sistema operativo 1.11

    Incompatibilidad con Ubuntu 18.04.6 en el kernel de Google Analytics

    Las versiones 1.11.0 y 1.11.1 de clústeres de Anthos alojados en Bare Metal no son compatibles con Ubuntu 18.04.6 en el kernel de Google Analytics (de 4.15.0-144-generic a 4.15.0-176-generic). La incompatibilidad hace que el agente de red no pueda configurar la red del clúster con un error que indica que el programa BPF es demasiado grande en los registros anetd. Es posible que veas Pods atascados en el estado ContainerCreating con un error networkPlugin cni failed to set up pod en el registro de eventos de Pods. Este problema no se aplica a los kernels de Ubuntu Hardware Enablement (HWE).


    Solución alternativa

    Te recomendamos que obtengas el kernel de HWE y lo actualices a la última versión de HWE compatible con Ubuntu 18.04.

    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    La creación o actualización del clúster falla en CentOS

    En diciembre de 2020, la comunidad de CentOS y Red Hat anunciaron la eliminación de CentOS. El 31 de enero de 2022, CentOS 8 alcanzó el final de su ciclo de vida (EOL). Como resultado del EOL, los repositorios yum dejaron de funcionar para CentOS, lo que provoca que fallen las operaciones de creación y actualización de clústeres. Esto se aplica a todas las versiones compatibles de CentOS y afecta a todas las versiones de clústeres de Anthos alojados en Bare Metal.


    Solución alternativa

    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Limitaciones del extremo del sistema operativo

    En RHEL y CentOS, hay un límite a nivel de clúster de 100,000 extremos. Servicio de Kubernetes Si 2 servicios hacen referencia al mismo conjunto de pods, se cuenta como 2 conjuntos de extremos. La implementación subyacente de nftable en RHEL y CentOS provoca esta limitación; no es una limitación intrínseca de clústeres de Anthos alojados en Bare Metal.

    Seguridad 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    El contenedor no puede escribir en VOLUME definido en 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 creados 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 este problema te afecta, 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="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" 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

    Solución alternativa

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

    • Desactiva SELinux.
    • No uses la función VOLUME dentro del Dockerfile.
    Seguridad 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Errores de SELinux durante la creación de Pods

    A veces, la creación de Pods falla cuando SELinux evita que el entorno de ejecución del contenedor configure etiquetas en las activaciones 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 hace que la creación del Pod falle, 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 permiso de caché de vector de acceso (AVC) en los registros de auditoría. El avc: denied de 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

    Solución alternativa

    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 una versión posterior, ya que esas versiones corrigieron el error del kernel.

    Restablecimiento/eliminación 1.10, 1.11, 1.12

    Eliminación del espacio de nombres

    Si borras un espacio de nombres, no se crearán recursos nuevos en ese espacio de nombres, incluidos los trabajos para restablecer máquinas.


    Solución alternativa

    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 podrán crear, y el proceso de eliminación omitirá el paso de limpieza de la máquina.

    Restablecimiento/eliminación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    servicio de containerd

    El comando bmctl reset no borra ningún archivo binario o archivo de configuración containerd. El servicio containerd systemd queda en funcionamiento. El comando borra los contenedores que ejecutan Pods programados en el nodo.

    Revisiones y actualizaciones 1.10, 1.11, 1.12

    El detector de problemas de nodos no está habilitado de forma predeterminada después de las actualizaciones de clústeres

    Cuando actualizas clústeres de Anthos alojados en Bare Metal, el detector de problemas de nodos no está habilitado de forma predeterminada. Este problema se aplica a las actualizaciones de la versión 1.10 a la 1.12.1 y se corrigió en la versión 1.12.2.


    Solución alternativa:

    Para habilitar el detector de problemas de nodos:

    1. Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
      1. Usa el comando SSH y conéctate al nodo.
      2. Comprueba si el servicio node-problem-detector systemd se está ejecutando en el nodo:
        systemctl is-active node-problem-detector
        Si el resultado del comando muestra inactive, significa que el nodo-problema-detector no se está ejecutando en el nodo.
    2. Para habilitar el detector de problemas de Node, usa el comando kubectl edit y edita el ConfigMap node-problem-detector-config. Para obtener más información, consulta Detector de problemas de nodos.
    Operación 1.9, 1.10

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


    Solución alternativa:

    Este problema se aplica a los clústeres de Anthos alojados en Bare Metal 1.9.x, 1.10.0 y 1.10.1, y se solucionó en las versiones 1.10.2 y posteriores.

    Herramientas de redes 1.10, 1.11, 1.12

    Los servicios del balanceador de cargas no funcionan con contenedores en la red host del plano de control

    Hay un error en anetd en el que los paquetes se descartan para los servicios LoadBalancer si los Pods de backend se ejecutan en el nodo del plano de control y usan el campo hostNetwork: true en la especificación del contenedor.

    El error no está presente en la versión 1.13 ni en versiones posteriores.


    Solución alternativa:

    Las siguientes soluciones pueden ayudarte si usas un Service LoadBalancer respaldado por los Pods de hostNetwork:

    1. Ejecútalos en nodos trabajadores (no en nodos de plano de control).
    2. Usa externalTrafficPolicy: local en las especificaciones del servicio y asegúrate de que tus cargas de trabajo se ejecuten en los nodos del balanceador de cargas.
    Actualizaciones y actualizaciones 1.12 a 1.13

    Un Pod anthos-version-$version$ huérfano no puede extraer la imagen

    Es posible que el clúster que se actualice de 1.12.x a 1.13.x observe un error de anthos-version-$version$ con el error ImagePullBackOff. Esto sucede debido a que la condición de carrera de anthos-cluster-operator se actualiza y no debería afectar ninguna funcionalidad del clúster normal.

    El error no está presente después de la versión 1.13 o posterior.


    Solución alternativa:

    Borra el trabajo de dynamic-version-installer antes del kubectl delete job anthos-version-$version$ -n kube-system .

    Revisiones y actualizaciones 1.13

    Los clústeres 1.12 actualizados de 1.11 no se pueden actualizar a 1.13.0

    Los clústeres de la versión 1.12 que se actualizaron desde la versión 1.11 no se pueden actualizar a la versión 1.13.0. Este problema de actualización no se aplica a los clústeres creados en la versión 1.12.

    Para determinar si te ves afectado, verifica los registros del trabajo de actualización que contiene la string upgrade-first-no* en el clúster de administrador. Si ves el siguiente mensaje de error, esto te afecta.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
    ...
    [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
    ...

    Solución alternativa:

    Para solucionar este problema, haz lo siguiente:

    1. Ejecuta los siguientes comandos en la estación de trabajo de administrador:
      echo '[{ "op": "remove", "path": \
          "/spec/clusterConfiguration/featureGates" }]' \
          > remove-feature-gates.patch
      export KUBECONFIG=$ADMIN_KUBECONFIG
      kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
          'kubectl patch kubeadmconfig $1 -n $0 --type json \
          --patch-file remove-feature-gates.patch'
    2. Vuelve a intentar la actualización del clúster.
    Si necesitas asistencia adicional, comunícate con el equipo de Atención al cliente de Google.