Editar

Arquitectura de red para AKS en Azure Stack HCI

Azure Stack
Windows Server

En este escenario se ilustra cómo diseñar e implementar conceptos de red para implementar nodos de Azure Kubernetes Service (AKS) en clústeres de AKS híbrido.

En este artículo se incluyen recomendaciones para el diseño de redes para nodos y contenedores de Kubernetes. Forma parte de un conjunto de instrucciones de referencia arquitectónica compuesto por dos artículos. Consulte las recomendaciones de arquitectura de base de referencia aquí.

Architecture

En la imagen siguiente se muestra la arquitectura de red para Azure Kubernetes Service en clústeres de centros de datos de Azure Stack HCI o Windows Server 2019 o 2022:

Conceptual graphic showing network baseline architecture.

Descargue un archivo Visio de esta arquitectura.

El escenario consta de los componentes y las funcionalidades siguientes:

  • Azure Stack HCI (20H2) es una solución de clúster de infraestructura hiperconvergida (HCI) que hospeda cargas de trabajo virtualizadas de Windows y Linux y su almacenamiento en un entorno local híbrido. El clúster de Azure Stack HCI se implementa como un clúster de 2 a 4 nodos.
  • Un clúster de conmutación por error de un centro de datos de Windows Server 2019 o 2022 es un grupo de equipos independientes que trabajan juntos para aumentar la disponibilidad y la escalabilidad de los roles en clúster.
  • Azure Kubernetes Service en Azure Stack HCI (AKS híbrido) es una implementación local de Azure Kubernetes Service (AKS) que automatiza la ejecución de aplicaciones en contenedores a gran escala.
  • [Active Directory Domain Services] [] es una estructura jerárquica que almacena información sobre los objetos de la red. Proporciona una solución de identidad y acceso para identidades asociadas a usuarios, equipos, aplicaciones u otros recursos que se incluyen en un límite de seguridad.
  • [Clúster de administración] [] también conocido como host de AKS es responsable de implementar y administrar varios clústeres de cargas de trabajo. El clúster de administración consume 1 dirección IP del grupo de nodos, pero debe reservar otras 2 direcciones IP para las operaciones de actualización. El clúster de administración también consume una dirección IP del grupo de direcciones VIP.
  • [Clúster de cargas de trabajo] [] es una implementación de alta disponibilidad de Kubernetes mediante máquinas virtuales Linux para ejecutar componentes del plano de control de Kubernetes y nodos de trabajo de Linux o Windows.
    • Plano de control Se ejecuta en una distribución de Linux y contiene componentes del servidor de API para la interacción con la API de Kubernetes y un almacén de pares clave-valor distribuido, etcd, para almacenar toda la configuración y los datos del clúster. Consume una dirección IP del grupo de nodos y una dirección IP del grupo de direcciones VIP.
    • Equilibrador de carga. Se ejecuta en una máquina virtual Linux y proporciona servicios con equilibrio de carga para el clúster de cargas de trabajo. Consume una dirección IP del grupo de nodos y una dirección IP del grupo de direcciones VIP.
    • Nodos de trabajo. Se ejecutan en un sistema operativo Windows o Linux que hospeda aplicaciones contenedorizadas. Consume direcciones IP del grupo de nodos, pero debe planear al menos tres direcciones IP más para las operaciones de actualización.
    • Recursos de Kubernetes. Los pods representan una instancia única de la aplicación, que normalmente tiene una asignación 1:1 con un contenedor, pero determinados pods pueden contener varios contenedores. Las implementaciones representan uno o varios pods idénticos. Los pods y las implementaciones se agrupan lógicamente en un espacio de nombres que controla el acceso a la administración de los recursos. Consumen 1 dirección IP por pod del grupo de direcciones VIP.
  • [Azure Arc] [] es un servicio basado en la nube que extiende el modelo de administración basado en Azure Resource Manager a recursos que no son de Azure, como máquinas virtuales (VM), clústeres de Kubernetes y bases de datos en contenedores.
  • [Azure Policy] [] es un servicio basado en la nube que evalúa los recursos locales y de Azure mediante la integración con Azure Arc mediante la comparación de propiedades con reglas de negocio personalizables.
  • [Azure Monitor] [] es un servicio basado en la nube que maximiza la disponibilidad y el rendimiento de las aplicaciones y los servicios al ofrecer una solución completa para recopilar, analizar y actuar sobre la telemetría de los entornos locales y en la nube.
  • [Microsoft Defender for Cloud] [] es un sistema unificado de administración de seguridad de infraestructura que refuerza la posición de seguridad de los centros de datos y proporciona protección contra amenazas avanzada en las cargas de trabajo híbridas en la nube y en el entorno local.

