Share via

Requisitos previos para implementar cargas de trabajo de inquilino

  • Artículo

En esta guía se explican los requisitos previos para crear:

  • Máquinas virtuales (VM) para cargas de trabajo de función de red virtual (VNF).
  • Implementaciones híbridas del clúster de Nexus Kubernetes para cargas de trabajo de funciones de red nativas en la nube (CNF).

Diagrama del flujo de implementación de cargas de trabajo de inquilino.

Requisitos previos de red

Debe crear varias redes en función de las necesidades de la carga de trabajo. La siguiente lista de consideraciones no es exhaustiva. Consulte con los equipos de soporte técnico adecuados para obtener ayuda.

  • Determine los tipos de redes que necesita para admitir las cargas de trabajo:
    • Una red de capa 3 (L3) requiere una asignación de VLAN y subred. La subred debe ser lo suficientemente grande como para admitir la asignación de direcciones IP a cada una de las máquinas virtuales. La plataforma reserva las tres primeras direcciones IP utilizables para uso interno. Por ejemplo, para admitir seis máquinas virtuales, el CIDR mínimo de la subred sería /28 (14 direcciones utilizables – 3 reservadas = 11 direcciones disponibles).
    • Una red de capa 2 (L2) requiere solo una asignación de VLAN.
    • Una red troncal requiere la asignación de varias VLAN.
  • Determine cuántas redes de cada tipo necesita.
  • Determine el tamaño de MTU de cada una de las redes (el máximo es 9000).
  • Determine la información de emparejamiento de BGP para cada red y si necesitan comunicarse entre sí. Debe agrupar las redes que tienen que comunicarse entre sí en el mismo dominio de aislamiento L3, ya que cada dominio de aislamiento L3 puede admitir varias redes L3.
  • La plataforma proporciona un proxy para permitir que la máquina virtual alcance otros puntos de conexión externos. La creación de una instancia cloudservicesnetwork requiere del uso de proxy para los puntos de conexión y, así, recopilar la lista de puntos de conexión. Puede modificar la lista de puntos de conexión después de la creación de la red.

Creación de dominios de aislamiento

Los dominios de aislamiento permiten la comunicación entre las cargas de trabajo hospedadas en el mismo bastidor (comunicación dentro del bastidor) o en bastidores diferentes (comunicación entre bastidores). Puede encontrar más detalles sobre cómo crear dominios de aislamiento aquí.

Creación de redes para cargas de inquilino

En las secciones siguientes, se describe cómo crear estas redes:

  • Red de capa 2
  • Red de capa 3
  • Red troncal

Creación de una red L2

Cree una red L2, en caso de que sea necesario, para las cargas de trabajo. Puede repetir las instrucciones para cada red L2 necesaria.

Recopile el id. de recurso del dominio de aislamiento L2 que ha creado para configurar la VLAN para esta red.

  az networkcloud l2network create --name "<YourL2NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --l2-isolation-domain-id "<YourL2IsolationDomainId>"

Creación de una red L3

Cree una red L3, en caso de que sea necesario, para las cargas de trabajo. Repita las instrucciones para cada red L3 necesaria.

Necesita:

  • El valor resourceID del dominio de aislamiento L3 que ha creado para configurar la VLAN de esta red.
  • El valor ipv4-connected-prefix, que debe coincidir con el valor i-pv4-connected-prefix que se encuentra en el dominio de aislamiento L3.
  • El valor ipv6-connected-prefix, que debe coincidir con el valor i-pv6-connected-prefix que se encuentra en el dominio de aislamiento L3.
  • El valor ip-allocation-type, que puede ser IPv4, IPv6 o DualStack (predeterminado).
  • El valor vlan, que debe coincidir con lo que se encuentra en el dominio de aislamiento L3.
  az networkcloud l3network create --name "<YourL3NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --ip-allocation-type "<YourNetworkIpAllocation>" \
    --ipv4-connected-prefix "<YourNetworkIpv4Prefix>" \
    --ipv6-connected-prefix "<YourNetworkIpv6Prefix>" \
    --l3-isolation-domain-id "<YourL3IsolationDomainId>" \
    --vlan <YourNetworkVlan>

Creación de una red troncal

Cree una red troncal, en caso de que sea necesario, para la máquina virtual. Repita las instrucciones para cada red troncal necesaria.

Recopile los valores resourceId de los dominios de aislamiento L2 y L3 que ha creado anteriormente para configurar las VLAN para esta red. Puede incluir todos los dominios de aislamiento L2 y L3, según sea necesario.

  az networkcloud trunkednetwork create --name "<YourTrunkedNetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --interface-name "<YourNetworkInterfaceName>" \
    --isolation-domain-ids \
      "<YourL3IsolationDomainId1>" \
      "<YourL3IsolationDomainId2>" \
      "<YourL2IsolationDomainId1>" \
      "<YourL2IsolationDomainId2>" \
      "<YourL3IsolationDomainId3>" \
    --vlans <YourVlanList>

Creación de una red de servicios en la nube

Para crear una máquina virtual (VM) de Operator Nexus o un clúster de Kubernetes de Operator Nexus, debe tener una red de servicios en la nube. Sin esta red, no se puede crear una máquina virtual ni un clúster.

