Principios básicos
Hace varios años, la virtualización era la palabra clave más moderno, ya que revolucionó la manera en la que los servidores se construyeron. La virtualización era acerca de la adopción de máquinas virtuales (VM) en lugar de servidores físicos dedicados para alojar y crear nuevas aplicaciones. Cuando llegó a escala, portabilidad, administración de la capacidad, costos y mucho más, los VM eran un ganador claro (como hoy). Puede encontrar toneladas de comparaciones entre los dos enfoques.
Si la virtualización era la palabra clave, las palabras clave ahora son Cloud, SDN y contenedores.
Hoy día, las comparaciones más intensas se encuentran entre VM y los contenedores, y cómo los contenedores prometen una nueva manera de crear y escalar aplicaciones. Aunque muchas organizaciones pequeñas piensan que los contenedores son demasiado silvestres o demasiado pronto como para adoptarlos, lo más sencillo es que, desde Gmail hasta YouTube y busque, todo en Google se ejecute en contenedores, y que ejecuten 2 mil millones contenedores por semana. Esto podría darle pistas acerca de dónde se encuentra el sector.
Pero, ¿qué es un contenedor y cómo es comparable con una VM? ’Empiece este día un libro con una comparación.
Descripción general de contenedores
Desde una perspectiva técnica, el concepto de un contenedor se arraiga en los espacios de nombres y el concepto cgroups de Linux, pero también se inspira en la inspiración de los recipientes de transporte de la carga metálica reales que se observan en los buques seafaring. Ambos tipos de contenedores comparten la capacidad de aislar contenidos, mantener la independencia de la operadora, ofrecer portabilidad y mucho más.
Los contenedores son un mecanismo lógico de empaquetado. YYou puede pensar en los contenedores como una virtualización ligera que ejecuta una aplicación y sus dependencias en el mismo sistema operativo, pero en distintos contextos que eliminan la necesidad de replicar un sistema operativo completo como se muestra en la Figure 1. Al hacerlo, la aplicación se limita en un paquete ligero que se puede desarrollar y probar individualmente, y, a continuación, implementarse y escalarse mucho más rápido que la máquina virtual tradicional. Los desarrolladores solo necesitan crear y configurar esta pieza ligera de software para que la mayor parte de la aplicación se pueda contenedor y esté disponible para el público sin la necesidad de administrar y admitir la aplicación por sistema operativo.
Muchos desarrolladores llamaron al tiempo de ejecución del contenedor que se muestra en la figura 1,1 como el hipervisor de los contenedores. Aunque este término no es técnicamente correcto, puede ser útil para visualizar la jerarquía.
Como en muchas tecnologías de la VM, los hipervisores más comunes son KVM y VMware ESX/ESXi. En las tecnologías contenedoras, el Docker y RKT son los más comunes, siendo el acoplador el más ampliamente implementado. Deje’que s Revise algunos números útiles en la comparación de máquinas virtuales con contenedores.
Juniper vSRX frente a cSRX
En la actualidad, las aplicaciones más comunes, como Redis, Ngnix, Mongo, MySQL, WordPress, Jenkins, Kibana y Perl, se han creado y se ofrecen de forma pública en https://Hub.Docker.com , lo que permite a los desarrolladores crear y probar sus aplicaciones con rapidez.
Existen numerosas pruebas disponibles que comparan el rendimiento y la escalabilidad de cualquier aplicación mientras se ejecuta en contenedores frente a la VM. Las comparaciones se alojan en los beneficios de ejecutar la aplicación en contenedores, pero ¿qué ocurre con las virtualizaciones de funciones de red (NFV), como firewall, TDR, enrutamiento, etc.?
En lo que se refiere al NFV basado en VM, la mayoría de los proveedores de redes ya implementan un tipo virtualizado del equipo de hardware que puede ejecutarse en el hipervisor de un hardware x86 estándar. Basado en Junos, vSRX es una puerta de enlace de servicios Juniper Networks serie SRX en un factor de forma virtualizada que ofrece funciones de red y seguridad similares a las disponibles para el SRX físico, del mismo modo que en el caso de los NFV basados en contenedores. Ésta’es la nueva tendencia. Juniper cSRX es el primer’servidor de seguridad de contenedor de la industria que ofrece un espacio compacto con un firewall de alta densidad para entornos virtualizados y de nube. En la Table 1 se enumeran las comparaciones entre vSRX y cSRX en las que se puede ver la idea de que el cSRX es un NFV ligero.
Table 1: vSRX frente a cSRX
vSRX | cSRX | |
Casos de uso | Enrutamiento, seguridad, TDR, VPN, alto rendimiento integrado | Seguridad L4-L7, espacio reducido |
Requisitos de memoria | Mínimo de 4 GB | En MBs |
TDR | Sí | Sí |
VPN IPSec | Sí | No |
Tiempo de arranque | ~ minutos | < 1Second |
Tamaño de imagen | En GB | En MBs |
Con el uso de las técnicas de micro Services, la aplicación puede dividirse en servicios más pequeños con cada parte (un contenedor en este caso) realizando una tarea específica.
Descripción del acoplador
Como se explicó, los contenedores permiten que un desarrollador Empaquete una aplicación con todas las partes que necesita, como bibliotecas y otras dependencias, y que las distribuya todo como un solo paquete. El acoplador es un software que facilita la creación, implementación y ejecución de contenedores.
El punto de inicio es el código fuente para el archivo de imagen del acoplador y, desde allí, puede crear la imagen que se va a almacenar – y distribuir en cualquier registro con – más frecuencia un concentrador de acoplamiento y usar esta imagen para ejecutar los contenedores.
El acoplador utiliza la arquitectura cliente-servidor que se muestra en la Figure 2. El cliente y el daemon de Dock se pueden ejecutar en el mismo sistema o se puede conectar un cliente de Dock a un demonio de Docker remoto. El daemon de Docker hace el pesado levantamiento de crear, ejecutar y distribuir los contenedores de los Docks. El cliente y el daemon Dock se comunican a través de una API de REST a través de sockets UNIX o una interfaz de red.
’Los contenedores no aparecen en un vacío, y en los entornos de producción’que ganó ha obtenido se cuenta con un solo host con varios contenedores, sino varios hosts que ejecutan cientos, no miles, de contenedores, lo que da lugar a dos preguntas importantes:
¿Cómo se comunican entre sí estos contenedores en el mismo host o en diferentes hosts, así como en el exterior? (Básicamente, las partes de redes de los contenedores).
¿Quién determina qué contenedores se iniciarán en qué host? ¿En función de lo que hace? Actualizaciones? Número de contenedores por aplicación Básicamente, ¿quién lo orquesta?
Estas dos preguntas se responden, con detalle, a lo largo del resto del libro, pero si desea una respuesta rápida, piense en Juniper Contrail y Kubernetes.
Comencemos’con las bases básicas de la plataforma de Contrail de Juniper.
Descripción general de la plataforma Contrail
La plataforma de Contrail de Juniper ofrece redes dinámicas de extremo a extremo, políticas de redes y control para cualquier nube, cualquier carga de trabajo y cualquier implementación, todo desde una sola interfaz de usuario. Aunque el enfoque de este manual es la creación de una red contenedora segura orquestada por Kubernetes, Contrail puede crear redes virtuales que integren contenedores, máquinas virtuales y servidores sin el metal.
Las redes virtuales son un concepto clave en el sistema de Contrail. Las redes virtuales son construcciones lógicas implementadas encima de las redes físicas. Se utilizan para reemplazar el aislamiento basado en VLAN y proporcionar multiinquilino en un centro de datos virtualizado. Cada inquilino o una aplicación puede tener una o varias redes virtuales. Cada red virtual se aísla de todas las demás redes virtuales, a menos que la Directiva de red lo permita explícitamente. Las redes virtuales se pueden extender a las redes físicas mediante una puerta de enlace. Por último, las redes virtuales se utilizan para–crear un encadenamiento de servicios.
Como se muestra en la Figure 3, el operador de red solo trata la abstracción lógica de la red, por lo que contrail realiza el pesado, el cual incluye, aunque no se limita a, la creación de políticas, el intercambio de rutas y los túneles de compilaciones en la topología física.
Fundamentos de la arquitectura de Contrail
Contrail funciona en un modelo de distribución física centralizada y distribuida con sus dos componentes principales, Contrail controladora y Contrail vRouter. El controlador es el plano de control y administración que administra y configura el vRouter, reuniendo y presentando análisis. El Contrail vRouter es el plano de envío que proporciona servicios de capa 2 y capa 3, y capacidades de Firewall distribuido, mientras se implementan políticas entre redes virtuales.
Contrail se integra con varios Orchestrator, como OpenStack, VMware, Kubernetes, OpenShift y mesos. Utiliza varios protocolos para proporcionar una SDN a estos Orchestrator, como se muestra en la Figure 4 , donde el protocolo de presencia y mensajería extensible (XMPP) es una tecnología Open XML para la comunicación en tiempo real, definida en RFC 6120. En Contrail, XMPP ofrece dos funciones principales: distribuir información de enrutamiento e insertar configuraciones, que son similares a lo que hace IBGP en MPLS los modelos VPN, además de NETCONF en la administración de dispositivos.
La Figure 4 también ilustra lo siguiente:
BGP se utiliza para intercambiar rutas con enrutadores físicos y Contrail administrador de dispositivos puede usar NETCONF para configurar esta puerta de enlace.
Ethernet VPN (EVPN) es una tecnología basada en estándares, RFC 7432, que proporciona conectividad de puente multipunto virtual entre distintos dominios de capa 2 a través de una red IP. El controlador de Contrail intercambia rutas EVPN con los conmutadores de TOR (actuando como puerta de enlace de la capa 2 VXLAN) para ofrecer una recuperación más rápida con el reenvío de VXLAN activo-activo.
MPLSoGRE, MPLSoUDP o VXLAN, son tres tipos diferentes de túneles superpuestos para transportar el tráfico a través de redes IP. Todos son paquetes IP, pero en VXLAN usa los valores VNI en el encabezado VXLAN para la segmentación, mientras que en MPLSoGRE y MPLSoUDP usa el valor etiqueta MPLS para la segmentación.
Para simplificar la relación entre Contrail vRouter, el controlador de Contrail y el tejido IP desde una arquitectura potencial, compárela con el modelo MPLS VPN mientras que’cualquier proveedor de servicios vRouter es como un enrutador PE y el VM/Container es como CE, pero el vRouter es simplemente una herramienta del controlador contrail y, en cuanto a los servidores Bare Metal, la parte superior del bastidor sería el PE
En este día, unlibro utiliza las palabras nodo de cálculo y host indistintamente. Ambas significan que la entidad aloja los contenedores que necesitan un nodo de cálculo para alojarla. Este host podría ser un servidor físico de su DC o una VM en su centro de datos o en la nube pública.
Contrail vRouter
Contrail vRouter se compone de los componentes del Contrail en el nodo o host de cálculo que se muestra en la Figure 5. Para un nodo Compute en la configuración predeterminada del acoplador, los contenedores del mismo host se comunican entre sí, así como con otros contenedores y servicios hospedados en el otro host con un puente de acoplamiento. En Contrail redes, en cada nodo Compute, el vRouter crea una tabla VRF por red virtual, lo que ofrece una larga lista de características.
Desde la perspectiva del plano de control, el Contrail vRouter:
Recibe una configuración de bajo nivel (instancias de enrutamiento y Directiva de reenvío).
Intercambia rutas.
Instala el estado de reenvío en el plano de reenvío.
Informa a los análisis (registros, estadísticas y eventos).
Desde el potencial del plano de datos, el Contrail vRouter:
Asigna paquetes recibidos de la red superpuesta a una instancia de enrutamiento en función de la etiqueta de MPLS o el identificador de red virtual (VNI).
Proxy DHCP, ARP y DNS.
Aplica una directiva de reenvío para el primer paquete de cada flujo nuevo y luego programa la acción a la entrada de flujo en la tabla de flujo del plano de reenvío.
Reenvía el paquete más después de una búsqueda de dirección de destino (IP o MAC) en la base de información de reenvío (FIB), encapsulando/decapsulating paquetes enviados a la red superpuestas o recibidos de ella.