Componentes

  • [Azure Stack HCI (20H2)] [1]
  • [Clúster de conmutación por error del centro de datos de Windows Server 2019/2022] []
  • [Azure Kubernetes Service (AKS)][]
  • [Windows Admin Center] []
  • [Una suscripción de Azure] []
  • [Azure Arc] [2]
  • [Control de acceso basado en rol de Azure (RBAC)] []
  • [Azure Monitor] [3]
  • [Microsoft Defender for Cloud] [4]

Detalles del escenario

Los casos de uso de este escenario se describen en el primer artículo de la serie, Arquitectura de base de referencia.

Redes de nodo de Kubernetes

Un aspecto importante en el diseño de redes para AKS en Azure Stack HCI es seleccionar el modelo de red que proporcione suficientes direcciones IP. AKS en Azure Stack HCI usa redes virtuales para asignar direcciones IP a los recursos del nodo de Kubernetes. Puede usar dos modelos de asignación de direcciones IP:

  • Las redes IP estáticas son más predecibles, pero agregan un esfuerzo adicional a la configuración inicial.
  • Las redes del protocolo de configuración dinámica de host (DHCP) usan la asignación dinámica de direcciones IP y requieren menos esfuerzo, pero debe tener cuidado de no agotar el grupo de direcciones IP disponibles. También tiene que administrar reservas e intervalos de exclusión para grupos de direcciones IP virtuales y determinados recursos de todo el clúster, como el servicio del agente en la nube.

Ambos modelos de asignación deben prever direcciones IP para:

  • Grupo de direcciones IP virtuales
  • Grupo de IP de VM de los nodos de Kubernetes

Grupo de direcciones IP virtuales

Un grupo de direcciones IP virtuales (VIP) es un conjunto de direcciones IP que son obligatorias para cualquier implementación de AKS en Azure Stack HCI. Prevea un número de direcciones IP del grupo de direcciones IP virtuales según el número de clústeres de las cargas de trabajo y servicios de Kubernetes. El grupo de direcciones IP virtuales proporciona direcciones IP para los siguientes tipos de recursos:

  • El agente en la nube requiere una dirección IP flotante del grupo de direcciones IP virtuales.

  • El componente de servidor de la API que se ejecuta dentro de la máquina virtual de la aplicación virtual de Kubernetes (KVA) usa una dirección IP del grupo de direcciones IP virtuales. El servidor de API es un componente del plano de control de Kubernetes que expone la API de Kubernetes. El servidor de API es el front-end del plano de control de Kubernetes. La KVA es una máquina virtual que ejecuta Mariner Linux y hospeda un clúster de Kubernetes. La dirección IP es flotante y también se usa para cualquier otra máquina virtual de KVA que implemente en AKS en Azure Stack HCI. La máquina virtual de KVA también hospeda un servicio de equilibrador de carga de IP virtual de Kubernetes.

  • Planee el direccionamiento IP para el número de máquinas virtuales del plano de control que se implementan en los servidores de destino, ya que también consumen más direcciones IP del grupo de direcciones IP virtuales. En la siguiente sección se describen otros aspectos.

  • El clúster de destino contiene una máquina virtual del equilibrador de carga, que es HAProxy y posee el grupo de direcciones IP virtuales del clúster de destino. Esta máquina virtual expone todos los servicios de Kubernetes a través del grupo de direcciones IP virtuales.

  • Las aplicaciones que se ejecutan en pods de Kubernetes usan direcciones IP del grupo de direcciones IP virtuales.

  • El equilibrador de carga HAProxy se implementa como una máquina virtual especializada y se puede usar para equilibrar la carga de las solicitudes entrantes en varios puntos de conexión. Consumen direcciones IP del grupo de direcciones IP virtuales y debe prever direcciones IP para cada clúster de cargas de trabajo.

