SDN/NFV y OpenStack

Question 1

Que es SDN (Redes definidas por Software)?

Answer 1

Arquitectura que separa el control de la red (Plano de Control) y las funciones de reenvio (Plano de Forwarding).
El Control de la red esta separado del envio y es directamente programable

Question 2

Controladores SDN

Answer 2

*Proporciona el control sobre toda la red
*Hace cumplir las politicas que dictan el comportamiento de la red
*Facilita la comunicacion entre aplicaciones que desean interactuar con elementos de red y elementos de red que desean transmitir informacion a esas aplicaciones.

Question 3

Que es ONOS (Open Network OS)?

Answer 3

ONOS es el controlador SDN desarrollado por la ONF. Otorga el plano de control para una arquitectura SDN. Entre sus funciones podemos indicar la administración de los componentes de red, switches y enlaces, y tambien ejecuta programas o módulos de software para proporcionar servicios de comunicación a los hosts finales y redes distintas.

Question 4

Que es la NFV?

Answer 4

Es una iniciativa para virtualizar los servicios de red que tradicionalmente se ejecutan en hardware dedicado y propio. Con NFV, funciones como enrutamiento, equilibrio de carga y firewalls se empaquetan como VMs en hardware básico.

Question 5

Arquitectura NFV

Answer 5

*VNF (Funciones de Red Virtualizadas) -> Aplicaciones de software que ofrecen funciones de red
*NFVI (Infraestructura de Virtualizacion de Funciones de Red) -> Consiste en los elementos de la infraestructura de una plataforma que soporta el software o una plataforma de gestion de contenedores, los cuales son necesarios para ejecutar las aplicaciones de red.
*MANO (VIM) (Gestion, Automatizacion y Organizacion de la Red) -> Proporciona el marco para gestionar la infraestructura de NFV e implementar NFV nuevos.

Question 6

NBI

Answer 6

Las aplicaciones que utilizan una SDN dependen del controlador para obtener información sobre el estado de la infraestructura de la red, para que puedan saber qué recursos están disponibles. Las aplicaciones hablan con la capa de control a través de las APIs northbound y le dicen a la capa
qué recursos necesitan las aplicaciones y su destino. La capa de control orquesta cómo las aplicaciones reciben los recursos disponibles en la red. Las APIs northbound suelen ser APIs RESTful, tambien pueden usar HTML

Question 7

Que es y que hace la SBI? Que protocolos utiliza?

Answer 7

Interfaz API por la cual el controlador SDN se comunica con la infraestructura de la red (Plano de datos). A la infraestructura se le dice qué ruta deben tomar los datos de la aplicación según lo decida el controlador. En tiempo real, el controlador puede cambiar la forma en que los routers y switches transfieren datos. Los datos ya no dependen de los dispositivos y las tablas de enrutamiento para determinar a dónde van. En cambio, la inteligencia del controlador toma decisiones que optimizan la ruta de los datos. Ejemplos: OpenFlow, Netconf, OVSDB, etc

Question 8

Que es OpenStack? Cual es su mision?

Answer 8

OpenStack es una solución de cloud computing del tipo IaaS de código abierto.
Su misión es proveer una solución flexible tanto para nubes públicas como privadas, sean estas de cualquier tamaño, y para esto se consideran dos requisitos básicos: las nubes deben ser simples de implementar y masivamente escalables.

Question 9

Cuales son los pilares de las nubes hechas con OpenStack?

Answer 9

-Computacion
-Almacenamiento
-Redes
La solidez de estos pilares determina la solidez, la escalabilidad y el rendimiento de la nube OpenStack

Question 10

Componentes de OpenStack

Answer 10

*Horizon (Dashboard)
*Keystone (Servicio de Identidad)
*Nova (Servicio de Computo)
*Glance (Servicio de imagenes)
*Swift (Servicio de almacenamiento de objetos)
*Cinder (Servicio de Almacenamiento de bloques)
*Neutron (Servicio de red)

Question 11

Que es el componente de OpenStack Horizon (Dashboard)?

Answer 11

Interfaz basada en browser para administrar servicios de OpenStack, que proporciona una interfaz grafica para iniciar instancias, administrar redes y establecer controles de acceso

Question 12

Que es Keystone (Servicio de identidad)?

Answer 12

