La información incluida en esta página y sus subsecciones se aplica cuando el usuario decidió migrar el pod de first-gen con el tipo de AKS para la implementación de Horizon Edge Gateway.
Introducción
Estas secciones describen los requisitos específicos relacionados con AKS que debe cumplir antes de ejecutar el asistente de migración.
En esta información se presupone que leyó la sección Decidir el tipo de implementación y cumplir sus requisitos, respondió las preguntas y decidió utilizar el tipo de AKS para la migración del pod.
Caso especial: si determinó que la red virtual del pod, incluidas otras redes conectadas, contiene direcciones IP restringidas por AKS
Como se describe en la sección Determinar si la red virtual o las redes conectadas del pod contienen direcciones IP restringidas por AKS, cuando se desea realizar la implementación con el tipo de AKS, pero la red virtual del pod de first-gen o la red local conectada a esa red virtual contienen direcciones IP de los rangos de IP restringidos por AKS, para un tipo de implementación de AKS, se debe:
- Configurar otra red virtual en la suscripción del pod, que no contenga direcciones IP de los rangos restringidos por AKS.
- Crear una nueva subred de administración en esa red virtual, con un CIDR de /26 como mínimo en la subred.
- Asegúrese de que la nueva red virtual y la subred de administración permitan la comunicación de red con los endpoints obligatorios del servicio next-gen, para sus protocolos y puertos obligatorios, de acuerdo con las páginas:
- Emparejar esa nueva red virtual con la red virtual existente del pod.
Una vez completados los cuatro pasos anteriores, utilice la nueva subred de administración y la red virtual cuando cumpla los requisitos descritos en las secciones que aparecen a continuación.
Los rangos de IP restringidos por AKS que se deben evitar son:
- 169.254.0.0/16
- 172.30.0.0./16
- 172.31.0.0/16
- 192.0.2.0/24
Además de evitar los rangos anteriores con la nueva red virtual, también debe evitar el uso de los CIDR que usted y su equipo hayan decidido utilizar para los rangos de IP virtuales de la implementación, que se describen en Tipo de AKS: reservar los rangos de IP virtuales necesarios para evitar conflictos con AKS.
Tipo de AKS: confirmar proveedores de recursos de Azure y registrar nuevos requeridos
El tipo de implementación de Horizon Edge Gateway de AKS requiere un conjunto específico de proveedores de recursos en la suscripción de Microsoft Azure.
En la suscripción del pod de first-gen, confirme que todos los proveedores de recursos siguientes tienen el estado Registered.
Algunos de estos son los mismos que se requieren para una implementación de pods de first-gen. En la tabla se señalan cuáles deben registrarse para el tipo de implementación de AKS.
| Proveedor de recursos | |
|---|---|
| Additional new ones to register for next-gen AKS deployment type |
|
| Needed by next-gen which would've been previously registered for your first-gen pod |
|
Para verificar los proveedores de recursos en la suscripción de Microsoft Azure del pod de first-gen:
- Inicie sesión en Azure Portal y busque la suscripción del pod.
- Haga clic en el nombre de la suscripción y desplácese hacia abajo hasta que vea la opción de menú
(Proveedores de recursos). - Busque los proveedores de recursos en la tabla anterior y confirme que cada uno de ellos muestra el estado
(Registrado). Utilice Azure Portal para registrar cualquier proveedor de recursos de la tabla que tenga el estado
NotRegistered.
Es posible que vea que la suscripción del pod tiene los proveedores de recursos necesarios para las instancias de Edge Gateway - next-gen que ya están en estado Registered. También es posible que vea proveedores de recursos registrados, como Microsoft.Billing, que no están relacionados con los requeridos por Horizon Cloud Service. Esta variación potencial del estado se debe al comportamiento estándar de Microsoft Azure, donde suele haber un conjunto de proveedores de recursos ya registrados para todas las suscripciones de Azure.
Tipo de AKS: configurar una puerta de enlace NAT o una tabla de rutas y asociarla a la subred de administración
Para su comunicación saliente con el plano de control de nube, el tipo de AKS de la implementación de Horizon Edge Gateway requiere uno de los siguientes elementos (puerta de enlace NAT o tabla de rutas) asociado a su subred de administración.
En la suscripción de Microsoft Azure del pod, cree la que desee utilizar y asóciela a la subred de administración del pod.
- Puerta de enlace NAT
- Tabla de rutas (esta es una opción más avanzada, que se suele utilizar solo cuando la red virtual del pod ya tiene tablas de rutas que se están utilizando con los pods de first-gen)
Usar una puerta de enlace NAT: crearla y asociarla a una subred de administración
Según la documentación de Microsoft Azure, para crear una puerta de enlace NAT se requiere una dirección IP pública, un prefijo de IP pública o ambos, según su opción de uso.
El asistente Crear puerta de enlace NAT de Azure Portal le requerirá que elija una opción. En los pasos que aparecen a continuación, elegimos crear una nueva dirección IP pública que se utilizará para nuestra puerta de enlace NAT.
- Inicie sesión en Azure Portal, utilice la barra de búsqueda para buscar puertas de enlace NAT y seleccione esa categoría.
- Haga clic en + Crear para iniciar el asistente Crear puerta de enlace NAT.
- En este primer paso del asistente Crear puerta de enlace NAT, asegúrese de que la suscripción del pod esté seleccionada y elija un grupo de recursos en el que residirá la puerta de enlace NAT.
- Asigne un nombre a la puerta de enlace NAT y asegúrese de que la región seleccionada sea la región de Azure del pod. Cuando se complete, haga clic en el paso IP saliente.
La siguiente captura de pantalla es un ejemplo en el que denominamos a nuestra puerta de enlace NAT como first-pod-migration. Reside en la región de Azure West US 2.
- En el paso IP saliente, siga las instrucciones que aparecen en pantalla para seleccionar si desea utilizar una dirección IP pública o prefijos de IP pública para esta puerta de enlace NAT.
La siguiente captura de pantalla es una ilustración de este paso, donde elegimos crear una nueva dirección IP pública para que la utilice esta puerta de enlace NAT y le asignamos el nombre first-pod-NAT-gtway.
Cuando se complete este paso, haga clic en el siguiente paso del asistente, Subnet.
- En el paso Subred del asistente:
- Si no desea tener direcciones IP restringidas por AKS en la red virtual, seleccione la red virtual del pod y su subred de administración.
- De lo contrario, si creó una nueva red virtual y una subred de administración para superar el problema de la red virtual del pod con direcciones IP restringidas por AKS, seleccione la nueva red virtual y la nueva subred de administración.
La siguiente captura de pantalla muestra este paso de selección de la red virtual del pod y su subred de administración, asociando la subred con esta puerta de enlace NAT.
- Haga clic en Revisar y crear.
Si se supera la validación, haga clic en Crear para crear finalmente esta puerta de enlace NAT.
Ahora la puerta de enlace NAT está asociada a la subred de administración y lista para que pueda seleccionarla en el asistente de migración.
Si se elige la tabla de rutas: crear una tabla de rutas y asociarla a la subred de administración
Configure esta tabla de rutas con la ruta predeterminada 0.0.0.0/0 que apunte a un próximo salto de tipo Virtual appliance o Virtual network gateway.
- Inicie sesión en Azure Portal, utilice la barra de búsqueda para buscar tabla de rutas y seleccione esa categoría.
- Haga clic en + Crear para iniciar el asistente Crear tabla de rutas.
- En este primer paso del asistente Crear tabla de rutas, asegúrese de que la suscripción del pod esté seleccionada y elija un grupo de recursos en el que residirá la tabla de rutas.
Nota: Tenga en cuenta que si decide que la tabla de rutas resida en un grupo de recursos diferente del grupo de recursos de la red virtual y la entidad de servicio del pod de first-gen utiliza una función personalizada, la función personalizada deberá tener permiso de Network Contributor en el grupo de recursos de esta tabla de rutas. El uso de una función personalizada para una implementación de first-gen es atípico. La razón por la que se necesita ese permiso en el grupo de recursos de la tabla de rutas es que un tipo de implementación de AKS necesita agregar entradas a la tabla de rutas asociada con la subred de administración. Estas entradas son para el enrutamiento interno de los pods de Kubernetes dentro del tipo de AKS de la implementación de Horizon Edge Gateway.
- Asigne un nombre a la tabla de rutas y asegúrese de que la región seleccionada sea la región de Azure del pod.
Para Propagar rutas de puerta de enlace, seleccione No.
La siguiente captura de pantalla es un ejemplo en el que denominamos a nuestra tabla de rutas como first-pod-migration. Reside en la región de Azure West US 2.
- Cuando se haya rellenado el formulario Crear tabla de rutas, haga clic en Revisar y crear.
Si se supera la validación, haga clic en Crear para crear finalmente esta tabla de rutas.
- A continuación, desplácese hasta la tabla de rutas recién creada para configurarla con la ruta predeterminada 0.0.0.0/0 que apunte a un próximo salto de tipo Virtual network gateway o Virtual appliance.
Dado que AKS solo admite esos dos tipos de próximo salto, el tipo de AKS de la implementación de Horizon Edge Gateway admite esos dos específicamente.
Virtual Appliance se suele utilizar cuando hay un dispositivo virtual de red de Azure (NVA) que controla el flujo del tráfico saliente entre la red virtual del pod y la internet pública. En el formulario Agregar ruta, deberá proporcionar la dirección IP del NVA que puede proporcionar conectividad saliente a Internet. Debe asegurarse de que se pueda acceder a la dirección IP desde la subred de administración (aquella en la que se implementará la implementación de Horizon Edge Gateway). El NVA debe permitir que el tráfico a los endpoints que el entorno de next-gen requiere para el tipo de implementación de AKS.
- Haga clic en Rutas y, a continuación, + Agregar para agregar esa ruta predeterminada.
En la siguiente captura de pantalla se ilustra este paso. El menú Tipo de próximo salto se expande en esta ilustración para mostrar dónde aparecen las opciones admitidas Virtual network gateway y Virtual appliance. Además, hemos escrito un nombre para la ruta y la dirección IP de destino 0.0.0.0/0.
La siguiente captura de pantalla muestra el formulario Agregar ruta rellenado con el próximo salto de Virtual Network Gateway.
- Haga clic en Agregar para agregar esta ruta a la tabla de rutas.
- A continuación, asocie la nueva tabla de rutas con la subred de administración haciendo clic en Subredes y + Asociar.
En la siguiente captura de pantalla se ilustra este paso. Seleccione la red virtual y la subred de administración adecuadas de acuerdo con lo siguiente:
- Si no desea tener direcciones IP restringidas por AKS en la red virtual, seleccione la red virtual del pod y su subred de administración.
- De lo contrario, si creó una nueva red virtual y una subred de administración para superar el problema de la red virtual del pod con direcciones IP restringidas por AKS, seleccione la nueva red virtual y la nueva subred de administración.
- Después de seleccionar la subred, haga clic en Aceptar.
Ahora la tabla de rutas está asociada a la subred de administración y lista para poder seleccionarla en el asistente de migración.
Tipo de AKS: crear una identidad administrada asignada por el usuario y asignar los permisos de función necesarios
Cuando se utiliza el tipo AKS de la implementación de Horizon Edge Gateway, la suscripción de Microsoft Azure del pod debe tener una identidad administrada asignada por el usuario.
Usted o su equipo de TI pueden crear y configurar esta identidad en Azure Portal.
Esta identidad debe configurarse con las siguientes características:
- Función de Network Contributor en el ámbito del grupo de recursos de la red virtual. La red virtual aplicable es:
- Si no desea tener direcciones IP restringidas por AKS en la red virtual, la red virtual del pod.
- De lo contrario, si creó una nueva red virtual para superar el problema de la red virtual del pod que tiene direcciones IP restringidas por AKS, esa red virtual.
- Función de Managed Identity Operator en el ámbito de la suscripción de Microsoft Azure del pod.
El motivo por el cual se necesita esta identidad administrada para el tipo de implementación de AKS es que el clúster del Servicio Kubernetes de Azure (AKS) en la puerta de enlace implementada requerirá una identidad para acceder a los recursos de Azure. Por lo tanto, esta identidad es necesaria para que el flujo de trabajo de migración implemente este tipo.
Crear la identidad administrada asignada por el usuario
- Inicie sesión en Azure Portal y utilice la barra de búsqueda para buscar el usuario asignado y, a continuación, seleccione el resultado Identidad administrada asignada por el usuario.
La siguiente captura de pantalla muestra este paso de búsqueda en el portal.
- Al hacer clic en el resultado de la búsqueda de Identidad administrada asignada por el usuario, se inicia el asistente Crear identidad administrada asignada por el usuario.
Elija la suscripción del pod y un grupo de recursos en el que almacenar este recurso de identidad después de crearlo.
Elija la región de Azure del pod y escriba un nombre para esta identidad administrada asignada por el usuario.
La siguiente captura de pantalla muestra este paso, con algunas partes modificadas por motivos de privacidad. Aquí, hemos denominado a nuestra identidad administrada asignada por el usuario AKS-Edge-identity.
- Haga clic en Revisar y crear para pasar al paso final del asistente.
- Revise la información y haga clic en Crear para completar el asistente y crear la identidad administrada asignada por el usuario.
Esta captura de pantalla muestra este último paso antes de hacer clic en Crear.
- A continuación, agregue los permisos de función a la identidad recién creada como se describe en la siguiente sección.
Asignar los permisos de función necesarios: método de vista previa de Azure
Los pasos de esta sección muestran el método de uso de los pasos de la vista previa de Azure para asignar una función a una identidad administrada. Si sigue los pasos que aparecen a continuación y no ve el botón + Agregar asignación de funciones (vista previa) cuando observe el área de Asignaciones de funciones de Azure de la identidad administrada asignada por el usuario, puede asignar los permisos de función mediante el método alternativo en la sección después de esta.
Los permisos para agregar a la identidad administrada asignada por el usuario son:
| Permiso de función | Ámbito |
|---|---|
| Función de Managed Identity Operator | La suscripción de Microsoft Azure del pod |
| Función de Network Contributor | El grupo de recursos de la red virtual. La red virtual aplicable es:
|
- En Azure Portal, desplácese hasta la identidad administrada asignada por el usuario que acaba de crear y haga clic en Asignación de funciones de Azure y Agregar asignación de funciones (vista previa) hasta que vea el formulario Agregar asignación de funciones (vista previa).
En la siguiente captura de pantalla se ilustra ese paso.
- En el formulario Agregar asignación de funciones (vista previa), seleccione Ámbito como Suscripción, seleccione la suscripción del pod y seleccione la Función de Managed Identity Operator.
- Haga clic en Guardar para guardar la asignación de funciones Managed Identity Operator en la identidad.
- Haga clic en Actualizar para ver la función recién agregada en la lista.
- Vuelva a abrir el formulario Agregar asignación de funciones (vista previa) haciendo clic en Agregar asignación de funciones (vista previa).
- Esta vez, seleccione Ámbito como Grupo de recursos, seleccione el grupo de recursos de la red virtual correspondiente y seleccione la Función de Network Contributor.
- Haga clic en Guardar para guardar la asignación de funciones Network Contributor en la identidad.
- Haga clic en Actualizar para ver la función recién agregada. Ahora las dos funciones deben aparecer en la lista.
Ahora existe la identidad administrada requerida asignada por el usuario y tiene los permisos de función que requiere el tipo de implementación de AKS.
Método alternativo de asignación de los permisos de función necesarios
Si no ve el botón + Agregar asignación de funciones (vista previa) cuando observe el área de Asignaciones de funciones de Azure de la identidad administrada asignada por el usuario, puede asignar los permisos de función mediante este método alternativo.
Los permisos para agregar a la identidad administrada asignada por el usuario son:
| Permiso de función | Ámbito |
|---|---|
| Función de Managed Identity Operator | La suscripción de Microsoft Azure del pod |
| Función de Network Contributor | El grupo de recursos de la red virtual. La red virtual aplicable es:
|
- En primer lugar, agregue el permiso de Managed Identity Operator al ámbito de la suscripción del pod:
- En Azure Portal, desplácese hasta la suscripción.
- En la página de esa suscripción, haga clic en Control de acceso (IAM) y, a continuación, haga clic en Asignaciones de funciones.
- Haga clic en .
Se muestra el asistente Agregar asignación de funciones.
- En el asistente, en la pestaña Función, busque y seleccione la función Managed Identity Operator. Asegúrese de que su fila esté seleccionada antes de hacer clic en Siguiente.
- Haga clic en Siguiente para ir a la pestaña Miembros.
- En la pestaña Miembros, seleccione Identidad administrada y, a continuación, + Seleccionar miembros, se mostrará el formulario Seleccionar identidades administradas.
El paso siguiente muestra la captura de pantalla de ejemplo.
- En el formulario Seleccionar identidades administradas, en el menú Identidad, seleccione Identidad administrada asignada por el usuario.
- A continuación, seleccione la identidad administrada asignada por el usuario que creó y haga clic en el botón Seleccionar para agregarla a la pestaña Miembros.
- A continuación, haga clic en Revisar y asignar para ir a la pestaña Revisar y asignar del asistente.
- En la pestaña Revisar y asignar, haga clic en el botón final Revisar y asignar para completar la asignación de esta función a la identidad en el ámbito de suscripción.
- A continuación, agregue el permiso de Network Contributor al ámbito del grupo de recursos de la red virtual:
- En Azure Portal, desplácese hasta el grupo de recursos de la red virtual correspondiente. La red virtual aplicable es:
- Si no desea tener direcciones IP restringidas por AKS en la red virtual, el grupo de recursos de la red virtual del pod.
- De lo contrario, si creó una nueva red virtual para superar el problema de la red virtual del pod que tiene direcciones IP restringidas por AKS, el grupo de recursos de la red virtual.
- En la página del grupo de recursos, siga pasos similares a los que realizó anteriormente para los permisos de la suscripción.
Haga clic en Control de acceso (IAM) y haga clic en la pestaña Asignaciones de funciones.
Esta captura de pantalla muestra este paso para nuestro grupo de recursos de red virtual denominado hcsvnet-RG.
- Haga clic en . Se muestra el asistente Agregar asignación de funciones.
- En el asistente, en la pestaña Función, busque y seleccione la función Network Contributor. Asegúrese de que su fila esté seleccionada antes de hacer clic en Siguiente.
- A continuación, igual que anteriormente para el otro permiso, haga clic en Siguiente para ir a la pestaña Miembros, seleccione Identidad administrada y, a continuación, + Seleccionar miembros, que muestra el formulario Seleccionar identidades administradas.
- En el formulario Seleccionar identidades administradas, en el menú Identidad, seleccione Identidad administrada asignada por el usuario.
- A continuación, seleccione la identidad administrada asignada por el usuario que creó y haga clic en el botón Seleccionar para agregarla a la pestaña Miembros.
- Ahora vaya a la pestaña Revisar y asignar del asistente y haga clic en el botón Revisar y asignar para completar la asignación de esta función a la identidad en el ámbito del grupo de recursos de la red virtual.
Esta captura de pantalla muestra este paso para nuestro grupo de recursos de red virtual denominado hcsvnet-RG.
- En Azure Portal, desplácese hasta el grupo de recursos de la red virtual correspondiente. La red virtual aplicable es:
Ahora existe la identidad administrada requerida asignada por el usuario y tiene los permisos de función que requiere el tipo de implementación de AKS.
Para confirmar que la identidad administrada asignada por el usuario tiene las dos funciones, desplácese hasta la identidad en Azure Portal y muestre su página de asignaciones de funciones de Azure.
La siguiente captura de pantalla muestra nuestra identidad administrada asignada por el usuario con las dos funciones indicadas en sus asignaciones de funciones de Azure.
Tipo de AKS: reservar los rangos de IP virtuales necesarios para evitar conflictos con AKS
Esta información se aplica cuando se ha decidido migrar el pod mediante el tipo de AKS para la implementación de Horizon Edge Gateway. El tipo de implementación de AKS requiere que algunos rangos de IP virtuales se reserven en el método de administración de IP de su elección, el sistema de IPAM (sistema de administración de direcciones IP).
Introducción
Son rangos de IP virtuales que se reservarán para el uso exclusivo del tipo de AKS de Horizon Edge Gateway
Por diseño, Kubernetes crea redes virtuales dentro del clúster de Kubernetes dentro de Horizon Edge Gateway.
Estas redes virtuales alojan los contenedores que se ejecutan dentro del clúster.
¿Por qué es necesario reservar estos rangos si son internos de la instancia de Edge?
El propósito de reservar estos rangos es evitar que otras máquinas del espacio de red obtengan las direcciones IP asignadas y utilicen las direcciones IP.
A pesar de que las redes virtuales del clúster de Kubernetes de Edge son internas de Horizon Edge Gateway y no están en realidad en la red de administración, las redes virtuales del clúster se conectan a la subred de administración en la red virtual de Azure.
Los servicios que se ejecutan fuera del clúster de AKS enrutan el tráfico a las redes internas del clúster de AKS. Por ejemplo, las instancias de Horizon Agent en escritorios de VDI deben enviar datos a servicios que se ejecutan en este clúster de AKS.
Por lo tanto, si los rangos no están reservados y otra máquina de la red obtiene una dirección IP de los rangos, esto podría afectar al enrutamiento y provocar conflictos en el tráfico de servicio necesario a las redes internas del clúster de AKS.
Al reservar los rangos de IP en el sistema de administración de direcciones IP antes de la migración del pod, se evitan estos posibles conflictos.
¿Necesito crear subredes de estos rangos?
No, no es necesario crear subredes de estos rangos.
Estos rangos de IP virtuales residirán dentro de la red virtual del clúster de AKS de Horizon Edge Gateway cuando se implemente Horizon Edge como parte del proceso de migración.
Para la migración de pods, ¿necesito saber cuáles son los rangos reservados?
Sí. Cuando tenga pensado elegir el tipo de implementación de AKS, debe conocer los rangos que usted y su equipo han reservado para esta implementación.
La interfaz de usuario del asistente de migración requiere que se introduzcan dos rangos de IP (CIDR) en los campos denominados CIDR de servicio y CIDR del pod.
Por lo tanto, debe decidir qué rangos han elegido reservar usted y su equipo antes de ejecutar el asistente de migración.
¿Qué tipo de rangos debo reservar?
El tipo AKS de Horizon Edge Gateway requiere que se reserven dos rangos de IP virtuales para su uso.
- Un rango de CIDR de /27 como mínimo para lo que se denomina CIDR de servicio
- Un rango de CIDR de /21 como mínimo para lo que se denomina CIDR de pod
Estos dos rangos de IP no deben superponerse unos a otros ni colisionar entre sí.
- 169.254.0.0/16
- 172.30.0.0./16
- 172.31.0.0/16
- 192.0.2.0/24
| Rango de IP para reservar | Detalles |
|---|---|
| CIDR de servicio | Decida un rango de IP paraCIDR de servicio y reserve ese espacio de IP en IPAM para que ninguna otra máquina pueda utilizar direcciones IP de ese rango. Se requiere un rango de /27 como mínimo.
Recordatorio: Como se indicó anteriormente, se trata de un rango de IP virtuales y no es necesario crear una subred con él. Solo tiene que asegurarse de que ninguna otra máquina de la red tenga asignada esas direcciones.
Cuando decida el rango de IP, tenga en cuenta estos puntos:
El objetivo de este CIDR para el tipo de AKS de Horizon Edge es que las direcciones de este rango de IP virtual se asignen a los servicios que se ejecutan dentro del clúster de AKS de Edge. |
| CIDR del pod | Decida un rango de IP paraCIDR de servicio y reserve ese espacio de IP en IPAM para que ninguna otra máquina pueda utilizar direcciones IP de ese rango. Se requiere un rango de /21 como mínimo.
Recordatorio: Como se indicó anteriormente, se trata de un rango de IP virtuales y no es necesario crear una subred con él. Solo tiene que asegurarse de que ninguna otra máquina de la red tenga asignada esas direcciones.
Cuando decida el rango de IP, tenga en cuenta estos puntos:
El objetivo de este CIDR en el tipo de AKS de Horizon Edge es que las direcciones de este rango de IP virtual se asignen a los servicios que se ejecutan dentro del clúster de AKS de Edge. Esto se debe a que el tamaño está relacionado con la cantidad de nodos que tendrá el clúster de AKS. A cada nodo del clúster de AKS se le asignan previamente 256 direcciones IP de este rango. |