Grupo de IP de VM de los nodos de Kubernetes

Los nodos de Kubernetes se implementan como máquinas virtuales en una implementación de AKS en Azure Stack HCI. Asegúrese de prever el número de direcciones IP según el número total de nodos de Kubernetes e incluir al menos tres direcciones IP más para que se usen durante el proceso de actualización. Para la configuración de direcciones IP estáticas, tiene que especificar el intervalo de grupos de direcciones IP de la máquina virtual del nodo de Kubernetes. Esto no es necesario para la asignación de DHCP. Prevea direcciones IP adicionales para:

  • La máquina virtual de KVA también usa más direcciones IP para Kubernetes del grupo de direcciones IP de la máquina virtual del nodo de Kubernetes. Prevea que tendrá que agregar direcciones IP durante el proceso de actualización, ya que la máquina virtual de KVA usa la misma dirección IP virtual para el servicio de API, pero requiere una dirección IP independiente del grupo de direcciones IP de la máquina virtual del nodo de Kubernetes.
  • Las máquinas virtuales del plano de control consumen una dirección IP del grupo de direcciones IP de la máquina virtual del nodo de Kubernetes para el servicio de servidor de API. Estas máquinas virtuales también hospedan el agente de Azure ARC que se conecta a Azure Portal con fines de administración.
  • Los nodos de un grupo de nodos (Linux o Windows) consumirán direcciones IP del grupo de direcciones IP asignado a la máquina virtual del nodo de Kubernetes.

Servicio en la nube local de Microsoft

Prevea un intervalo de direcciones IP para la nube local de Microsoft (MOC) que permita la pila de administración para que las máquinas virtuales de Azure Stack HCI se administren en la nube. La asignación de direcciones IP del servicio MOC se realiza en la red física subyacente y las direcciones IP configuradas para los nodos del clúster de Azure Stack HCI se encuentran en el centro de datos. Puede configurar direcciones IP para los nodos físicos de Azure Stack HCI con una de las siguientes opciones:

  • Nodos de clúster de Azure Stack HCI con un modo de asignación de direcciones IP basado en DHCP. El servicio MOC obtiene una dirección IP del servicio DHCP presentado en la red física.
  • Nodos de clúster de Azure Stack HCI con un modelo de asignación de direcciones IP estáticas. La dirección IP del servicio en la nube MOC debe especificarse explícitamente como un intervalo IP en formato de Enrutamiento de interdominios sin clases (CIDR) y debe estar en la misma subred que las direcciones IP de los nodos del clúster de Azure Stack HCI.

Equilibrador de carga en AKS en Azure Stack HCI

Para una implementación pequeña, puede usar el equilibrador de carga integrado, implementado como una máquina virtual Linux que usa HAProxy + KeepAlive para enviar tráfico a los servicios de la aplicación que se implementan como parte del clúster de AKS. El equilibrador de carga HAProxy configura pods como puntos de conexión del equilibrador de carga. Equilibra la carga de las solicitudes al servidor de API de Kubernetes y administra el tráfico a los servicios de aplicación.

También puede usar un equilibrador de carga personalizado para administrar el tráfico a los servicios. El equilibrador de carga personalizado proporciona flexibilidad adicional a la implementación y garantiza que AKS en Azure Stack HCI funciona junto con las implementaciones existentes como, por ejemplo, las implementaciones de redes definidas por software (SDN) que usan equilibradores de carga. En el caso de los equilibradores de carga personalizados, kube-virtual IP proporciona clústeres de Kubernetes con una dirección IP virtual y un equilibrador de carga para el plano de control y para Kubernetes Service del tipo LoadBalancer. El servicio kube-virtual IP se implementa automáticamente en cada nodo de trabajo.