Proporciona autenticacion y autorizacion a todos los servicios de OpenStack. Actua como un servicio de autenticacion de inicio de sesion unico (SSO) para usuarios y componentes. Es el responsable de crear y administrar usuarios, dominios, roles y proyectos

Question 13

Que es el componente de OpenStack Nova (Servicio de computo)?

Answer 13

Administra instancias que se ejecutan en nodos, proporcionando VM bajo demanda. Esta diseñado para escalar horizontalmente en hardware estandar, descargando imagenes para iniciar instancias segun sea necesario

Question 14

Glance (Servicio de Imagenes)

Answer 14

Actua como un registro de imagenes de VM, lo que permite a los usuarios copiar imagenes del servidor para su almacenamiento inmediato

Question 15

Swift (Servicio de almacenamiento de objetos)

Answer 15

Proporciona almacenamiento de objetos que permite a los usuarios almacenar y recuperar archivos. La arquitectura del almacenamiento de objetos se distribuye para permitir el crecimiento horizontal y proporcionar redundancia como diseño para evitar fallos o perdidas de objetos

Question 16

Cinder (Servicio de almacenamiento de bloques)

Answer 16

Administra volumenes de almacenamiento para VM. Puede ser un almacenamiento en bloque tanto efimero como persistente para las instancias que se ejecutan en el servicio de Compute

Question 17

Que es el componente de OpenStack Neutron (Servicio de Red)?

Answer 17

Servicio de SDN que ayuda a crear redes, subredes, routers y direcciones IP flotantes. Los usuarios pueden crear sus propias redes, controlar el trafico y conectar servidores a otras redes. Los Adminstradores pueden definir una puerta de enlace para que un router permita el acceso externo

Question 18

Arquitectura Openstack

Answer 18

La mayoria de las nubes OpenStack estan formadas por nodos de infraestructura fisica que encajan en una de estas categorias:
-Nodos de Control (Controlador) : Ejecutan los servicios de APIs para todos los componentes de OpenStack. Ejecutan la BD y los servicios de mensajeria y, a menudo, son el punto de administracion de la nube.
-Nodos de Red: Ejecutan DHCP y servicios de metadatos y pueden alojar routers virtuales cuando se instala el agente Neutron L3
-Nodos de computo: Ejecutan un hipervisor o un software de contenedor. Tambien pueden albergar routers virtuales, especialmente cuando se configura el DVR (Enrutamiento Virtual Distribuido)
-Nodos de Almacenamiento: Se limitan a ejecutar software relacionado con el almacenamiento

Question 19

OpenStack Plugins

Answer 19

*Plugin de Nucleo (Core Plugin): Implementa la API principal de Neutron y es responsable de adaptar la red logica en algo que pueda interpretar el agente L2 y el sistema de administracion de direcciones IP que se ejecutan en el host
*Plugin de Servicio (Service Plugin): Proporciona servicios de red adicionales, como enrutamiento, balanceo de carga, firewalls y mas

Question 20

Plugin ML2 (Modular Layer 2)

Answer 20

Es extensible por diseño y soporta arquitecturas de red heterogeneas que pueden aprovechar multiples tecnologias simultaneamente. Reemplaza a dos plugins monoliticos: el Linux bridge y el core plugin Open vSwitch

Question 21

Drivers

Answer 21

El plugin ML2 introdujo el concepto de Type Drivers y Mechanism Drivers para separar los tipos de redes que se implementan y los mecanismos para implementar redes de esos tipos
*Type Drivers (Controladores de Tipo): Mantiene un estado de red especifico del tipo, valida los atributos de la red del proveedor y describe los segmentos de la red utilizando los atributos del proveedor
*Mechanism Drivers (Controladores de Mecanismo): Responsable de tomar la informacion establecida por el controlador de tipo y garantizar que se implemente. Los Mechanism Drivers multiples pueden ser configurados para operar simultaneamente, y se puede describir usando tres tipos de modelos: Basado en agente, basado en controlador y top-of-rack

Question 22

Neutron (OpenStack Networking)

Answer 22

Sistema escalable, conectable y basado en APIs para administrar redes en una nube basada en OpenStack. Complementa otros servicios basicos de OpenStack como Nova, Glance, Keystone, Cinder, Swift y Horizon para proporcionar una solucion completa en la nube. Expone una API a los usuarios y pasa las solicitudes a los plugins de red configurados para un procesamiento adicional. Los usuarios pueden definir la conectividad de la red en la nube, y los operadores de la nube pueden aprovechar diferentes tecnologias de red para mejorar y potenciar la nube

