Problemas conocidos de Container Engine for Kubernetes

Las propiedades de los nuevos nodos de trabajador que se inician en un pool de nodos no reflejan los últimos cambios de las propiedades del pool de nodos. La causa probable es el uso de los atributos quantityPerSubnet y subnetIds en desuso al utilizar la operación de API UpdateNodePoolDetails para actualizar las propiedades del pool de nodos.

Realice una de las siguientes acciones:

• Comience a utilizar el atributo nodeConfigDetails al utilizar la operación de API UpdateNodePoolDetails. En primer lugar, ajuste el pool de nodos a 0 mediante quantityPerSubnet. A continuación, deje de utilizar los atributos subnetIds y quantityPerSubnet y utilice el atributo nodeConfigDetails en su lugar.
• Póngase en contacto con los Servicios de soporte Oracle para reiniciar el componente backend responsable de la sincronización (el componente inquilino-agente).

Al iniciar el panel de control de Kubernetes, en algunas situaciones puede encontrar mensajes de error "net/http: TLS handshake timeout" y "connection reset by peer" en el explorador web. Este problema solo se ha observado en las agrupaciones creadas recientemente que ejecutan Kubernetes versión 1.11. Para obtener más información sobre un problema relacionado con Kubernetes, consulte https://github.com/kubernetes/dashboard/issues/3038.

1. En una ventana de terminal, introduzca:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. En el explorador web, vaya a https://localhost:8443

Cuando utiliza un token de Kubeconfig versión 2.0.0 para acceder a las versiones de Helm/Tiller anteriores a la versión 2.11, recibirá uno de los siguientes errores:

• Error: Unauthorized
• Error: no se pudo obtener el cliente de Kubernetes: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Actualice Helm/Tiller de la siguiente manera:

1. En una ventana de terminal, descargue una versión de token 1.0.0 de Kubeconfig mediante la introducción del siguiente comando:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. Identifique la clave de región que se utilizará para especificar el registro de Oracle Cloud Infrastructure Registry en la región del cluster (consulte Disponibilidad por región). Por ejemplo, si el cluster está en Este de EE. UU. (Ashburn), iad es la clave de región que se utilizará para especificar el registro en dicha región.

3. Actualice Tiller introduciendo el siguiente comando:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   donde <region-key> es la clave que ha identificado en el paso anterior.

4. En un explorador, navegue a https://helm.sh/docs/using_helm/#installing- the-helm-client y siga las instrucciones para descargar e instalar el binario del cliente Helm.

5. Después de actualizar Helm/Tiller, descargue una versión del token de Kubeconfig 2.0.0 introduciendo el siguiente comando:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

La versión de Motor de contenedor para Kubernetes 1.8.0 incluía una mejora de seguridad para mejorar la solidez del cifrado en el kubelet que se ejecuta en los nodos de los trabajadores del cliente. Los nuevos nodos de trabajadores creados entre el 20 de agosto de y el 16 de septiembre de 2019 incluyen esta configuración. El nuevo conjunto de cifrados no permite conexiones al kubelet a través de http/2. Esta restricción afecta al servidor de métricas y a la escala automática de pod horizontal que depende del servidor de métricas.

Para cada nodo de trabajador existente, a su vez:

1. Evite que los nuevos pods inicien y eliminen los pods existentes en el nodo de trabajo introduciendo kubectl drain <node_name>. Para obtener más información:

   • acerca del uso de kubectl, consulte Acceso a un cluster mediante Kubectl
   • acerca del comando drain, consulte la sección de vaciado en la documentación de Kubernetes

   Recomendado: Aproveche los presupuestos de interrupción de pod según corresponda para su aplicación con el fin de garantizar que haya un número suficiente de pods de réplica en ejecución durante la operación de vaciado.

2. Suprima el nodo de trabajo (por ejemplo, finalizando el nodo en la consola ).
3. Espere a que se inicie un nodo de trabajo de sustitución.

Los nodos de trabajo de sustitución incluyen una nueva configuración que permite la comunicación con el kubelet.

Cuando se inicia un nuevo pod en un nodo de trabajador de un cluster, en algunas situaciones, el pod no puede montar todos los volúmenes asociados al nodo debido a timeouts y aparece un mensaje similar al siguiente:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