AKS en Azure Stack HCI también admite el uso de MetalLB u otros equilibradores de carga de software de código abierto basados en Kubernetes para equilibrar el tráfico destinado a los servicios de un clúster de cargas de trabajo. MetalLB es una implementación de un equilibrador de carga para clústeres de Kubernetes sin sistema operativo, que usa protocolos de enrutamiento estándar, como el Protocolo de puerta de enlace de borde (BGP). Puede funcionar con complementos de red, Calico y Flannel, pero debe asegurarse de que el intervalo de direcciones IP virtuales proporcionado durante la instalación de AKS en Azure Stack HCI no se superpone con el intervalo de direcciones IP planeado para el equilibrador de carga personalizado.

Implementación de este escenario

Implementación de un controlador de entrada

Considere la posibilidad de implementar un [controlador de entrada][] para la terminación TLS, proxy reversible o enrutamiento de tráfico configurable. Los controladores de entrada funcionan en la capa 7 y pueden usar reglas inteligentes para distribuir el tráfico de las aplicaciones. Los recursos de entrada de Kubernetes se usan para configurar las reglas de entrada y las rutas de los distintos servicios de Kubernetes. Al definir un controlador de entrada, se consolidan las reglas de enrutamiento de tráfico en un único recurso que se ejecuta como parte del clúster.

Uso de un controlador de entrada para exponer servicios a través de direcciones URL accesibles externamente. La entrada expone rutas HTTP y HTTPS desde fuera del clúster a los servicios del clúster. El enrutamiento del tráfico se controla mediante reglas definidas en el recurso de entrada. Las reglas HTTP de entrada contienen la siguiente información:

  • Un host opcional. Si no proporciona información de host, la regla se aplica a todo el tráfico HTTP entrante.
  • Lista de rutas de acceso que tiene un back-end asociado definido con un service.name y un service.port.name o service.port.number.
  • Back-end que proporciona una combinación de nombres de servicio y puerto.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Use un controlador de entrada para equilibrar el tráfico entre distintos back-end de la aplicación. El tráfico se divide y se envía a diferentes puntos de conexión de servicio e implementaciones, en función de la información de la ruta de acceso.

Para enrutar el tráfico HTTP a varios nombres de host en la misma dirección IP, puede usar un recurso de entrada diferente para cada host. El tráfico que llega a través de la dirección IP del equilibrador de carga se enruta según el nombre de host y la ruta de acceso proporcionada en la regla de entrada.

Conceptos sobre redes de contenedores en Azure Kubernetes Service (AKS) en Azure Stack HCI

Kubernetes proporciona una capa de abstracción a una red virtual, por lo que las aplicaciones basadas en contenedores pueden comunicarse interna o externamente. El componente kube-proxy se ejecuta en cada nodo y puede proporcionar acceso directo al servicio, distribuir el tráfico mediante equilibrios de carga o usar controladores de entrada para un enrutamiento de aplicaciones más complejo. Kubernetes utiliza servicios para agrupar lógicamente un conjunto de pods y proporcionar conectividad de red. Están disponibles los siguientes servicios de Kubernetes:

  • IP del clúster: este servicio crea una dirección IP interna solo para aplicaciones internas.
  • NodePort: este servicio crea una asignación de puertos en el nodo subyacente, que permite acceder a la aplicación directamente con la dirección IP y el puerto del nodo.
  • LoadBalancer: puede exponer servicios de Kubernetes externamente mediante reglas de equilibrador de carga o un controlador de entrada.
  • ExternalName: este servicio usa una entrada DNS específica para la aplicación de Kubernetes.

Redes de Kubernetes