Question 23

Arquitectura de Neutron

Answer 23

Neutron requiere acceso a una DB para almacenamiento persistente de la configuracion de la red. El servidor de Neutron puede recibir solicitudes de APIs de usuarios y servicios, y comunicarse con agentes a traves de una cola de mensajes

Question 24

Flujo de Trafico de Red

Answer 24

*Trafico de red norte-sur: Viaja entre una instancia y una red externa (ej: Internet)
*Trafico de red este-oeste: Viaja entre instancias en la misma red o redes diferentes

Question 25

Trafico de red norte-sur

Answer 25

-Instancia en el nodo de computo O1 y usa la red de autoservicio
-Instancia envia un paquete a internet
*Para instancias con una direccion IPv4 fija, el nodo de red realiza SNAT en el trafico de norte a sur que pasa de la red de autoservicio o redes externas
*Para instancias con una direccion IPv6 fija, el nodo de red realiza el enrutamiento convencial del trafico entre las redes de autoservicio y las redes externas

Question 26

Trafico de red este-oeste

Answer 26

-Instancias en diferentes redes
*Instancia O1 esta en el nodo de computo 01 y usa la red de autoservicio 01
*Instancia O2 esta ubicada en el nodo de computo 01 y usa la red de autoservicio 02
*La VM1 en el nodo de computo 01 envia un paquete a la VM2, que tambien reside en el nodo 01

Question 27

Docker

Answer 27

Tipos de redes:
A. Redes de host
B. Bridge Networking
C. Red de Bridge personalizada
D. Redes definidas por contenedor
E. Sin Redes

Question 28

Docker -> Redes de host

Answer 28

El contenedor comparte la misma direccion IP y espacios de nombres de red que el host. Los servicios que se ejecutan dentro de este contenedor tienen las mismas capacidades de red que los servicios que se ejecutan directamente en el host.

Question 29

Docker -> Bridge Networking

Answer 29

El contenedor se ejecuta en una red privada interna del host. La comunicacion esta abierta a otros contenedores en la misma red. La comunicacion con los servicios fuera del host pasa por la NAT antes de salir del host

Question 30

Docker -> Red de bridge personalizada

Answer 30

Es lo mismo que Bridge Networking pero usa un puente creado explicitamente para este (y otros) contenedor. Otros contenedores pueden tener una interfaz en el puente predeterminado y el puente de la DB, lo que le permite comunicarse con ambas redes

Question 31

Docker -> Redes definidas por contenedor

Answer 31

Un contenedor puede compartir la direccion y la configuracion de red de otro contenedor. Este tipo permite el aislamiento de procesos entre contenedores, donde cada contenedor ejecuta un servicio pero donde los servicios aun pueden comunicarse entre si en la direccion localhost

Question 32

Docker -> Sin redes

Answer 32

Esta opcion deshabilita todas las redes para el contenedor. Este modo es util cuando el contenedor no necesita comunicarse con otros contenedores o con el mundo exterior. No tiene asignada una direccion IP y no puede publicar ningun puerto

Question 33

Comunicacion contenedor a contenedor

Answer 33

Dos contenedores que se ejecutan en el mismo host se conectan a traves del bridge. Si el contenedor 1 quiere enviarle una solicitud al contenedor 2, los paquetes se mueven de la siguiente manera:
1_ Un paquete sale del contenedor a traves del eth0 y llega a la interfaz vethxxx correspondiente
2_ La interfaz vethxxx se conecta a la interfaz vethyyy a traves del bridge docker0
3_ El bridge docker0 reenvia el paquete a la interfaz vethyyy
4_ El paquete se mueve a la interfaz eth0 dentro del contenedor de destino

Question 34

Comunicacion de Contenedores entre hosts

Answer 34

Las redes entre hosts suelen utilizar una red overlay, que construye una malla entre los hosts y emplea un gran bloque de direcciones IP dentro de esa malla. El controlador de red rastrea que direcciones se encuentran en que host y transfiere paquetes entre los hosts segun sea necesario para la comunicacion entre contenedores. Las redes overlay pueden estar cifradas o no cifradas. La funcionalidad de red overlay integrada en Docker se llama Swarm. Cuando conecta un host a Swarm, el motor de Docker en cada host maneja la comunicacion y el enrutamiento entre los hosts