Aunque la red de servicios en la nube permite automáticamente el acceso a puntos de conexión de plataforma esenciales, debe agregar otros, como docker.io, cuando la aplicación los requiera. La configuración del proxy de red de servicios en la nube es un paso fundamental para garantizar una conexión correcta a los puntos de conexión deseados. Para ello, puede agregar los puntos de conexión de salida a la red de servicios en la nube durante la creación inicial o como actualización, mediante el parámetro --additional-egress-endpoints. Aunque el uso de caracteres comodín para los puntos de conexión de dirección URL puede parecer práctico, no se recomiendan por motivos de seguridad. Por ejemplo, si desea configurar el proxy para permitir la extracción de imágenes de cualquier repositorio hospedado fuera de docker.io, puede especificar .docker.io como punto de conexión.

Los puntos de conexión de salida deben cumplir las estructuras de nombres de dominio y las especificaciones de nombre de host descritas en RFC 1034, RFC 1035 y RFC 1123. Los nombres de dominio válidos incluyen caracteres alfanuméricos, guiones (no al principio o al final) y pueden tener subdominios separados por puntos. Los puntos de conexión pueden ser un único nombre de dominio completo o un subdominio (prefijo de dominio con un .). Estos son algunos ejemplos para demostrar las convenciones de nomenclatura compatibles para los nombres de dominio y host.

  • contoso.com: el dominio base, que actúa como un dominio de segundo nivel en el dominio de nivel superior .com.
  • sales.contoso.com: un subdominio de contoso.com, que actúa como un dominio de tercer nivel en el dominio de nivel superior .com.
  • web-server-1.contoso.com: un nombre de host para un servidor web específico, que usa guiones para separar palabras y números.
  • api.v1.contoso.com: incorpora dos subdominios (v1 y api) sobre el dominio base contoso.com.
  • .api.contoso.com: un carácter comodín para cualquier subdominio en api.contoso.com, que cubre varios dominios de tercer nivel.
  az networkcloud cloudservicesnetwork create --name "<YourCloudServicesNetworkName>" \
    --resource-group "<YourResourceGroupName >" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId >" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --additional-egress-endpoints "[{\"category\":\"<YourCategory >\",\"endpoints\":[{\"<domainName1 >\":\"< endpoint1 >\",\"port\":<portnumber1 >}]}]"

Después de configurar la red de servicios en la nube, puede usarla para crear una máquina virtual o clúster que pueda conectarse a los puntos de conexión de salida especificados. Recuerde que el proxy solo funciona con HTTPS.

Nota:

Para asegurarse de que la imagen de VNF se pueda extraer correctamente, cerciórese de que la dirección URL de ACR está en la lista de salidas permitidas de la red de servicios en la nube que usará con la máquina virtual Operator Nexus.

Además, si ACR tiene puntos de conexión de datos dedicados habilitados, deberá agregar todos los nuevos puntos de conexión de datos a la lista de salidas permitidas. Para encontrar todos los puntos de conexión posibles para ACR, siga las instrucciones que se encuentran aquí.

Uso del proxy para llegar fuera de la máquina virtual

Tras crear la máquina virtual (VM) de Operator Nexus o un clúster de Kubernetes de Operator Nexus con esta red de servicios en la nube, debe establecer las variables de entorno adecuadas dentro de la máquina virtual para usar el proxy de inquilino y para que el alcance vaya más allá de la máquina virtual. Este proxy de inquilino es útil si necesita acceder a los recursos fuera de la máquina virtual, como administrar paquetes o instalar software.

Para usar el proxy, debe establecer las siguientes variables de entorno:

export HTTPS_PROXY=http://169.254.0.11:3128
export https_proxy=http://169.254.0.11:3128

Después de establecer las variables de entorno de proxy, la máquina virtual podrá acceder a los puntos de conexión de salida configurados.

Nota:

Por motivos de seguridad, no se admite el protocolo HTTP al usar el proxy para acceder a los recursos fuera de la máquina virtual. Es necesario usar HTTPS para garantizar una comunicación segura al administrar paquetes o instalar software en la máquina virtual (VM) de Operator Nexus o el clúster de Kubernetes de Operator Nexus con esta red de servicios en la nube.

Importante

Al usar un proxy, también es importante establecer correctamente la variable de entorno no_proxy. Esta variable se puede usar para especificar dominios o direcciones IP a las que no se debe tener acceso a través del proxy. Si no se establece correctamente, puede causar problemas al acceder a los servicios, como el servidor de API de Kubernetes o la dirección IP del clúster. Asegúrese de incluir la dirección IP o el nombre de dominio del servidor de API de Kubernetes y las direcciones IP del clúster de la variable no_proxy.

Zona de disponibilidad del clúster de Nexus Kubernetes

Al crear un clúster de Nexus Kubernetes, puede programarlo en bastidores específicos o distribuirlo entre varios bastidores. Esta técnica puede mejorar el uso de recursos y la tolerancia a errores.

Si no especifica una zona al crear un clúster de Nexus Kubernetes, la plataforma Azure Operator Nexus implementará automáticamente una regla de antiafinidad predeterminada para distribuir la máquina virtual entre bastidores y nodos de equipo sin sistema operativo y no está garantizada. Esta regla también tiene como objetivo evitar la programación de la máquina virtual del clúster en un nodo que ya tiene una máquina virtual del mismo clúster, pero es un principio de máximo esfuerzo que no puede ofrecer garantías.

Para obtener la lista de zonas disponibles en la instancia de Operator Nexus de Azure especificada, puede usar el siguiente comando:

    az networkcloud cluster show \
      --resource-group <Azure Operator Nexus on-premises cluster resource group> \
      --name <Azure Operator Nexus on-premises cluster name> \
      --query computeRackDefinitions[*].availabilityZone