En AKS en Azure Stack HCI, el clúster se puede implementar mediante uno de los siguientes modelos de red:

  • [Redes de Project Calico] []. Se trata de un modelo de red predeterminado para AKS en Azure Stack HCI y se basa en una red de código abierto que proporciona seguridad de red para contenedores, máquinas virtuales y cargas de trabajo nativas basadas en host. La directiva de red de Calico se puede aplicar en cualquier tipo de punto de conexión, como pods, contenedores, máquinas virtuales o interfaces de host. Cada directiva consta de reglas que controlan el tráfico de entrada y salida mediante acciones que pueden, ya sea permitir, denegar, registrar o pasar el tráfico entre los puntos de conexión de origen y destino. Calico puede usar el filtro de paquetes extendido de Berkeley para Linux (eBPF) o la canalización de redes de kernel de Linux para la entrega del tráfico. Calico también se admite en Windows y utiliza el servicio de redes de host (HNS) para crear espacios de nombres de red por punto de conexión de contenedor. En el modelo de red de Kubernetes, cada pod obtiene su propia dirección IP que se comparte entre los contenedores de ese pod. Los pods se comunican en la red mediante direcciones IP de pod y el aislamiento se define con directivas de red. Calico usa complementos de CNI (interfaz de red de contenedor) para agregar pods a la red de pods de Kubernetes o eliminarlos de esta, y complementos IPAM (administración de direcciones IP) de CNI para asignar y liberar direcciones IP.
  • [Redes de superposición de Flannel.] [] Flannel crea una capa de red virtual que superpone la red host. Las redes superpuestas usan la encapsulación de los paquetes de red a través de la red física existente. Flannel simplifica la administración de direcciones IP (IPAM), admite el uso de direcciones IP entre diferentes aplicaciones y espacios de nombres, y proporciona una separación lógica de las redes de contenedores de la red subyacente que usan los nodos de Kubernetes. El aislamiento de red se logra mediante una red de área local virtual extensible (VXLAN), un protocolo de encapsulación que proporciona conectividad con el centro de datos mediante la tunelización para ajustar las conexiones del nivel 2 mediante una red subyacente de nivel 3. Flannel es compatible con contenedores de Linux que usan DaemonSet y contenedores de Windows que usan el complemento de CNI de Flannel.

Diseño de redes de Azure Stack HCI

El diseño general de redes incluye actividades de planeamiento de Azure Stack HCI.

En primer lugar, empiece por planear el hardware y la instalación de Azure Stack HCI. Puede adquirir sistemas integrados de cualquier asociado de hardware de Microsoft con el sistema operativo Azure Stack HCI preinstalado, o bien comprar nodos validados e instalar el sistema operativo usted mismo. Azure Stack HCI está pensado como un host de virtualización, por lo que los roles de servidor deben ejecutarse dentro de máquinas virtuales.

Requisitos de red física para Azure Stack HCI

Microsoft no certifica los conmutadores de red, pero tiene ciertos requisitos que el proveedor del equipo debe cumplir:

  • Estándar IEEE 802.1Q que define una red de área local virtual (VLAN).
  • Estándar IEEE 802.1Qbb que define el control de flujos basado en prioridades (PFC).
  • Estándar IEEE 802.1Qaz que define la selección de transmisión mejorada (ETS).
  • Estándar IEEE 802.1AB que define el protocolo de detección de topologías del nivel de vínculo (LLTD).

Requisitos de red de host para Azure Stack HCI

Considere la posibilidad de usar un adaptador de red que haya logrado la certificación de centro de datos definido por software (SDDC) de Windows Server con la calificación adicional (AQ) Estándar o Premium.

Asegúrese de que el adaptador de red admite:

  • [Cola múltiple de máquina virtual dinámica] [] (Dynamic VMMQ o d.VMMQ) es una tecnología inteligente y de recepción para el ajuste automático del procesamiento del tráfico de red a núcleos de CPU.
  • El acceso directo a memoria remota (RDMA) es una descarga de pila de red en el adaptador de red. Permite que el tráfico de almacenamiento del bloque de mensajes del servidor omita el sistema operativo en el procesamiento.
  • RDMA de invitado permite que las cargas de trabajo de SMB de las máquinas virtuales disfruten de las mismas ventajas que con el uso de RDMA en los hosts.
  • Switch Embedded Teaming (SET) es una tecnología de formación de equipos basada en software.