Question 35

CNI (Container Network Interface)

Answer 35

Proporciona una solucion de red orientada a plug-in para contenedores y orquestadores de contenedores. Consiste en una especificacion y librerias para escribir plug-ins para configurar interfaces de red en contenedores de Linux.
Solo se ocupa de la conectividad de red de los contenedores, asi como de la recoleccion de desechos de los recursos una vez que se eliminan los contenedores. CNI es el estandar de facto para los orquestadores de contenedores

Question 36

Kubernetes

Answer 36

Plataforma de orquestacion de contenedores de codigo abierto que automatiza la implementacion, la gestion, el escalado y la creacion de redes de contenedores. Permite ejecutar aplicaciones compuestas por una gran cantidad de contenedores de manera confiable, continua y a prueba de fallas. Cuando falla un contenedor que se ejecuta en un cluster de Kubernetes, puede restaurar el contenedor casi de inmediato. Kubernetes permite a los equipos actualizar las aplicaciones menos se ejecutan.
Brinda acceso seguro a las aplicaciones a un nivel muy detallado

Question 37

Arquitectura de Kubernetes

Answer 37

*Modelo controller-worker: Una computadora o grupo de computadoras controla a otro grupo que hace el trabajo
*Los componentes y los datos instalados en la computadora de control forman lo que se llama plano de control y las computadoras que hacen el trabajo se denominan nodos worker. Combinados, forman un cluster
*El plano de control realiza todas las funciones de control, delegando todo el trabajo a un grupo de workers
*Cuando un cluster alcanza los limites de su capacidad informatica, un administrador del sistema puede activar automaticamente otra computadora y agregarla al cluster en tiempo real. Luego, Kubernetes aprovisiona automaticamente la maquina de estado deseado.

Question 38

Funcionamiento de Kubernetes

Answer 38

-El bloque de construccion fundamental es el contenedor de linux. El contenedor aisla el proceso asociado con el de una manera que hace que el proceso piense que es el unico en la computadora
-El proceso tiene su propio sistema de archivos, asi como acceso especial a otros recursos del sistema. Ademas, al proceso se le puede dar su propia direccion IP. Ningun otro proceso que se ejecuta en la computadora tiene acceso a el.
-Los contenedores aportan mucha versatilidad al proceso de implementacion. Puede agregarlos y eliminarlos a su antojo sin tener que reiniciar la computadora host.
-Un pod es un recurso de Kubernetes que aloja logicamente uno o mas contenedores
-Kubernetes facilita la implementacion de aplicaciones en contenedores desde un repositorio de contenedores y aprovisiona los contenedores dentro del cluster automaticamente
-Kubernetes ofrece varias funciones adicionales que hacen que la tecnologia sea atractiva:
*El plano de control determina cual de sus nodos worker es el mas adecuado para alojar los contenedores de la aplicacion
*Crea acceso al contenedor en la red interna del cluster como parte del proceso de implementacion del contenedor
*Garantiza que todos los contenedores que deben estar en ejecucion esten siempre en ejecucion, y repone un contenedor en caso de falla
*Si la computadora de un nodo worker falla por completo, Kubernetes recrea los contenedores que se estaban ejecutando en otra maquina
*Si se agrega una nueva computadora de nodo worker al cluster, Kubernetes redistribuye los contenedores para equilibrar la carga de trabajo

Question 39

Plano de Control

Answer 39

Controla las actividades dentro del cluster y entre los nodos worker

Question 40

Componentes del Plano de Control

Answer 40

*Servidor API: Permite que los componentes del cluster se comuniquen entre si para ejecutar tareas
*Administrador de controlador: Administra todos los contenedores del cluster
*Programador: Encuentra el mejor nodo worker en el cluster en el que instalar un pod. Una vez identificado, programara el pod para que se ejecute en el nodo
*Almacenamiento de Datos
*Servidor DNS: Nombre legible para ubicar recursos en la red

Question 41

Nodos Worker

Answer 41

Computadora o Maquina virtual que aloja contenedores que se ejecutan bajo Kubernetes

Question 42

Componentes de los nodos worker

Answer 42