Una posible causa identificada para este problema es que la especificación del pod incluye un campo fsGroup en el campo securityContext. Si el contenedor se está ejecutando en un nodo de trabajador como usuario no raíz, la definición del campo fsGroup en securityContext puede provocar timeouts debido al número de archivos en los que Kubernetes debe realizar cambios de propiedad (consulte https://github.com/kubernetes/kubernetes/issues/67014).

Si la especificación del pod no incluye un campo fsgroup en securityContext, la causa se desconoce.

Si la especificación del pod incluye el campo fsgroup en securityContext y el contenedor está ejecutando un usuario no raíz, considere las siguientes soluciones alternativas:

• Elimine el campo fsgroup de securityContext.
• Utilice el campo supplementalGroups en securityContext (en lugar de fsgroup) y defina supplementalGroups en el identificador de volumen.
• Cambie la especificación del pod para que el contenedor se ejecute como raíz.

Si la especificación del pod no incluye el campo fsgroup en securityContext o si el contenedor ya se está ejecutando como raíz, debe reiniciar o sustituir el nodo de trabajador. Por ejemplo, parando e iniciando la instancia, reiniciando la instancia o terminando la instancia para que se inicie una nueva instancia. Siga las instrucciones de Parada, inicio o reinicio de una instancia o de Terminación de una instancia, según corresponda, para utilizar la consola o la API. También puede utilizar comandos de CLI, como el siguiente ejemplo, para terminar una instancia:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

donde <name> es el nombre del nodo de trabajador, derivado de la propiedad de dirección IP privada de la instancia (por ejemplo, 10.0.10.5).

Al utilizar el servicio OS Management para gestionar actualizaciones y parches del sistema operativo en instancias de Oracle Cloud Infrastructure, hay algunas situaciones en las que falla la puesta en línea de los pools de nodos de cluster creados en Container Engine for Kubernetes.

Hay dos soluciones alternativas posibles:

• Solución alternativa 1: si desea utilizar OS Management para gestionar instancias de Oracle Cloud Infrastructure, active Oracle Enterprise Linux en OS Management. Consulte Gestión de orígenes de software.
• Solución alternativa 2: si no desea utilizar OS Management para gestionar las instancias de Oracle Cloud Infrastructure, asegúrese de que no hay ninguna política que permitan la ejecución de OS Management. En concreto, elimine la política que otorga a un grupo dinámico de instancias acceso al servicio OS Management. Consulte Configuración de políticas para OS Management.

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

Para verificar esta incidencia, abra una ventana de terminal en la instancia y ejecute el siguiente comando:

sudo /usr/sbin/lsmod | grep br_netfilter 

Si no se devuelve ningún resultado, el módulo de núcleo de Bridge Netfilter no está activado. Se necesita el módulo de núcleo de Bridge Netfilter para enmascarar el tráfico VxLAN para los pods de Kubernetes.

Active el módulo de núcleo de Bridge Netfilter. Abra una ventana de terminal en la instancia y ejecute los siguientes comandos:

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

Al utilizar redes de pods nativas de VCN, es posible que la dirección IP del cliente de origen de las solicitudes entrantes a un pod no se mantenga como se espera. En su lugar, es posible que las solicitudes entrantes recibidas a través de un servicio de Kubernetes de tipo LoadBalancer que tiene externalTrafficPolicy: Local definido en el archivo de manifiesto se muestren como procedentes de la dirección IP del nodo de trabajo.

Para las solicitudes TCP entrantes recibidas mediante un servicio Kubernetes de tipo LoadBalancer que tenga la anotación oci.oraclecloud.com/load-balancer-type: "lb" en el archivo de manifiesto, obtenga la dirección IP del cliente de origen de la cabecera X-Forwarded-For o X-Real-IP.

Al utilizar redes de pods nativas de VCN, es posible que los pods no puedan comunicarse a través de la red si ha especificado una unidad con hardware dedicado para nodos de trabajo en uno o más pools de nodos del cluster.

Especifique una unidad de máquina virtual para los nodos de trabajo en todos los pools de nodos del cluster al utilizar redes de pods nativas de VCN.

Al utilizar redes de pods nativas de VCN, el número máximo de pods por nodo de trabajo en un pool de nodos puede estar limitado a 31, independientemente del número de OCPU que especifique para la unidad flexible que haya seleccionado para el pool de nodos.

Si desea más de 31 pods por nodo de trabajo en un pool de nodos, seleccione una unidad diferente para los nodos de trabajo en el pool de nodos.

Al utilizar redes de pods nativas de VCN, es posible que los pods que se ejecutan en nodos de trabajo conectados a una subred de pods con un bloque de CIDR fuera del primer bloque de CIDR especificado para la VCN no puedan comunicarse con los servicios de Kubernetes.

Cree subredes de pod con bloques CIDR dentro del primer bloque CIDR especificado para la VCN.

Al utilizar el script de Node Doctor para solucionar incidencias de nodos, el script puede mostrar un mensaje de error de excepción similar al siguiente:

FileNotFoundError: [Errno 2] No such file or directory: '/home/opc/vendor/pip…

El script de Node Doctor probablemente continuará ejecutándose y, después de mostrar el mensaje Generating node doctor bundle, producirá una salida de solución de problemas.

Somos conscientes del problema y estamos trabajando para solucionarlo. Mientras tanto, si el script de Node Doctor muestra el mensaje Generating node doctor bundle, tenga en cuenta que la salida de solución de problemas sigue siendo válida.

Si no desea que el script de Node Doctor muestre el mensaje de error de excepción FileNotFoundError: [Errno 2]..., actualice el script de Node Doctor introduciendo lo siguiente:

node-doctor.sh --update

Para obtener más información sobre el script de Node Doctor y cómo actualizarlo, consulte Solución de problemas de nodos para clusters de Kubernetes mediante el script de Node Doctor.

Si un cluster utiliza redes de pods nativas de VCN y tiene un pod de carga de trabajo y el pod CoreDNS en ejecución en el mismo nodo de trabajador, la resolución de DNS a veces falla porque el tráfico es incorrectamente NATed.

En 2023-03-21, se ha publicado una actualización del plugin de CNI de red de pods nativa de VCN de OCI que ha resuelto esta incidencia. Siga las instrucciones de la sección sobre actualización del plugin de CNI de red de pod nativa de VCN de OCI para desplegar la actualización.

Si un cluster utiliza redes de pod nativas de VCN y tiene nodos de trabajador que ejecutan Oracle Linux 8 (OL8), los pods a veces no se inician en uno de los nodos de trabajador. Esta incidencia tiene las siguientes características:

• El nodo de trabajador está ejecutando una imagen de OL8.
• Los pods relacionados con la red del host se ejecutan como se esperaba en el nodo de trabajador, pero el resto de los pods no se inician.
• Los logs crictl contienen el mensaje Adding address to IPVLAN parent device (que indica que se está conectando una dirección IP a la VNIC secundaria del nodo de trabajador), seguido del mensaje de error Error adding secondary VNIC IP.
• La ejecución del comando ip address de Linux en el nodo de trabajador muestra que una (o más) VNIC secundarias no tienen una dirección IP asociada.
• Todos los demás nodos de trabajador (o la mayoría) funcionan como se esperaba.

Una causa probable identificada para esta incidencia está relacionada con NetworkManager, que gestiona los dispositivos y las conexiones de red. En algunos casos, NetworkManager desasocia la dirección IP asociada a una o más VNIC secundarias del nodo de trabajador, lo que provoca que falle el plugin de CNI de red de pods nativa de VCN de OCI.

En 2023-03-21, se ha publicado una actualización del plugin de CNI de red de pods nativa de VCN de OCI que ha resuelto esta incidencia. Siga las instrucciones de la sección sobre actualización del plugin de CNI de red de pod nativa de VCN de OCI para desplegar la actualización.

Si ha especificado Oracle Linux 8.7 u Oracle Linux 8.8 para un pool de nodos (seleccionando una imagen de plataforma de Oracle Linux 8.7 u Oracle Linux 8.8, o una imagen de nodo de trabajador de OKE creada sobre Oracle Linux 8.7 u Oracle Linux 8.8), el estado de los nodos de trabajador del pool de nodos puede cambiar inesperadamente a NotReady. Esta incidencia tiene las siguientes características:

• Los nodos de trabajador están ejecutando Oracle Linux 8.7 u Oracle Linux 8.8.
• Los nodos de trabajador ejecutan la versión 1.24.1, 1.25.4 o 1.26.2 de Kubernetes. (Los nodos de trabajador que ejecutan Kubernetes versión 1.25.12, 1.26.7 y 1.27 no se ven afectados).
• Los pods de corta duración se despliegan con frecuencia en los nodos de trabajador.
• Los pods desplegados en los nodos de trabajador del pool de nodos también pueden permanecer en el estado ContainerCreating durante más tiempo del esperado.

Somos conscientes del problema y estamos trabajando para solucionarlo.

Mientras tanto, si encuentra esta incidencia, utilice cualquiera de las siguientes soluciones alternativas que mejor se adapte a sus requisitos:

• Especifique una imagen de Oracle Linux 7 para el pool de nodos.
• Especifique una imagen de Oracle Linux 8.6 (o una imagen anterior de Oracle Linux 8) para el pool de nodos.
• Especifique una versión posterior de Kubernetes para el pool de nodos. (Los nodos de trabajador que ejecutan Kubernetes versión 1.25.12, 1.26.7 y 1.27 no se ven afectados).

Para obtener los OCID de imágenes que ya no aparecen en la consola:

• Imágenes de plataforma: consulte todas las imágenes de Oracle Linux 7.x y todas las imágenes de Oracle Linux 8.x
• Imágenes de nodo de trabajador de OKE: consulte todas las imágenes de Oracle Linux 7.x de nodo de trabajador de OKE y todas las imágenes de Oracle Linux 8.x de nodo de trabajador de OKE

En los clusters creados antes del 26 de junio de 2023 que utilizan redes de pods nativas de VCN, puede que vea un retraso en el aprovisionamiento de nuevos nodos de trabajador.

Al iniciar nodos de trabajador con el plugin CNI de red de pod nativos de VCN de OCI, Container Engine for Kubernetes despliega un recurso personalizado de Kubernetes (el recurso NativePodNetwork o NPN) en cada instancia informática. Cuando un nodo de trabajador se ha iniciado correctamente, Container Engine for Kubernetes proporciona el estado SUCCESS al recurso NPN asociado a la instancia informática.

En algunos casos, si una instancia informática se termina antes de que Container Engine for Kubernetes otorgue el estado SUCCESS al recurso NPN asociado, el recurso NPN permanece en estado BACKOFF o IN_PROGRESS indefinidamente. La existencia de estos recursos "anteriores" puede retrasar el aprovisionamiento de nuevos nodos de trabajador.

El problema se corrige en los clusters creados después de 2023-06-26. Para resolver el problema en los clusters creados antes de 2023-06-26, realice una acción única para suprimir los recursos anticuados siguiendo las instrucciones de esta sección.

Antes de empezar, asegúrese de que el sistema cumple los siguientes requisitos:

• La CLI de OCI está instalada (consulte Instalación de la CLI)
• La CLI de OCI está configurada (consulte Configuración de CLI)
• jq se ha descargado e instalado (consulte https://jqlang.github.io/jq/download/)
• existe una política de IAM que otorga al menos el permiso INSTANCE_READ, como Allow group <group-name> to manage instance-family in <location> (consulte Creación de política necesaria para grupos)
• se puede acceder a los archivos kubeconfig adecuados para permitirle utilizar kubectl para gestionar clusters que utilizan el plugin CNI de red de pod nativos de VCN de OCI (consulte Acceso a un cluster mediante Kubectl)

Identifique y suprima los recursos anticuados de la siguiente manera:

1. Compruebe que el sistema cumple todos los requisitos:
   1. Guarde el siguiente script en un archivo denominado pre-req-check.sh:

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. Ejecute el script pre-req-check.sh introduciendo:

      sh pre-req-check.sh

2. Identifique los recursos de NPN que son posibles candidatos para supresión porque no tienen el estado Correcto:
   1. Para generar una lista de recursos NPN que no tienen el estado SUCCESS en un archivo de texto denominado potential_stale_resources.txt, introduzca:

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. Opcionalmente, puede ver la lista de recursos de NPN candidatos en potential_stale_resources.txt introduciendo:

      cat potential_stale_resources.txt

      Por ejemplo, potential_stale_resources.txt puede contener:

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. Identifique los recursos de NPN anticuados que desea suprimir mediante la determinación de los recursos de NPN candidatos asociados a instancias informáticas que no están disponibles o que se han terminado:
   1. Guarde el siguiente script en un archivo denominado get_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. Ejecute el script get_stale_resources.sh introduciendo:

      sh get_stale_resources.sh potential_stale_resources.txt

      La secuencia de comandos get_stale_resources.sh identifica los recursos de NPN anticuados que se deben suprimir, envía mensajes de procesamiento a la pantalla y escribe los nombres de los recursos de NPN anticuados en un archivo denominado stale_resources.txt. Por ejemplo:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. Opcionalmente, puede ver la lista de recursos de NPN obsoletos en stale_resources.txt introduciendo:

      cat stale_resources.txt

      Por ejemplo, stale_resources.txt puede contener:

      anyhqljth4...snq
      anyhqljth4...qhq

4. Suprima los recursos de NPN anticuados que se muestran en el archivo stale_resources.txt:
   1. Guarde el siguiente script en un archivo denominado delete_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. Ejecute el script delete_stale_resources.sh introduciendo:

      sh delete_stale_resources.sh stale_resources.txt

      La secuencia de comandos delete_stale_resources.sh suprime los recursos de NPN anticuados que se muestran en el archivo stale_resources.txt y envía los mensajes de procesamiento a la pantalla. Por ejemplo:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. Como buena práctica de limpieza y mantenimiento, suprima los archivos stale_resources.txt y potential_stale_resources.txt que ha creado anteriormente.

Al especificar una unidad Arm para un nodo virtual, los pods programados en el nodo se ejecutan en procesadores Arm según lo previsto. Sin embargo, si examina el nodo virtual mediante el comando kubectl describe node o la API de Kubernetes, la propiedad Architecture del nodo indica AMD64, aunque los pods programados en el nodo se ejecuten en procesadores Arm.

Somos conscientes del problema y estamos trabajando para solucionarlo.

Mientras tanto, si encuentra este problema, ignore el valor de la propiedad Architecture del nodo virtual.