Considere la posibilidad de usar [Network ATC][], que proporciona control basado en intenciones para simplificar la configuración de redes de host.

AKS en Azure Stack HCI requiere una conexión de red confiable de baja latencia y gran ancho de banda entre cada nodo de servidor. Asegúrese de que, al menos, un adaptador de red está disponible y dedicado para la administración del clúster. Compruebe también que los conmutadores físicos de la red estén configurados para permitir el tráfico en cualquier VLAN que utilice.

Conmutador virtual

Azure Stack HCI simplifica el diseño de red mediante la configuración de un conmutador virtual que se puede usar para la clasificación de red. La tarjeta de interfaz de red virtual (vNIC) se puede colocar en diferentes VLAN para que los hosts proporcionen un flujo de tráfico diferente para las redes siguientes:

  • Red de administración. La red de administración forma parte de la red vertical de arriba abajo y se usa para la comunicación con el host.
  • Red de proceso. La red de proceso forma parte de la red vertical de arriba abajo y se usa para el tráfico de la máquina virtual. Use calidad de servicio (QOS), virtualización de E/S de raíz única (SR-IOV) y acceso directo a memoria remota virtual (vRDMA) para ajustar el rendimiento de la red en función de la demanda.
  • Red de almacenamiento. La red de almacenamiento forma parte de la red horizontal de derecha a izquierda y requiere RDMA con un rendimiento recomendado de 10 GB como mínimo. Se usa para la migración en vivo de las máquinas virtuales.
  • Red de invitado de la máquina virtual.

Ventaja del tráfico horizontal de derecha a izquierda del tráfico RDMA

El tráfico de red horizontal de derecha a izquierda representa la comunicación entre los hosts y no expone ningún acceso externo. El tráfico permanece dentro de los conmutadores ToR (parte superior del bastidor) y el límite de capa 2 (VLAN). Incluye los siguientes tipos de tráfico:

  • Latidos del clúster y comunicación entre nodos
  • [SMB] Capa de bus de almacenamiento
  • [SMB] Volumen compartido de clúster
  • [SMB] Recompilación de almacenamiento

Tráfico vertical de arriba abajo

El tráfico vertical de arriba abajo es el tráfico externo que llega al clúster de AKS en Azure Stack HCI. Puede prever el tráfico de la gama de servicios de Azure que permiten la supervisión, facturación y administración de seguridad mediante la integración de Azure ARC. El tráfico vertical de arriba abajo tiene las siguientes características:

  • El tráfico fluye desde un conmutador ToR hacia el tronco o viceversa.
  • El tráfico sale del bastidor físico o cruza un límite de capa 3 (IP).
  • Incluye tráfico de administración (PowerShell, Windows Admin Center), tráfico de proceso (VM) y tráfico de clúster extendido entre sitios.
  • Usa un conmutador Ethernet para la conectividad a la red física.

AKS en Azure Stack HCI puede usar varias opciones de implementación de red de clúster:

  • Red convergente que combina varias intenciones de red (MGMT, proceso, almacenamiento). Esta es la implementación recomendada para más de tres nodos físicos y requiere que todos los adaptadores de red físicos estén conectados a los mismos conmutadores ToR. ROCEv2 es muy recomendable.
  • La implementación sin conmutador usa comunicación vertical de arriba abajo como equipo de red mediante la combinación de redes de proceso y administración.
  • Implementación híbrida como una combinación de ambas implementaciones.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que la invalide.

Recomendaciones de red