*Kubelet: Crea contenedores en su nodo worker y los monitorea. Una vez que se encuentra el mejor nodo worker, el plano de control notifica a la instancia de kubelet que se ejecuta en el nodo worker identificado para realizar un contenedor de pod. Luego, Kubelet hace el trabajo de instalar el contenedor en el nodo worker e informa al servidor API los detalles sobre la instalacion del contenedor
*cAdvisor: Recopila e informa metricas sobre actividades dentro del nodo worker dado. Es consciente de todos los contenedores que se ejecutan en un nodo worker y recopila estadisticas de uso de la CPU, la memoria, el sistema de archivos y la red sobre los contenedores
*kube-proxy: Es un demonio que se ejecuta en cada nodo de trabajo en un cluster de Kubernetes para enrutar el trafico de red recibido por el nodo worker al contenedor apropiado alojado en el nodo worker. Hace esta tarea trabajando con el plano de control para observar como se definen las rutas para el servicio, que operan dentro del cluster. Con esta informacion, descubre como enrutar una solicitud entrante al contenedor correspondiente en el nodo worker

Question 43

Recursos basicos de Kubernetes

Answer 43

Un recurso de Kubernetes es una estructura logica dentro del ecosistema de Kubernetes que representa un determinado aspecto del estado o actividad en un cluster de Kubernetes. Es una estructura de datos que le dice a otros programas como comportarse.
Dos formas de realizarlo:
-Realizacion Imperativa: Se crea desde la linea de comandos desde la CLI de kubectl
-Realizacion Declarativa: Se crea a partir de un archivo de texto que describa la configuracion del recurso

Question 44

Pod

Answer 44

Envolutura logica para uno o mas contenedores alojados dentro de un cluster de Kubernetes. Define la imagen del contenedor junto con el repositorio de imagenes asociado que se usara para realizar los contenedores correspondientes. Puede definir las variables ambientales que se crearan en el proceso del contenedor dado, tiene una direccion IP que es unica para el cluster. Cada contenedor puede tener un numero de puesto unico.

Question 45

Modelo de Networking de Kubernetes

Answer 45

Kubernetes dicta los siguientes requisitos en cualquier implementacion de redes:
-Todos los pods pueden comunicarse con todos los demas Pods sin utilizar NAT
-Todos los nodos pueden comunicarse con todos los pods sin NAT
-La IP con la que un pod se ve a si mismo es la misma IP con la que otros lo ven
Dadas estas restricciones, nos quedan cuatro problemas distintos de redes para resolver:
1. Redes de contenedor a contenedor
2. Redes de pod a pod
3. Redes de pod a servicio
4. Redes de Internet a Servicio

Question 46

Modelo de Networking de Kubernetes -> Redes de Contenedor a Contenedor

Answer 46

En Linux, cada proceso en ejecucion se comunica dentro de un namespace de red que proporciona una pila de red logica con sus propias rutas, reglas de firewall y dispositivos de red. En esencia, un namespace de red proporciona una pila de red completamente nueva para todos los procesos dentro del namespace. De forma predeterminada, Linux asigna todos los procesos al namespace de la red raiz para brindar acceso al mundo externo.
En Docker, un pod se modela como un grupo de contenedores de Docker que comparten un namespace de red. Podemos crear un espacio de namespace de red para cada Pod en una VM. Esto se implementa como un “Contenedor Pod” que mantiene abierto el namespace de la red mientras que los “contenedores de aplicaciones” se unen a ese namespace

Question 47

Modelo de Networking de Kubernetes -> Redes de Pod a Pod

Answer 47

En Kubernetes, cada Pod tiene una direccion IP real y cada Pod se comunica con otros Pods usando esa direccion IP.
Desde la perspectiva del Pod, este existe en su propio namespace de Ethernet que necesita para comunicarse con otros namespaces de red en el mismo. Para conectar los namespace del Pod, podemos asignar un lado del par vETH al namespace de red raiz y el otro lado al namespace de red del Pod. Cada para vETH funciona como un cable de conexion, conectando los dos lados y permitiendo que el trafico fluya entre ellos. Esta configuracion se puede replicar para tantos Pods como tengamos en la maquina.
En este punto, configuramos los Pods para que cada uno tenga su namespace de red, de modo que crean que tienen su propio dispositivo Ethernet y direccion IP, y que estan conectados al espacio de nombres raiz para el Nodo. Ahora, queremos que los Pods se comuniquen entre si a traves del namespace raiz, y para eso usamos un bridge de red

Question 48

Modelo de Networking de Kubernetes -> Redes de Pod a Servicio

Answer 48

Un servicio de Kubernetes administra el estado de un conjunto de pods, lo que le permite restrear un conjunto de direcciones IP de pod que cambian dinamicamente con el tiempo. Los servicios actuan como una abstraccion sobre los pods y asignan una sola direccion IP virtual a un grupo de direcciones IP del Pod. Cualquier trafico dirigido a la IP virtual del Servicio sera enrutado al conjunto de Pods que esten asociados a la IP virtual. Al crear un nuevo servicio de Kubernetes, se crea una nueva IP virtual en su nombre. En cualquier lugar dentro del cluster, el trafico dirigido a la IP virtual tendra una carga equilibrada para el conjunto de Pods de respaldo asociados con el Servicio. En efecto, Kubernetes crea y mantiene automaticamente un balanceador de carga distribuido en el cluster que distribuye el trafico a los Pods en buen estado asociados a un Servicio.

Question 49

Modelo de Networking de Kubernetes -> Redes de Internet a Servicio

Answer 49

1) Llevar el trafico de un servicio de Kubernetes a Internet
2) Llevar el trafico de Internet a su servicio de Kubernetes

Question 50

Redes de Internet a Servicio -> Llevar el trafico de un servicio de Kubernetes a Internet

Answer 50

Con una puerta de enlace a Internet, las VM pueden enrutar el trafico a Internet. Desafortunadamente, los pods tienen su propia direccion IP que no es la misma que la direccion IP del nodo que aloja al pod, y la traduccion de NAT en la puerta de enlace de Internet solo funciona con direcciones IP de VM porque no tiene conocimiento sobre en que se ejecutan los Pods.
El paquete se origina en el namespace del Pod y viaja a traves del par vETH conectado al namespace raiz. Una vez en el namespace raiz, el paquete pasa del bridge al dispositivo predeterminado, ya que la direccion IP del paquete no coincide con ningun segmento de red conectado al bridge. En este caso, la direccion IP de origen del paquete en un Pod, y si mantenemos el origen como un Pod, la puerta de enlace de Internet la rechazara porque la puerta de enlace NAT solo entiende las direcciones IP que estan conectadas a la VM. La solucion es hacer que iptables realice un NAT de origen para que parezca que el paquete proviene de la VM y no del Pod. La puerta de enlace de Internet realizara otro NAT reescribiendo la IP de origen desde una IP interna de VM a una IP externa. Finalmente, el paquete llegara a la Internet publica

Question 51

Redes de Internet a Servicio -> Llevar el trafico de Internet a su servicio de Kubernetes

Answer 51

Ingress se divide en dos soluciones que funcionan en diferentes partes de la pila de red:
1. Un service LoadBalancer
2. Un Controlador de Ingress

Question 52

Llevar el trafico de Internet a su servicio de Kubernetes -> Service LoadBalancer

Answer 52

Cuando crea un servicio de Kubernetes, puede especificar opcionalmente un LoadBalancer para que lo acompañe. La implementacion de LoadBalancer la proporciona un controlador en la nube que sabe como crear un LoadBalancer para su servicio. Una vez que se crea su servicio, anunciara la direccion IP para el LoadBalancer. Como usuario final, puede comenzar a dirigir el trafico al LoadBalancer para comenzar a comunicarse con su servicio

Question 53

Llevar el trafico de Internet a su servicio de Kubernetes -> Controlador de Ingress

Answer 53

El ingreso de red de capa 7 opera en el rango de protocolo HTTP/HTTPS de la pila de red y se basa en los servicios. El primer paso para habilitar Ingress es abrir un puerto en su servicio utilizando el tipo de servicio NodePort en Kubernetes. Si establece el campo de tipo de servicio en NodePort, el maestro de Kubernetes asignara un puerto de un range que especifique, y cada Nodo representara ese puerto en su servicio. Es decir, cualquier trafico dirigido al puerto del nodo se reenviara al servicio utilizando las reglas de iptables.
La vida de un paquete que fluye a traves de un Ingress es muy similar a la de un LoadBalancer. Las diferencias clave son que un Ingress conoce la ruta de la URL, y que la conexion inicial entre el Ingress y el Nodo se realizara a traves del puerto expuesto en el Nodo para cada servicio