La principal preocupación en el diseño de redes para AKS en Azure Stack HCI es seleccionar un modelo de red que proporcione suficientes direcciones IP para el clúster de Kubernetes y sus servicios y aplicaciones.

  • Considere la posibilidad de implementar direcciones IP estáticas para permitir que AKS en Azure Stack HCI controle la asignación de direcciones IP.

  • Dimensione correctamente los intervalos de direcciones IP para que tenga suficientes direcciones IP libres para un grupo de nodos de Kubernetes y para un grupo de direcciones IP virtuales. Asegúrese de que el grupo de direcciones IP virtuales es lo suficientemente grande para que cada vez que actualice pueda usar actualizaciones graduales, las cuales requieren más direcciones IP. Puede planear lo siguiente:

    • Direccionamiento o nombres de host para la configuración del proxy
    • Direcciones IP para el plano de control del clúster de destino
    • Direcciones IP para Azure ARC
    • Direcciones IP para el escalado horizontal de nodos del plano de trabajo y de control en clústeres de destino

  • El grupo de direcciones IP virtuales debe ser lo suficientemente grande como para admitir la implementación de los servicios de aplicación que requieren conectividad con el enrutador externo.

  • Implemente CNI de Calico para proporcionar una directiva de red mejorada que controle la comunicación entre pods y aplicaciones.

  • Asegúrese de que los nodos de clúster físicos (HCI o Windows Server) se encuentren en el mismo bastidor y estén conectados a los mismos conmutadores ToR.

  • Deshabilite IPv6 en todos los adaptadores de red.

  • Asegúrese de que el conmutador virtual existente y su nombre sean los mismos en todos los nodos del clúster.

  • Compruebe que todas las subredes que defina para el clúster se puedan enrutar entre sí y a Internet.

  • Asegúrese de que haya conectividad de red entre los hosts de Azure Stack HCI y las VM de inquilino.

  • Habilite las actualizaciones de DNS dinámicas en el entorno DNS para permitir que AKS en Azure Stack HCI registre el nombre genérico del clúster del agente en la nube en el sistema DNS para su detección.

  • Considere la posibilidad de implementar la clasificación del tráfico de red por su dirección:

    • El tráfico vertical de arriba abajo es el tráfico de Azure Stack HCI y el resto de la red,
      • Administración
      • Proceso
      • Tráfico del clúster extendido entre sitios
    • Tráfico horizontal de derecha a izquierda dentro de Azure Stack HCI:
      • Tráfico de almacenamiento que incluye la migración en vivo entre nodos del mismo clúster.
      • Conmutador Ethernet o conexión directa.

Modelos de tráfico de almacenamiento

  • Use varias subredes y VLAN para separar el tráfico de almacenamiento en Azure Stack HCI.
  • Considere la posibilidad de implementar la asignación de ancho de banda de tráfico de varios tipos de tráfico.

Consideraciones

El [Marco de buena arquitectura de Microsoft Azure][] es un conjunto de principios de orientación que se siguen en este escenario. Las consideraciones siguientes se enmarcan en el contexto de estos principios.

Confiabilidad

  • Resistencia integrada, inherente al proceso definido por software de Microsoft (clúster de conmutación por error de nodos de Hyper-V), almacenamiento (resistencia anidada de Espacios de almacenamiento directo) y redes (redes definidas por software).
  • Considere la posibilidad de seleccionar el conmutador de red que admite estándares del sector y garantiza comunicaciones confiables entre nodos. Entre los siguientes estándares se incluyen:
    • Estándar: IEEE 802.1Q
    • Estándar IEEE 802.1Qbb
    • Estándar IEEE 802.1 Qas
    • Estándar IEEE 802.1 AB
  • Considere la posibilidad de implementar varios hosts en el clúster de administración y en el clúster de Kubernetes para satisfacer el nivel mínimo de disponibilidad de las cargas de trabajo.
  • AKS en Azure Stack HCI usa clústeres de conmutación por error y migración en vivo para conseguir una alta disponibilidad y tolerancia a errores. La migración en vivo es una característica de Hyper-V que permite trasladar máquinas virtuales en ejecución desde un host de Hyper-V a otro sin que se perciba tiempo de inactividad y de manera transparente.
  • Debe asegurarse de que los servicios a los que se hace referencia en la sección Arquitectura se admiten en la región en la que se implementa Azure Arc.

Seguridad

  • Protección del tráfico entre pods mediante directivas de red en AKS en Azure Stack HCI
  • El servidor de API de AKS en Azure Stack HCI contiene la entidad de certificación que firma los certificados para la comunicación desde el servidor de API de Kubernetes a kubelet.
  • Use el inicio de sesión único (SSO) de Microsoft Entra para crear una conexión segura con el servidor de API de Kubernetes.
  • Puede usar Azure RBAC para administrar el acceso a Kubernetes habilitado para Azure Arc–en entornos locales y de Azure mediante identidades de Microsoft Entra. Para más información, vea [Uso de Azure RBAC para la autorización de Kubernetes][].

Optimización de costos

  • Use la [Calculadora de precios de Azure][] para calcular los costos de los servicios usados en la arquitectura. Otros procedimientos recomendados se describen en la sección [optimización de costos][] de [Marco de buena arquitectura de Microsoft Azure.][]
  • Considere la posibilidad de implementar hyper-threading en el equipo físico para optimizar el costo, ya que la unidad de facturación de AKS en Azure Stack HCI es un núcleo virtual.
  • La funcionalidad del plano de control de Azure Arc se proporciona sin coste adicional. Esto incluye el apoyo a la organización de los recursos a través de los grupos de gestión y las etiquetas de Azure, y el control de acceso mediante Azure RBAC. Los servicios de Azure utilizados conjuntamente con los servidores habilitados para Azure Arc incurren en costes en función de su uso.
  • En cuanto a rentabilidad, puede usar tan solo dos nodos de clúster con cuatro discos y 64 gigabytes (GB) de memoria por nodo. Para reducir aún más los costos, puede usar interconexiones sin conmutador entre nodos, lo que elimina la necesidad de dispositivos de conmutación redundantes.

Excelencia operativa

  • Administración simplificada mediante Windows Admin Center. Windows Admin Center es la interfaz de usuario para crear y administrar AKS en Azure Stack HCI. Se puede instalar en Windows 10/11 o en una máquina virtual de Windows Server que se debe registrar en Azure y que esté en el mismo dominio que el clúster de Azure Stack HCI o Windows Server Datacenter.
  • Integración con Azure Arc o una gama de servicios de Azure que proporcionan más funcionalidades de administración, mantenimiento y resistencia (Azure Monitor, Azure Backup).
  • Si el clúster de Kubernetes está [asociado a Azure Arc][Servicio kubernetes habilitado para Azure Arc–], puede [administrar el clúster de Kubernetes mediante GitOps][]. Para revisar los procedimientos recomendados para conectar un clúster híbrido de Kubernetes a Azure Arc, vea el escenario [Administración e implementación híbridas de Azure Arc para clústeres de Kubernetes][].
  • La plataforma de Azure Stack HCI también ayuda a simplificar las redes virtuales para los clústeres de AKS en Azure Stack HCI al proporcionar la red "subyacente" con una alta disponibilidad.

Eficiencia del rendimiento

  • Use hardware certificado de Azure Stack HCI para mejorar el rendimiento y el tiempo de actividad de la aplicación, obtener administración y operaciones simplificadas, y reducir el costo total de propiedad.
  • Almacenamiento: Espacios de almacenamiento directo
    • Configuración del volumen (reflejo bidireccional anidado en comparación con la paridad acelerada por reflejo anidado)
    • Configuración de disco (almacenamiento en caché, niveles)
  • Asegúrese de que los nodos de clúster se encuentren físicamente en el mismo bastidor y estén conectados a los mismos conmutadores ToR.
  • Planee las reservas de direcciones IP para configurar hosts de AKS, clústeres de cargas de trabajo, servidores de API de clúster, Kubernetes Service y servicios de aplicación. Microsoft recomienda reservar un mínimo de 256 direcciones IP para la implementación de AKS en Azure Stack HCI.
  • Considere la posibilidad de implementar un controlador de entrada que funcione en la capa 7 y use reglas más inteligentes para distribuir el tráfico de la aplicación.
  • Use la aceleración de la unidad de procesamiento gráfico (GPU) para cargas de trabajo extensas.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Pasos siguientes