TFG Daniel Moreno Belinchon

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA
Y SISTEMAS DE TELECOMUNICACIÓN
PROYECTO FIN DE GRADO
TÍTULO: DESPLIEGUE DE MICROSERVICIOS MEDIANTE TÉCNICAS DE

VIRTUALIZACIÓN LIGERAS BASADAS EN CONTENEDORES
AUTOR: DANIEL MORENO BELINCHÓN
TITULACIÓN: TELEMÁTICA
TUTOR: D. ANTONIO DA SILVA FARIÑA
DEPARTAMENTO: INGENIERÍA TELEMÁTICA Y ELECTRÓNICA
VºBº
MIEMBROS DEL TRIBUNAL CALIFICADOR:
PRESIDENTE: D.ª MARÍA PILAR OCHOA PÉREZ

VOCAL: D. ANTONIO DA SILVA FARIÑA
SECRETARIO: D. RUBÉN DE DIEGO MARTÍNEZ
FECHA DE LECTURA: DE DE 2018
CALIFICACIÓN:
El Secretario,
A mis padres
AGRADECIMIENTOS
Después de cuatro años ha llegado el momento de poner fin a esta gran etapa
como estudiante de Ingeniería Telemática, la cual no puedo finalizar sin mostrar mi
agradecimiento a aquellas personas y entidades que han formado parte de ella.
En primer lugar, quiero agradecer a todos los profesores y miembros de la
Universidad Politécnica de Madrid su labor docente y profesional que ha marcado
mi aprendizaje durante estos cuatro años.
En segundo lugar, quiero mostrar un agradecimiento especial a mi tutor, el
Dr. Antonio da Silva Fariña, por su apoyo, confianza y por ofrecerme la oportunidad
de realizar este proyecto a su lado.
Por último, agradecer el apoyo incondicional que me ha prestado mi familia,
y en especial mis padres por ayudarme con su ejemplo y esfuerzo a conseguir todo
lo que me propongo. Sin vosotros nada de esto hubiese sido posible, siempre os
estaré agradecido.
¡GRACIAS!
Daniel Moreno Belinchón
I
II
RESUMEN
Hoy en día el modelo de computación más utilizado sigue siendo el cloud
computing, que permite a una serie de recursos hardware como ordenadores y
servidores, ofrecer una serie de servicios a través de internet.
Con los avances de la tecnología, y con la llegada del internet de las cosas
(IoT) en relativamente poco tiempo el número de dispositivos conectados a la red
ha crecido enormemente. De modo que muy pronto resultará habitual disponer de
gran cantidad de dispositivos domésticos y personales que estén conectados a la red
constantemente. Con estos avances, ha surgido la necesidad de plantear alternativas
a la computación en la nube que permitan distribuir y descentralizar el
procesamiento de los entornos cloud. Es así como surge el fog computing: un
modelo de computación que permite llevar parte de las aplicaciones de cloud,
generalmente en forma de microservicios y VNF (Virtual Network Functions), a los
nodos o extremos de la red con el fin de realizar una parte del procesamiento de la
información antes de transmitirla.
El propósito de este proyecto, Despliegue de microservicios mediante
técnicas de virtualización ligera basadas en contenedores, es el análisis y
despliegue de aplicaciones y VNF a través de la red. Para conseguirlo, se ha realizado
un análisis de las herramientas y tecnologías disponibles que ha servido como base
para posteriormente diseñar determinados entornos reales en los que se han
desplegado una serie de microservicios y funciones virtuales de red.
El proyecto ha sido planteado de forma tenga un alcance que resulte lo más
útil y aproximado a la realidad posible, y por ello se han definido casos de uso y
despliegues que tienen aplicación y sentido práctico en nuestros días.
En primer lugar, se ha realizado un estudio de ingeniería, plasmado en el
presente documento, que ha servido para la adquisición de multitud de
conocimientos relacionados con arquitecturas software, microservicios y
virtualización de funciones de red. Dichos conocimientos han sido puestos en
práctica mediante el diseño e implementación de una serie de escenarios teóricos y
prácticos sobre los que se han desplegado una serie de aplicaciones.
El alcance de este proyecto unido a la filosofía y características de las
tecnologías utilizadas hacen que los escenarios y casos de uso aquí planteados
resulten aplicables a entornos cotidianos de hoy en día en los que se prima la
agilidad, escalabilidad, rapidez, economía y bajo consumo de recursos de las
aplicaciones y servicios desplegados.
III
IV
ABSTRACT
Nowadays the most widely used model of computing continues to be cloud
computing that allows a series of resources hardware such as computers and servers,
offer a series of services via internet.
With the advances in technology and the arrival of the internet of things (IoT)
in a relatively short time the number of devices connected to the network has grown
tremendously. In a short time it will be usual to have lots of domestic and personal
devices constantly connected to the network. With these advances, has emerged the
need to think about alternatives to cloud computing enabling distributed and
decentralized processing of cloud environments. This is how the fog computing
arises: a model of computation which can carry part of cloud applications, usually
as microservices and VNF (Virtual Network Functions), to networks node and
network extremes in order to carry out a part of the processing of the information
before transmitting it.
The purpose of this project, Deployment of microservices by light container-
based virtualization techniques, is the analysis and deployment of VNF and based
on microservices applications across the network. To achieve this, an analysis of the
tools and technologies available has been carried and it has served as basis for
designing certain real environments in which a series of microservices and virtual
networking capabilities have been deployed.
The project has been raised in a way to have a scope that is as useful and real
as possible, and therefore some use cases and deployments that have full application
in our days have been defined.
In the first place, an engineering study has been carried out, reflected in the
present document, which has served to acquire a multitude of knowledge related to
software architectures, microservices and virtualization of network functions. This
knowledge has been put into practice through the design and implementation of a
series of theoretical and practical scenarios on which a bunch of applications have
been deployed.
The scope of this project, together with the philosophy and characteristics of
the technologies used, make the scenarios and use cases proposed here applicable
to today's day-to-day environments where agility, scalability, speed, economy and
low consumption of the applications and deployments prevail.
V
VI
ÍNDICE
AGRADECIMIENTOS ..................................................................................... I
RESUMEN .................................................................................................... III
ABSTRACT ...................................................................................................... V
ÍNDICE ......................................................................................................... VII
LISTADO DE FIGURAS.................................................................................IX
LISTADO DE TABLAS ...................................................................................XI
LISTADO DE ACRÓNIMOS .......................................................................XIII
1. INTRODUCCIÓN .................................................................................. - 1 -
1.1. ALCANCE Y OBJETIVOS DEL PROYECTO ................................. - 2 -
1.2. ESTRUCTURA DE LA MEMORIA ................................................ - 2 -
2. ANTECEDENTES Y MARCO TECNOLÓGICO ................................ - 5 -
2.1. CLOUD COMPUTING ................................................................... - 5 -
2.2. MICROSERVICIOS .................................................................... - 7 -
2.2.1. Introducción a los microservicios ........................................... - 7 -
2.2.2. Características de los microservicios .................................... - 10 -
2.2.3. Contenedores ........................................................................ - 16 -
2.2.4. Orquestadores o gestores ...................................................... - 20 -
2.3. NFV ........................................................................................... - 31 -
2.3.1. Introducción .......................................................................... - 31 -
2.3.2. Características ....................................................................... - 32 -
2.3.3. Soluciones ............................................................................. - 34 -
2.3.4. Relación NFV-SDN ............................................................... - 37 -
2.4. OPENSTACK ............................................................................. - 39 -
2.4.1. Introducción ......................................................................... - 39 -
2.4.2. Componentes ........................................................................ - 39 -
2.4.3. Arquitectura .......................................................................... - 41 -
3. CONSIDERACIONES DE DISEÑO................................................. - 45 -
3.1. ESPECIFICACIONES Y RESTRICCIONES DE DISEÑO ........ - 45 -
3.2. DECISIONES DE DISEÑO ....................................................... - 45 -
4. IMPLEMENTACIÓN Y RESULTADOS .......................................... - 47 -
4.1. Introducción al entorno ............................................................ - 47 -
4.2. Análisis detallado ...................................................................... - 48 -
4.2.1. Escenario 1. Docker Swarm monoarquitectura. ................... - 48 -
4.2.2. Escenario 2. Docker Swarm multiarquitectura. ................... - 51 -
VII
4.2.3. Escenario 3. Kubernetes monoarquitectura. ........................ - 54 -
5. PRESUPUESTO ............................................................................... - 57 -
6. CONCLUSIONES Y TRABAJOS FUTUROS ................................... - 59 -
6.1. CONCLUSIONES ...................................................................... - 59 -
6.2. TRABAJOS FUTUROS ............................................................. - 59 -
7. REFERENCIAS ................................................................................ - 61 -
ANEXOS .................................................................................................... - 67 -
A. ENTORNO DISPONIBLE................................................................ - 69 -
B. DOCKER .......................................................................................... - 71 -
Instalación ............................................................................................. - 71 -
Docker en Ubuntu.............................................................................. - 71 -
Docker en Debian .............................................................................. - 74 -
Instalación genérica ........................................................................... - 76 -
Manejo ................................................................................................... - 77 -
Nociones básicas ................................................................................ - 77 -
Gestión de imágenes y contenedores ................................................ - 77 -
Clúster Docker .................................................................................. - 80 -
C. OPENBATON ................................................................................... - 83 -
a. Instalación Go .............................................................................. - 83 -
b. Instalación VIM Driver para Docker ........................................... - 83 -
c. Instalación VNFM Docker............................................................- 84 -
d. Instalación OpenBaton................................................................. - 85 -
e. Unión OpenBaton & Drivers ........................................................- 86 -
f. Creación de un paquete VNF .......................................................- 89 -
g. Despliegue de VNF .......................................................................- 90 -
D. KUBERNETES ................................................................................. - 93 -
Instalación ............................................................................................. - 93 -
Manejo ................................................................................................... - 94 -
Nociones básicas ................................................................................ - 94 -
Gestión de deployments y pods ......................................................... - 95 -
Clúster Kubernetes ............................................................................ - 97 -
Clúster Kubernetes multiarquitectura ............................................ - 101 -
Desactivar swap ................................................................................... - 105 -
E. CREACIÓN Y DESPLIEGUE DE UN FIREWALL ........................ - 107 -
F. ARQUITECTURA OPENSTACK .................................................... - 111 -
G. INSTALACIÓN DEVSTACK ........................................................... - 113 -
VIII
LISTADO DE FIGURAS
Figura 1: evolución a arquitecturas de microservicios ............................... - 1 -
Figura 2: tipos de servicios en la nube ....................................................... - 5 -
Figura 3: nube pública ................................................................................ - 6 -
Figura 4: nube privada ................................................................................ - 6 -
Figura 5: nube híbrida ................................................................................ - 6 -
Figura 6: implementaciones de SOA .......................................................... - 8 -
Figura 7: evolución arquitectura software ................................................ - 10 -
Figura 8: monolito VS microservicios ...................................................... - 10 -
Figura 9: extracto de The Bell System Technical Journal ......................... - 11 -
Figura 10: ley de Conway .......................................................................... - 12 -
Figura 11: equipos multidisciplinares ....................................................... - 12 -
Figura 12: aplicación descentralizada ....................................................... - 13 -
Figura 13: descentralización de datos ....................................................... - 14 -
Figura 14: comparación monolito y microservicios ................................. - 16 -
Figura 15: arquitectura sin contenedores ..................................................- 17 -
Figura 16: virtualización VS contenedores ................................................- 17 -
Figura 17: histórico descargas Docker ...................................................... - 18 -
Figura 18: arquitectura típica Docker ....................................................... - 20 -
Figura 19: arquitectura Docker Swarm .................................................... - 22 -
Figura 20: interfaz Portainer .................................................................... - 23 -
Figura 21: interfaz Swarmpit .................................................................... - 24 -
Figura 22: interfaz Docker-swarm-visualizer ........................................... - 24 -
Figura 23: ejemplo API Kubernetes ......................................................... - 27 -
Figura 24: arquitectura Kubernetes ......................................................... - 28 -
Figura 25: interés por orquestadores ....................................................... - 29 -
Figura 26: interfaz gráfica Kubernetes ..................................................... - 31 -
Figura 27: esquema ETSI NFV MANO ..................................................... - 33 -
Figura 28: contexto OpenBaton ............................................................... - 34 -
Figura 29: arquitectura OpenBaton ......................................................... - 35 -
Figura 30: VNFM genérico ....................................................................... - 35 -
Figura 31: interfaz OpenBaton .................................................................. - 36 -
Figura 32: enfoque Cloudify ..................................................................... - 37 -
Figura 33: caso de uso Cloudify ................................................................ - 37 -
Figura 34: red tradicional VS SDN ........................................................... - 38 -
Figura 35: arquitectura SDN..................................................................... - 38 -
Figura 36: servicios principales de OpenStack......................................... - 41 -
Figura 37: interfaz gráfica Devstack ......................................................... - 42 -
Figura 38: servicios OpenStack multinodo .............................................. - 43 -
Figura 39: mapa de red del escenario I .................................................... - 49 -
Figura 40: despliegue httpd escenario I ................................................... - 49 -
Figura 41: tiempo de despliegue por réplica httpd escenario I ................ - 50 -
Figura 42: tiempos de despliegue escenario I .......................................... - 51 -
Figura 43: mapa de red del escenario II ................................................... - 51 -
Figura 44: despliegue httpd escenario II .................................................. - 52 -
Figura 45: tiempo de despliegue por réplica httpd escenario II .............. - 53 -
Figura 46: reparto de contenedores ......................................................... - 53 -
IX
Figura 47: mapa de red del escenario III .................................................. - 54 -
Figura 48: despliegue httpd escenario I y escenario III ........................... - 55 -
Figura 49: tiempos de despliegue por réplica httpd escenario III ........... - 55 -
Figura 50: comparativa presupuestos ...................................................... - 58 -
Figura 51: nodos clúster Docker usando CLI ............................................ - 81 -
Figura 52: resumen clúster a través de Portainer .................................... - 81 -
Figura 53: servicios y nodos Docker Swarm .............................................- 82 -
Figura 54: ejemplos servicio Docker Swarm ............................................- 82 -
Figura 55: Docker VIM driver en marcha .................................................- 84 -
Figura 56: VNFM en marcha .................................................................... - 85 -
Figura 57: inicio sesión OpenBaton ..........................................................- 86 -
Figura 58: interfaz principal OpenBaton ..................................................- 86 -
Figura 59: managers VNFM en OpenBaton ............................................. - 87 -
Figura 60: instancias VIM OpenBaton ..................................................... - 87 -
Figura 61: PoP añadido y funcionando en OpenBaton ........................... - 88 -
Figura 62: mensajes Docker VIM Driver ................................................. - 88 -
Figura 63: catálogo NSD OpenBaton ........................................................- 90 -
Figura 64: resumen OpenBaton ...............................................................- 90 -
Figura 65: listado de pods Kubernetes .....................................................- 98 -
Figura 66: interfaz gráfica Kubernetes ..................................................... - 99 -
Figura 67: listado de nodos CLI Kubernetes ............................................ - 99 -
Figura 68: listado de nodos gráfico Kubernetes ..................................... - 100 -
Figura 69: nodos multiarquitectura en Kubernetes ............................... - 104 -
Figura 70: interfaz principal del firewall ................................................ - 107 -
Figura 71: listado de interfaces del firewall ............................................ - 108 -
Figura 72: listado de objetos del firewall ................................................ - 108 -
Figura 73: listado de reglas del firewall .................................................. - 109 -
Figura 74: creación de regla en el firewall .............................................. - 109 -
Figura 75: listado reglas NAT en el firewall ............................................ - 110 -
Figura 76: mapa red FW ......................................................................... - 110 -
Figura 77: arquitectura lógica OpenStack ............................................... - 111 -
Figura 78: gestión de instancias en DevStack ......................................... - 114 -
Figura 79: gestión de contenedores en DevStack .................................... - 114 -
Figura 80: ejemplo contenedor en DevStack I ........................................ - 115 -
Figura 81: ejemplo contenedor en DevStack II ....................................... - 115 -
X
LISTADO DE TABLAS
Tabla 1: arquitectura monolítica VS microservicios ................................. - 15 -
Tabla 2: pods de red .................................................................................. - 28 -
Tabla 3: nodos primer escenario .............................................................. - 47 -
Tabla 4: nodos segundo escenario ............................................................ - 48 -
Tabla 5: costes mano de obra .................................................................... - 57 -
Tabla 6: coste compra de hardware .......................................................... - 57 -
Tabla 7: coste alquiler hardware ............................................................... - 58 -
Tabla 8: características entorno ............................................................... - 69 -
Tabla 9: instrucciones Dockerfile ............................................................. - 79 -
Tabla 10: nodos clúster Docker.................................................................- 80 -
Tabla 11: nodos clúster Kubernetes .......................................................... - 97 -
Tabla 12: nodos clúster multiarquitectura k8s ........................................- 101 -
XI
XII
LISTADO DE ACRÓNIMOS
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
AWS Amazon Web Services
BSS Business Support System
CLI Command Line Interface
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
DevOps Development & Operations
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
EC2 Elastic Compute Cloud
ECS Elastic Container Service
EM Element Management
ESB Enterprise Service Bus
ETSI European Telecommunications Standards Institute
FTP File Transfer Protocol
GCP Google Cloud Computing
GPG GNU Privacy Guard
HTTP HyperText Transfer Protocol
IaaS Infrastructure as a Service
IDL Interface Definition Language
IoT Internet of Things
IP Internet Protocol
J2EE Java 2 platform Enterprise Edition
JSON JavaScript Object Notation
KVM Kernel-based Virtual Machine
LXC Linux Containers
MANO Management and Orchestration
MSA MicroServices Architecture
NAT Network Address Translation
XIII
NFS Network File System
NFV Network Function Virtualization
NFVI NFV Infraestructure
NFVO NFV Orchestrator
NS Network Service
OMG Object Management Group
OSS Operations Support System
PaaS Platform as a Service
QEMU Quick EMUlator
RC Replication Controller
REST Representational State Transfer
RH Red Hat
RHEL Red Hat Enterprise Linux
RPC Remote Procedure Call
RPM Red Hat Package Manager
RS Replication Set
SaaS Software as a Service
SDK Software Development Kit
SDN Software Defined Networking
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
TOSCA Topology and Orchestration Specification for Cloud
Applications
UDP User Data Protocol
UML User Mode Linux
VIM Virtualised Infraestructure Manager
VNF Virtual Network Function
XIV
VNFM VNF Manager
WSDL Web Services Description Language
WWW World Wide Web
XMI XML Metadata Interchange
XML eXtensible Markup Language
XV
XVI
INTRODUCCIÓN
1. INTRODUCCIÓN
Hoy en día en el ámbito de las telecomunicaciones existe cierta tendencia a
llevar los servicios a la nube haciendo uso del cloud computing, una técnica
mediante la cual un grupo de ordenadores y servidores ofrecen servicios de diversos
tipos a través de internet. Se usa principalmente porque ofrece gran cantidad de
ventajas como transparencia, flexibilidad, ubicuidad, seguridad y escalabilidad
entre otras.
Sin embargo, con los avances del internet de las cosas (IoT), y otras
tecnologías entre otras tecnologías, ha surgido la necesidad de pensar en
alternativas a la computación en la nube que permitan distribuir el procesamiento
en los extremos de la red sin necesidad de tener que salir hacia internet para realizar
ciertas operaciones.
Así ha surgido el concepto de fog computing un modelo de computación que
permite llevar ciertos procesos, generalmente en forma de microservicios y VNF
(Virtual Network Functions), a los nodos o extremos de la red con el fin de realizar
un análisis y procesado de la información antes de transmitirla.
Este proyecto se basa, principalmente, en el estudio de microservicios, NFV
(Network Function Virtualization) y otras tecnologías necesarias para el manejo y
despliegue de los mismos.
Por un lado, las arquitecturas de microservicios defienden un modo de
despliegue, basado en SOA (Service Oriented Architecture), que permita distribuir
aplicaciones como un conjunto de servicios débilmente acoplados que funcionan de
forma independiente y aislada. La evolución y arquitectura básica se plasma en la
figura 1 [1].
Figura 1: evolución a arquitecturas de microservicios
Por otro lado, NFV proporciona la capacidad de virtualizar componentes y

funciones de red –típicamente firewalls, routers y otros componentes– reduciendo
así una serie de inconvenientes tradicionales como los costes de instalación, la vida
útil relativamente corta de los dispositivos y la gran inversión necesaria en
infraestructuras.
-1-
A lo largo de este proyecto se van a analizar y poner en práctica tanto estas
dos tecnologías como todas las necesarias para poder comprender y desplegar
microservicios y NFV.
1.1. ALCANCE Y OBJETIVOS DEL PROYECTO
Este proyecto tiene como finalidad principal el análisis y despliegue de
aplicaciones diseñadas en base a la arquitectura de microservicios a través de la red,
haciendo uso de una serie de tecnologías como NFV.
Para ello se han definido una serie de objetivos divididos por tecnologías. En
primer lugar, los relacionados con la arquitectura de microservicios son:
 Analizar el estado del arte
 Comprender su filosofía y arquitectura
 Analizar y comprender los métodos de despliegue de microservicios:
contenedores
 Estudiar con detalle tareas necesarias como la orquestación
 Identificar las tecnologías que mejor se adaptan al entorno
 Aplicar los conocimientos a un caso de uso sencillo
 Preparar un entorno adecuado para el despliegue de una aplicación
basada en microservicios haciendo uso de las tecnologías estudiadas
 Definir y desplegar una aplicación funcional
Por otro lado, los objetivos relativos a VNF son:
 Análisis del estado del arte
 Estudiar su filosofía y arquitectura
 Estudiar las normas que rigen su aplicación y definición como ETSI
(European Telecommunications Standards Institute)
 Identificar las tecnologías que mejor se adaptan al entorno
 Aplicar y relacionar los conceptos con las tecnologías estudiadas de
microservicios y contenedores
Una vez definidas las dos bases principales del proyecto (microservicios y
NFV) queda pendiente la relación y aplicación de ambas en su conjunto, surgiendo
necesario el estudio de diversas tecnologías como OpenBaton, Cloudify y OpenStack
que se estudian en este proyecto.
1.2. ESTRUCTURA DE LA MEMORIA
En primer lugar, el primer capítulo recoge una introducción que aparte de
servir para poner en contexto e introducir la arquitectura de microservicios y NFV
también recoge de forma resumida el alcance y la estructura de la memoria.
En el capítulo dos se recogen de forma más detallada un análisis de los
conceptos y puntos clave de las tecnologías que se utilizan en el proyecto. El objetivo
del mismo es introducir aquellos conceptos más importantes de las tecnologías que
se han utilizado y estudiado en este proyecto, y por lo tanto su lectura será clave para
la comprensión de la filosofía y características que definen cada una de ellas.
-2-
INTRODUCCIÓN
El capítulo tres recoge una serie de consideraciones de diseño que han

condicionado el desarrollo del proyecto. Se han separado por un lado las
especificaciones y restricciones y por otro lado las decisiones de diseño.
En el capítulo cuatro se recogen los procesos de implementación y los
resultados obtenidos. En primer lugar, en este capítulo se introduce el entorno
disponible para después analizar detalladamente cada uno de los escenarios y los
resultados obtenidos. Teniendo en cuenta las especificaciones y restricciones de
diseño recogidas en el tercer capítulo, se han tomado una serie de decisiones de
diseño, explicadas en cada apartado, que han definido y condicionado los entornos
y las tecnologías de trabajo. Gran parte del trabajo de este capítulo está definido en
los anexos del último capítulo con la intención de no hacer demasiado extensa la
parte de implementación y resultados.
El quinto capítulo recoge el presupuesto, en varias modalidades, considerado
para este proyecto.
En el sexto capítulo se recogen las conclusiones sacadas de este proyecto y los
trabajos que quedan pendientes de realización en el futuro.
El séptimo capítulo recoge un listado de referencias que han sido utilizadas
para la elaboración del proyecto.
Para finalizar, en el último capítulo se han definido una serie de anexos con
el objetivo de servir de guía de instalación, configuración y consideraciones de
manejo de las tecnologías utilizadas.
-3-
-4-
ANTECEDENTES Y MARCO TECNOLÓGICO
2. ANTECEDENTES Y MARCO TECNOLÓGICO

2.1. CLOUD COMPUTING
La computación en la nube (cloud computing) es un paradigma tecnológico
mediante el cual un grupo de ordenadores y servidores ofrecen servicios de diversos
tipos a través de internet. Hoy en día existe una gran tendencia a llevar los servicios
a la nube por la gran cantidad de ventajas que ofrece: flexibilidad, ubicuidad,
transparencia, seguridad, escalabilidad…
La mayoría de los servicios informáticos que residen en la nube se encuentran
comprendidos dentro de las siguientes categorías [2]:
 SaaS (Software as a Service): cualquier servicio ofrecido a través de la
web. Por ejemplo, Outlook, Gmail, Office 365, Dropbox…
 PaaS (Platform as a Service): es una solución de cloud computing que
proporciona a los usuarios un entorno sobre el que diseñar y
desarrollar sus aplicaciones. El proveedor proporciona la
infraestructura que se necesita para el desarrollo. Algunos ejemplos
son Google App Engine, Red Hat Openshift.
 IaaS (Infrastructure as a Service): solución de cloud computing que
ofrece recursos físicos y virtuales sobre los que montar los entornos y
aplicaciones. Es la capa más completa y compleja de todas, ofrece al
cliente la libertad de decidir qué quiere hacer con los recursos
hardware de los que dispone. Por ejemplo: AWS (Amazon Web
Services), OpenStack y Azure.
 CaaS (Container as a Service): permite disponer de contenedores bajo
demanda. Se trata de una variante intermedia entre Iaas y PaaS. Aún
no existen muchos proveedores de servicios CaaS; los más destacados
son OpenStack Magnum, Docker Universal Control Plane y otras
variantes que permiten gestionarlos como Kubernetes y AWS ECS
(Elastic Container Service).
Figura 2: tipos de servicios en la nube
Sin embargo, con los avances del internet de las cosas (IoT) [3], entre otras
tecnologías, ha surgido la necesidad de pensar en alternativas a la computación en
la nube que permitan distribuir el procesamiento en los extremos de la red sin
necesidad de tener que salir hacia internet para ciertas operaciones.
-5-
Así ha surgido el concepto de fog computing [4], un modelo de computación
que permite llevar ciertos procesos, generalmente en forma de microservicios, a los
nodos o extremos de la red con el fin de realizar un análisis y procesado de la
información antes de transmitirla.
Por otro lado, en función del alcance o ubicación de los servicios las nubes
pueden ser clasificadas en [5]:
 Públicas: cuando el proveedor ofrece una serie de servicios de forma abierta
a todas las entidades que lo deseen.
Figura 3: nube pública
 Privadas: cuando los recursos ofrecidos no son accesibles para todo el

mundo, típicamente para una empresa u organización privada.
Figura 4: nube privada
 Híbridas: cuando se combinan ambos tipos para obtener un tipo de nube

flexible que ofrece parte de los servicios de forma pública y parte de forma
privada.
Figura 5: nube híbrida
-6-
2.2. MICROSERVICIOS
2.2.1. Introducción a los microservicios
Hasta hace relativamente poco, el método tradicional de desarrollo de
aplicaciones más común se basaba en arquitecturas monolíticas, es decir, aquellas
cuyo objetivo es conseguir una aplicación única y de un solo nivel que se comporta
como una sola entidad, autónoma e independiente del resto.
Típicamente las aplicaciones empresariales están compuestas por tres capas
principales: una capa servidora que contiene gran parte de la lógica y responde a
peticiones, la parte de almacenamiento normalmente en forma de base de datos y la
parte del cliente que suele ser una mera interfaz de acceso a los datos ofrecidos por
el servidor [6]. En dichas aplicaciones, la parte servidora, por ejemplo, se encarga
de recibir peticiones, procesarlas accediendo a la lógica y base de datos y devolver
una respuesta. Su comportamiento es monolítico pues sus componentes no son
independiente del resto y se comporta como una única entidad que no realiza una
sola tarea, sino que realiza una serie de pasos para completar una determinada
función.
Existen muchos casos de éxito de aplicaciones monolíticas. La ventaja
principal de las mismas es que suelen tener buen rendimiento al tener toda la lógica
y procesos concentrados en un único sistema. Sin embargo, son bastantes las
desventajas que han hecho que esta arquitectura quede de lado y se busquen otras
alternativas. Las desventajas principales son [7]:
 Los elementos de una aplicación monolítica están fuertemente ligados
y relacionados, lo que implica que cualquier cambio en el monolito,
por pequeño que sea, implicará volver a construir y distribuir el
mismo.
 Compilar y generar los ejecutables suele llevar horas.
 Las aplicaciones por lo general carecen de modularidad. Es decir, no
están divididas en módulos o subprogramas, y por tanto no permiten
reutilización de partes de la aplicación y su mantenimiento y
reparación es más costoso.
 No son escalables verticalmente puesto que cualquier cambio en el
sistema implicará volver a desplegar la aplicación.
 Resulta difícil aislar ciertas partes de la aplicación puesto que todas
ellas comparten el mismo entorno de ejecución.
 Ciertas decisiones de diseño enfocadas a una parte de la aplicación
pueden afectar fuertemente a otras partes.
 Los monolitos son, por lo general, aplicaciones muy amplias con gran
cantidad de dependencias que resultan muy difíciles de entender y
mantener.
En definitiva, las aplicaciones monolíticas son muy difíciles de mantener
debido principalmente a su falta de modularidad y escalabilidad.
Hay diferentes formas de alcanzar esa modularidad y escalabilidad, por
ejemplo, a través de arquitecturas orientadas a servicios como SOA.
-7-
De acuerdo con IEEE- Std 1471-2000 [8], una arquitectura software define
“la organización fundamental de un sistema encarnado en sus componentes, las
relaciones que tienen entre sí, el entorno y los principios que guían su diseño y
evolución”
SOA es estilo arquitectónico basado en distintas piezas de software que
ofrecen unas determinadas funcionalidades como servicios haciendo uso de
protocolos de comunicación normalmente a través de la red. Pero, ¿qué es un
servicio? Un servicio es un mecanismo que permite el acceso a unos determinados
recursos a través de la red. Es entendido como una representación lógica y discreta
de una actividad de negocio que resuelve una determinada necesidad [9].
Algunos principios de SOA son:
 Autonomía: los servicios son independientes y ellos mismos controlan
su funcionalidad.
 Abstracción: un servicio es entendido como un sistema transparente,
solo se debe conocer la forma de invocarlo y se obtiene la respuesta.
 Carecen de estado: los servicios dan una respuesta en función de la
petición, pero no de transacciones previas, lo que hace que el
rendimiento sea mayor.
 Modularidad: las tareas se reparten en diferentes servicios con el fin
de tener piezas de código más pequeñas y específicas.
 Reusabilidad: los servicios pueden ser divididos en tantos como se
necesite con el fin de poder reutilizarlos y disponer de un sistema más
modular.
 Encapsulamiento: unos servicios pueden encapsular a otros.
 El contrato de servicio está estandarizado en el que se define un
acuerdo de comunicación que especifica el punto de entrada o de
llamada al sistema.
Como se puede ver en la figura 6 [9], las arquitecturas SOA pueden ser
implementadas a través de diferentes tecnologías.
Figura 6: implementaciones de SOA
-8-
Una de las implementaciones más comunes de SOA son los Web Services
(Servicios Web), componentes software que encapsulan una funcionalidad
específica y pueden ser accedidos a través de protocolos estándares de internet. Las
tecnologías asociadas más comunes son [10]:
 HTTP (HyperText Transfer Protocol) es el protocolo de comunicación
por excelencia de internet que permite las transferencias de
información a través en la WWW (World Wide Web). Muchos de los
servicios web se construyen en HTTP y hace que estos sean accesibles
a través de Internet.
 XML (eXtensible Markup Language) es un lenguaje de marcado
estándar que sirve para definir la estructura de los datos.
 WSDL (Web Services Description Language) es un lenguaje basado en
XML que se utiliza para describir los servicios web. Se utiliza para
describir detalladamente las interfaces públicas de los servicios y la
forma de comunicación de los mismos.
 SOAP (Simple Object Access Protocol) es un protocolo de mensajería
definido en XML para el intercambio de información en entornos
distribuidos y heterogéneos. Es independiente de la plataforma y
lenguajes de desarrollo y puede trabajar sobre cualquier pila de
protocolos, por ejemplo: HTTP, SMTP (Simple Mail Transfer
Protocol)…
 UDDI (Universal Description, Discovery and Integration) es un
estándar basado en XML para describir, publicar y encontrar servicios
web.
Otras implementaciones muy comunes de SOA son:
 CORBA (Common Object Request Broker Architecture) [11] es un
estándar definido por el OMG (Object Management Group) 1 que
describe un mecanismo de mensajería para la comunicación entre
objetos remotos distribuidos de forma heterogénea a través de la red.
La comunicación se establece a través de unas interfaces definidas en
IDL (Interface Definition Language) y es independiente del sistema
operativo y del lenguaje de programación utilizado.
 DCOM (Distributed Component Object Model) es una tecnología
propiedad de Microsoft para distribuir software a través de la red.
 J2EE (Java 2 Platform Enterprise Edition) permite la definición de
aplicaciones orientadas a servicios.
En los últimos años, existe una implementación de SOA que está ganando
mucho peso, son las MSA (MicroServices Architectures). En la figura 7 [9] se
muestra la evolución de las arquitecturas de software durante los últimos años.
1 OMG es un consorcio fundado en 1989 dedicado al cuidado y establecimiento de estándares
de tecnologías orientadas a objetos como CORBA, UML y XMI (XML Metadata Interchange) entre
otras.
-9-
Figura 7: evolución arquitectura software
Las arquitecturas basadas en microservicios plantean la distribución de

aplicaciones a través de en entidades muy pequeñas llamadas servicios. Cada uno
de estos servicios se centrará en cumplir con una determinada función, podrá ser
comunicado con el exterior a través de mecanismos de comunicación ligeros como
HTTP y será fácilmente escalable desplegable.
Cada uno de esos servicios encapsula una o varias funcionalidades
específicas.
2.2.2. Características de los microservicios
Las arquitecturas basadas en microservicios se centran en distribuir
aplicaciones en pequeños módulos o entidades llamados servicios.
Cada uno de estos servicios ofrece una funcionalidad específica y es distribuible y
escalable de forma independiente al resto, alcanzando así un amplio grado de
modularidad que en otras arquitecturas, como la monolítica, sería impensable.
Véase figura 8 [12]
Figura 8: monolito VS microservicios
Aunque se trata de una arquitectura que está de moda y parece muy

novedosa, su filosofía no es tan moderna pues coincide con los principios del sistema
operativo Unix.
En la figura 9 se muestra un extracto del periódico “The Bell System Technical
Journal” [13] publicación de julio-agosto del año 1978 que recoge un escrito de
Malcolm Douglas McIlroy, programador y director del Centro de Investigación de
Ciencias de Computación de los Laboratorios Bell, lugar de origen de Unix. En él se
- 10 -
puede leer uno de los principios de Unix y posteriormente de las arquitecturas

basadas en microservicios: “hacer que cada programa haga una tarea bien. Para
hacer una nueva tarea construir otro en lugar de complicar los programas viejos
añadiendo nuevas ‘características’ ” Está accesible en: [14]
Figura 9: extracto de The Bell System Technical Journal
Aunque no hay un patrón estrictamente definido para las arquitecturas

basadas en microservicios, la mayoría de ellas comparten las siguientes
características:
Engloba componentes a través de servicios
Tradicionalmente, con el propósito de escribir código reutilizable se hacía uso
de librerías como parte de software, es decir componentes enlazados al programa
que son accesibles a través de llamadas a funciones.
Las arquitecturas basadas en microservicios utilizan bibliotecas aunque su
modo principal de dividir su software en componentes es mediante los servicios.
Las bibliotecas son componentes vinculados a un programa a los que se
accede a través de llamadas, mientras que los servicios son componentes fuera de
proceso que se comunican mediante peticiones a servicios web o a través de RPC
(Remote Procedure Call).
Una de las razones para utilizar servicios como componentes en lugar de
bibliotecas es que los servicios se pueden implementar de forma totalmente
independiente. Es decir, si se dispone de una aplicación basada en diversas
bibliotecas y se quiere hacer un cambio en una de ellas surgirá la necesidad de
desplegar la aplicación por completo; mientras que si se hace en base a servicios
simplemente habrá que volver a desplegar el servicio modificado.
Organizado en torno a capacidades de negocio
Como consecuencia de la ley de Conway [15], un cambio en una parte
técnica de una aplicación monolítica suele englobar a varios sectores o partes de
desarrollo de la misma. Por ejemplo, un cambio en la estructura de la base de
datos influirá en la parte del middleware y de la interfaz gráfica implicando así
volver a distribuir la aplicación. Véase figura 10.
- 11 -
Figura 10: ley de Conway
Ley de Conway [15]: “Any organization that designs a system (defined

broadly) will produce a design whose structure is a copy of the organization's
communication structure”
Con las arquitecturas orientadas a microservicios esta visión es diferente,
pues lo que se pretende es organizar dichos servicios en torno a capas de negocio.
Es decir, cada uno de ellos ha de encargarse de una sola funcionalidad de negocio,
pero ha de cumplir completamente con ella, incluyendo interfaces de usuario,
almacenamiento… Véase figura 11.
Figura 11: equipos multidisciplinares
En consecuencia se dispondrá de equipos multidisciplinares que serán capaces de

gestionar por completo el servicio en todos sus aspectos pudiendo así hacer cambios
o redistribuciones del mismo sin que se vean afectadas otras partes de la aplicación.
Es muy común hacer uso del término DevOps (Development and Operations) [16],
una metodología ágil para la creación de software que basándose en la comunicación
entre los equipos de desarrollo y operaciones permite crear software más rápido,
con más calidad y con menor coste.
Productos no proyectos
Normalmente las aplicaciones son consideradas como un proyecto que se
desarrolla por un equipo constituido para tal fin. Una vez se desarrolla el equipo se
suele disolver y la aplicación pasa a estar controlada por la sección de
mantenimiento.
- 12 -
Sin embargo, con las arquitecturas basadas en microservicios se pretende que

el equipo permanezca ligado al producto, siendo su responsable durante toda su vida
útil.
Extremos inteligentes, comunicaciones sencillas
Es común, en algunas arquitecturas SOA, hacer uso de ESB (Entreprise
Service BUS) [17] como elemento de comunicación entre determinados servicios.
Aunque existen muchas definiciones e implementaciones distintas en relación a un
ESB, se puede concluir con que es un componente sofisticado para la comunicación
entre servicios web que ofrece una capa de abstracción y una serie de mecanismos
que permite llevar a cabo funciones como enrutamiento de mensajes, conversión,
desacoplamiento de servicios, coreografía y tareas de seguridad entre otras.
Sin embargo las aplicaciones basadas en microservicios pretenden estar lo
más desacopladas y aisladas posible centrando su esfuerzo en la funcionalidad y no
en la comunicación. De esta forma, un microservicio recibirá una petición, la
procesará y en consecuencia producirá una respuesta. La comunicación más
habitual entre microservicios se hace a través del protocolo HTTP o a través de un
mecanismo de mensajería ligero como RabbitMQ [18] que simplemente
proporciona un mecanismo de comunicación asíncrono basado en una cola.
Gobierno descentralizado
A menudo en las fases de diseño de software es necesario tomar una serie de
decisiones y restricciones que marcarán todo el desarrollo de la aplicación, como por
ejemplo qué lenguaje de programación se va a usar, qué entornos, arquitectura…
Con las arquitecturas monolíticas no es una tarea sencilla pues un lenguaje puede
resolver muy bien un determinado problema pero puede ser muy tedioso para el
resto.
Sin embargo, con las arquitecturas basadas en microservicios estas
decisiones pueden ser tomadas para cada uno de los servicios, permitiendo así
escoger los entornos, lenguajes y demás condicionantes que mejor se adapten a un
problema en concreto.
Por ejemplo, como se muestra en la figura 12 [19] cada microservicio de la
aplicación es independiente y las decisiones de diseño de cada uno de ellos no
afectan al resto de microservicios.
Figura 12: aplicación descentralizada
- 13 -
Gestión de datos descentralizada
En el modelo monolítico se tiende a disponer de un único almacén de datos,
o varios en alta disponibilidad, con el fin de garantizar la persistencia y coherencia
de los mismos. Sin embargo, con las arquitecturas basadas en microservicios se
defiende que cada microservicio gestione su propio sistema de base de datos. Una
representación se muestra en la figura 13.
Figura 13: descentralización de datos
Automatización de infraestructura
El gran desarrollo de la computación en la nube de los últimos años ha traído
consigo la mejora de las técnicas de automatización disponibles para los
microservicios.
Las técnicas de automatización han evolucionado y mejorado mucho con la
computación en la nube, lo que hace que los microservicios puedan ser fácilmente
desplegados y depurados en tiempo real. Además, haciendo uso del continuous
delivery2 se puede tener siempre la última versión desplegada en producción.
Diseñados para fallar
Como consecuencia de utilizar los servicios como componentes, las
aplicaciones han de ser diseñadas para tolerar los fallos puesto que cualquier
llamada puede no ser respondida debido a la indisponibilidad del servidor. Visto así,
es una desventaja en comparación con las arquitecturas monolíticas puesto que
supone un extra de trabajo para solventarlo. Sin embargo, una vez un servicio es
diseñado y preparado para fallar la aplicación el su conjunto es mucho más robusta
y estable que si se tratase de una aplicación monolítica.
Con el fin de conseguir servicios tolerantes a fallos es importante detectarlos
rápido y disponer de los sistemas de automatización que se han tratado en el punto
anterior para desplegar nuevas versiones en caso de que sea necesario. En estos
2 Continuous delivery o entrega continua es un mecanismo de ingeniería de software basado
en el desarrollo en ciclos cortos que permite la liberación de software en cualquier momento.

- 14 -
entornos es muy importante monitorizar continuamente el servicio con el fin de

obtener muestras y anticiparse a comportamientos futuros.
Es muy común durante las fases de desarrollo y test de las aplicaciones
programar y provocar fallos en ciertas partes con el fin de diseñar y obtener un
sistema tolerante a los mismos.
Para resumir, un microservicio es un conjunto de software que encapsula las
mínimas funcionalidades posibles y que tiene las siguientes características:
 Independencia: los componentes de una arquitectura de
microservicios pueden ser cambiados, actualizados y reemplazados de
forma independiente sin afectar al comportamiento del resto.
 Agilidad: al desglosar las funcionalidades en servicios pequeños y
simples los equipos de desarrollo DevOps se centran únicamente en lo
relativo al servicio reemplazando así las metodologías de diseño
software tradicional y costoso por las metodologías ágiles actuales.
 Escalabilidad: los microservicios están diseñados para ser escalados
vertical y modularmente.
 Abstracción: el servicio es administrado por un equipo que se abstrae
completamente del resto de ellos.
 Eficiencia: con los microservicios el uso del código y de las
infraestructuras subyacentes es mucho más eficiente, lo que implica
ahorros de coste de hasta el 50% en algunos casos.
 Resiliencia: al dispersar la funcionalidad en múltiples servicios se
reduce la posibilidad de que la aplicación falle en un solo punto. El
resultado son aplicaciones mucho más robustas que se comportan
mejor, permanecen menos tiempo inactivos y son fácilmente
escalables bajo demanda.
 Ingresos: la tolerancia a fallos, reducción de infraestructuras y de
tiempos de desarrollo, aumento de la resiliencia y estabilidad hace que
las aplicaciones sean más baratas y puedan generar más ingresos.
Como se ha visto, la arquitectura de microservicios presenta muchas ventajas
en determinados aspectos con respecto a la arquitectura monolítica. Véase la tabla
1 en la que se muestran las principales diferencias entre ambas arquitecturas [20].
Tabla 1: arquitectura monolítica VS microservicios
Aspecto Arquitectura monolítica Arquitectura de microservicios

Código Un código para toda la Cada microservicio tiene su base
aplicación de código
Comprensibilidad Compleja Mucho más entendible y
manejable
Mantenimiento Costoso Sencillo
Despliegue Costoso y lento Rápido y continuo
Lenguaje de Típicamente la aplicación Cada microservicio es
programación entera suele estar independiente y puede estar
programada en un lenguaje escrito en otro lenguaje de
único programación
- 15 -
Escalado Horizontal: hacer copias de la Vertical: se puede escalar aquella
aplicación al completo parte de la aplicación que se
necesite
Sin embargo como se observa en la figura 14 [21] la arquitectura monolítica
sigue resultando más productiva para aquellos problemas y situaciones que se
caracterizan por su sencillez.
Figura 14: comparación monolito y microservicios
Teniendo en cuenta los aspectos principales -como agilidad, independencia y

abstracción- que caracterizan a los microservicios parece lógico pensar que para
desplegarlos se necesitará un método compatible con todas las características
enumeradas. Por eso mismo, el despliegue de microservicios se lleva a cabo
generalmente haciendo uso de los contenedores que se estudiarán a continuación.
2.2.3. Contenedores
Los contenedores [22] son un conjunto de procesos aislados y separados del
sistema que pueden ejecutarse desde una imagen (microservicio) que contiene todos
los archivos y recursos necesarios para dar soporte a los procesos. Se trata pues de
una imagen portátil que contiene todo lo necesario para ser ejecutada en entornos
distintos y su comportamiento será siempre el mismo independientemente del
entorno.
Antes de continuar con las características y detalles de los contenedores cabe
hacer mención a una serie de arquitecturas que pueden ser encontradas a la hora de
ejecutar aplicaciones y que han servido de precursoras de los contenedores.
En primer lugar, el método clásico de ejecución de aplicaciones en un
servidor es el que aparece en la figura 15 [23]. En él se dispone de una serie de
componentes hardware sobre los que se instala el sistema operativo y un conjunto
de librerías necesarias para la aplicación o aplicaciones. Este modelo está muy ligado
a las aplicaciones monolíticas y presenta una serie de inconvenientes como:
complejidad a la hora de conseguir todas las librerías, las aplicaciones suelen
necesitar versiones concretas de librerías que pueden ser incompatibles entre sí,
dificultad de actualización, dependencia de componentes…
- 16 -
Figura 15: arquitectura sin contenedores
Por otro lado, con el fin de conseguir aislamiento entre procesos y

aplicaciones, existen técnicas como la virtualización que permiten, como se muestra
en la figura 16 [23], ejecutar partes de aplicación o servicios en entornos aislados e
independientes. Sin embargo, presenta una serie de desventajas como: redundancia
del kernel para cada máquina virtual, sistemas operativos duplicados en muchos
casos, consumo elevado de recursos al aumentar la cantidad de máquinas en
ejecución… Así fue cómo surgió la necesidad de los contenedores: un enfoque nuevo
basado en técnicas de virtualización ligera que permite aislar completamente a las
aplicaciones haciendo uso de un único sistema operativo.
Figura 16: virtualización VS contenedores
Existen varias técnicas que nos permiten hacer uso de contenedores:

En primer lugar, LXC (Linux Containers) [24] es una tecnología surgida en
2008 de virtualización a nivel de sistema operativo para Linux que permite la
ejecución simultánea de varios entornos virtuales aislados en un mismo servidor.
LXC se basa en los grupos de control, conocidos como cgroups de Linux: una
característica que permite al kernel limitar los recursos –CPU, memoria, disco,
entrada/salida y red– que son asignados a una serie de procesos. LXC fue
reemplazado posteriormente por LXD: un hipervisor de contenedores que ofrece
una experiencia de usuario similar a la ofrecida por máquinas virtuales pero
haciendo uso de contenedores Linux.
Posteriormente, en 2013 surgió lo que hoy en día conocemos como Docker
[25]. Se trata ni más ni menos que una extensión de las capacidades de LXC que
proporciona una API (Application Programming Interface) de alto nivel para la
- 17 -
virtualización ligera de contenedores. Está escrito en Go y utiliza LXC, cgroups y el
kernel de Linux.
Aunque LXC y Docker pueden complementarse, la sencillez y la interfaz de
alto nivel ofrecida por Docker le han llevado a ser la plataforma más usada y
evolucionar y crecer desmesuradamente desde su creación, hasta el punto de llegar
a los 12 billones de descargas de imágenes en 2018. Véase figura 17 [26].
Figura 17: histórico descargas Docker
Debido a las características y ventajas que presenta Docker, este trabajo se

realizará con dicha tecnología.
Introducción a Docker
Docker es una plataforma de código abierto diseñada para el despliegue de
aplicaciones ligeras, portables y basadas en contenedores autosuficientes que
pueden ejecutarse virtualmente en cualquier parte.
Antes de comenzar con sus características, cabe hacer introducción a una
serie de conceptos:
 Imágenes Docker: son plantillas para crear contenedores. Una imagen
contiene los pasos de instalación de una aplicación –entendida como
una pieza de software independiente– y los procesos a ejecutar cuando
se ejecute la instancia. Las imágenes Docker suelen ser construidas en
base a un Dockerfile.
 Dockerfile: es el núcleo de un proyecto Docker. Se trata de un fichero
que contiene las instrucciones que indican como se debe construir la
imagen Docker.
 Contenedor Docker: es una imagen Docker en ejecución que se ha
creado a partir de las instrucciones encontradas en la imagen. El
contenedor reúne todos los recursos necesarios para que la aplicación
pueda ser ejecutada de forma independiente, incluyendo un pequeño
sistema operativo, ficheros, dependencias…
- 18 -
 Registro Docker: repositorio de imágenes, público o privado, en el que

los usuarios pueden subir y descargar imágenes. El registro más
popular es Docker Hub3.
Características de los contenedores Docker
 Ligeros: al ser ejecutados sobre un sistema operativo, se trata de
imágenes o paquetes muy ligeros en comparación con las máquinas
virtuales.
 Kernel compartido: los contenedores se ejecutan bajo un sistema
operativo que no es exclusivo para ellos.
 Rapidez: al tratarse de imágenes ligeras que corren bajo un sistema
operativo compartido su ejecución es mucho más rápida.
 Menor consumo de recursos y mayor rendimiento: el OS es
compartido y los contenedores comparten procesos kernel por lo que
se mejora el rendimiento con respecto a las aplicaciones que arrancan
un sistema operativo por completo.
 Ubicuidad: los contenedores pueden ser ejecutados virtualmente en
cualquier entorno, independientemente del sistema operativo y de si
son máquinas físicas o virtuales.
 Aislamiento y seguridad: los contenedores virtualizan CPU, memoria,
almacenamiento y redes a nivel de sistema operativo, lo que los hace
independientes entre sí. Normalmente cada microservicio es
distribuido en un contenedor.
 Portabilidad: pueden ser diseñados localmente y distribuidos en la
nube.
 Reutilización de componentes: permite reutilizar componentes y crear
unos que sirvan como base de otros.
 Control de versiones: en su versión básica dispone de un gestor y
clasificador de versiones.
 Escalabilidad: la cantidad de réplicas de un contenedor puede ser
modificada y automatizada en cualquier momento.
 Librerías compartidas: existen repositorios públicos y fácilmente
accesibles que permiten a la comunidad crecer y hacer uso de cientos
de imágenes actualizadas.
Como se ha mencionado anteriormente, la arquitectura de microservicios se
basa en desplegar una aplicación en gran cantidad de entidades independientes que
cumplen con una determinada función. Los microservicios van encapsulados y son
distribuidos a través de contenedores. Es por ello que a la hora de poner en
producción una determinada aplicación que tenga cierto nivel de tráfico y de
usuarios que la utilicen sea fundamental la existencia de un componente de gestión,
típicamente un orquestador, que se encargue de la sincronización y manejo de los
3 Docker Hub accesible a través de https://hub.docker.com/

- 19 -
microservicios [27]. En el siguiente apartado se recogen una serie de soluciones que
pueden resultar útiles a la hora de gestionar y orquestar contenedores.
2.2.4. Orquestadores o gestores
Antes de comenzar con las herramientas de manejo de contenedores cabe
introducir unos términos que serán utilizados a continuación. En el ámbito de
Docker:
 Nodo: es una instancia (host) de Docker Engine que puede o no
participar en un clúster. Hay dos tipos de nodos, véase figura 18 [28]:
o Manager: nodo encargado de gestionar el clúster y distribuir las
tareas entre los nodos worker. Si hay varios nodos manager uno
de ellos es seleccionado como líder y se encarga de mantener el
estado general del clúster.
Para entornos de producción se recomienda que existan al
menos cinco swarm managers, aunque en entornos reducidos
es suficiente con uno o dos. Los nodos manager utilizan el
algoritmo de consenso Raft4 para garantizar que todos y cada
uno de ellos están en un estado de consistencia que garantiza
un funcionamiento correcto en caso que alguno de ellos falle.
o Worker: nodo encargado de recibir y ejecutar tareas
(contenedores).
Nota: un nodo manager puede actuar como worker simultáneamente.
Figura 18: arquitectura típica Docker
 Clúster: conjunto o agrupación de nodos físicos o virtuales que

ejecutan Docker Engine en modo swarm.
 Modo swarm: estado en el que se ponen los nodos para poder formar
parte de un clúster, ejecutando una serie de servicios y tareas
específicas. En este modo se garantizan una serie de servicios como el
balanceo de carga que se detalla a continuación.
4 Raft es un algoritmo de consenso que permite distribuir el estado de una máquina a lo largo
de un clúster, asegurando que cada uno de los nodos del clúster están en el mismo estado y
garantizando la consistencia de la información.
- 20 -
 Balanceo de carga: técnica basada en distribuir el flujo de trabajo y/o

de información entre una serie de dispositivos. Se usa con el fin de
incrementar la capacidad y disponibilidad de las aplicaciones.
Los balanceadores de carga más comunes se dividen en dos categorías
[29]: los de capa cuatro que separan el tráfico de las capas de
transporte y de red como IP (Internet Protocol), TCP (Transmission
Control Protocol), FTP (File Transfer Protocol) y UDP (User Data
Protocol) entre otros, y los de capa siete que lo hacen en base a
protocolos de aplicación como HTTP.
Los balanceadores de carga trabajan en base a algoritmos muy
utilizados en los sistemas operativos como por ejemplo Round Robin
(muy utilizado en servicios de resolución de nombres como DNS),
Weighted Round Robin, Least Connections, Least Response Time…
El balanceo de carga es un concepto muy importante puesto que puede
aportar otras ventajas adicionales a los servicios como alta
disponibilidad, seguridad, elasticidad y flexibilidad.
 Servicios: tareas a ejecutar en los nodos. Cuando se crea un servicio se
define su estado óptimo, es decir: número de réplicas, datos de red y
almacenamiento, recursos, preferencias de ejecución… Durante el
tiempo de vida del servicio, el clúster se encargará de intentar
mantener dicho estado, llevando a cabo tareas de balanceo de carga y
alta disponibilidad.
 Tareas: son la unidad de trabajo de Docker. Es decir, cada uno de los
trabajos que se ejecutan dentro de los contenedores. Los nodos
manager asignan tareas a los trabajadores de acuerdo al número de
réplicas y el estado de cada nodo en cada momento. Una vez que una
tarea se asigna a un nodo no puede ser cambiada a otro a menos que
deje de estar disponible.
 Stack: en el ámbito de Docker, un stack es un conjunto de servicios que
comparten dependencias y pueden ser escalados y orquestados en
conjunto.
 Escalado: indica el número de tareas/contenedores que se especifican
para ejecutar un servicio [30]. Es un parámetro que puede ser
cambiado en cualquier momento y típicamente varía en función de las
necesidades. Hay dos tipos de escalado: el paralelo cuando todos los
contenedores de un servicio se ejecutan al mismo tiempo sin depender
los unos de los otros, y el secuencial cuando los contenedores se
ejecutan de uno en uno a medida que el anterior va acabando. El modo
por defecto es el escalado paralelo.
Existen multitud de posibilidades a la hora de escoger un gestor u
orquestador de contenedores, a continuación se analizarán las más relevantes.
- 21 -
Docker Swarm
Docker contiene un framework5 de orquestación y una plataforma de gestión,
llamado Docker Swarm [31], para la gestión de nodos que forman un clúster. Es
accesible por defecto por línea de comandos a través de CLI (Command Line
Interface) y ofrece un mecanismo para el escalado, distribución, orquestación y
monitorización de microservicios en arquitecturas multinodo de forma rápida y
sencilla haciendo uso de ficheros yaml.
Además dispone de un mecanismo que permite a los nodos descubrirse y
establecer relaciones entre sí utilizando TLS (Transport Layer Security) como capa
de transporte.
La arquitectura de Docker Swarm se muestra en la figura 19. En ella se aprecia
un clúster formado por varios nodos trabajadores y varios managers. Los usuarios
interactúan con Docker Swarm a través del CLI ofrecido por los managers.
Figura 19: arquitectura Docker Swarm
Portainer
Portainer es una solución de gestión de contenedores accesible a través de
una interfaz web que permite gestionar diferentes entornos Docker (nodos y swarm
clúster).
Entre otras cosas permite:
 Visualizar un resumen del estado general del nodo o nodos.
 Gestión de plantillas de aplicaciones: permite editar y hacer uso de
plantillas ya creadas con el fin de poder desplegar los contenedores ahí
definidos.
 Gestión de stacks: creación y modificación de conjuntos de servicios.
5 Framework: framework es un entorno de trabajo que reúne conceptos, prácticas y criterios
para enfrentarse y resolver ciertos problemas

- 22 -
 Gestión de servicios: permite configurar detalladamente los

parámetros de los servicios: networking, volúmenes, almacenamiento,
etiquetado, restricciones, variables de entorno, consulta y
modificación de tareas en ejecución, escalado de servicios, asignación
y limitación de recursos…
 Gestión de contenedores: permite visualizar, editar, asignar y
desasignar volúmenes y redes, visualización de logs, ejecución de
consola web y operaciones como arrancar, parar, pausar, reiniciar y
eliminar contenedores.
 Gestión de imágenes: permite crear, editar, subir, descargar y eliminar
imágenes de repositorios.
 Gestión de redes: creación y manipulación de redes en general.
 Gestión de volúmenes: creación y manipulación de volúmenes en
general.
 Gestion del clúster swarm: permite obtener detalles de cada uno de los
nodos: recursos disponibles, versiones y estado entre otros. Además
dispone de una opción que muestra gráficamente qué hay
ejecutándose en cada uno de los nodos.
Figura 20: interfaz Portainer
Swarmpit
Como se muestra en la figura 21, presenta una interfaz muy parecida a la de
portainer pero bastante más simple y enfocada principalmente a la gestión del
clúster. Se trata de una solución sencilla y ligera que permite una gestión básica de
Docker Engine.
- 23 -
Figura 21: interfaz Swarmpit
Docker-swarm-visualizer
Docker-swarm-visualizer proporciona simplemente una representación
gráfica en directo del clúster, incluyendo los nodos y los contenedores que está
ejecutando cada uno de ellos, sin poder realizar ningún tipo de gestión ni alteración
del entorno.
Figura 22: interfaz Docker-swarm-visualizer
- 24 -
Kubernetes
Kubernetes, también conocido como k8s, es un sistema de código abierto
multiplataforma para la automatización de despliegues, escalado y gestión de
aplicaciones contenedorizadas. Fue creado en 2014 por Google haciendo uso del
lenguaje Go y posteriormente donado a Cloud Native Computing Foundation [32].
Antes de profundizar es necesario introducir una serie de conceptos:
 Espacio de nombres, namespace en inglés es un término creado con el
fin de proporcionar aislamiento entre zonas, de forma que los
elementos y objetos que pertenezcan a un espacio de nombres son
independientes e invisibles por los demás. Es una característica que
resulta realmente útil sobre todo cuando varios proyectos o equipos
distintos se están ejecutando sobre el mismo clúster. Por defecto
existen tres espacios de nombres:
o Kube-system: espacio de nombres que almacena todos los
objetos que ha creado el sistema
o Kube-public: espacio de nombres usable por el clúster para
hacer públicos unos determinados objetos. Es configurable por
el administrador.
o Default: espacio de nombres general del clúster. Normalmente
usado para la gestión privada de objetos.
 Pod: mínima entidad que se puede desplegar en Kubernetes. Puede
estar compuesto por uno o más contenedores, aunque normalmente
se despliega un contenedor por cada pod. Los contenedores que se
ejecutan dentro de un pod comparten el contexto, parámetros de red,
espacio de nombres, volúmenes y todo el entorno de ejecución.
Los pods son entendidos como unidades temporales que pueden ser
volatilizadas en cualquier momento por el administrador o por el
clúster en sí, y no tienen que implementar mecanismos para ser
recuperados ya que de dichas tareas se encarga Kuberenetes.
 Despliegue, deployment en inglés: es la mejor forma de desplegar y
gestionar una aplicación en Kubernetes. Ofrece los mecanismos
necesarios para desplegar, actualizar y escalar por completo la
aplicación.
 Servicios: son entendidos como una capa de abstracción para el
enrutado de tráfico hacia un determinado conjunto de pods. Haciendo
uso de los servicios no es necesario encaminar el tráfico a la dirección
IP de cada pod, sino que se utilizan selectores y etiquetas que permiten
hacerlo de forma automática. Por tanto, permite el desacoplamiento y
hace posible la comunicación entre microservicios, soportando TCP y
UDP. Hay cuatro tipos de servicios:
o ClusterIP: el servicio se hace público a través de una IP interna
dentro del clúster.
o NodePort: Kubernetes asigna un puerto en cada nodo y todo el
tráfico que vaya a ese puerto será enrutado al puerto del
servicio.
- 25 -
o LoadBalancer: disponible solo cuando se usan proveedores de
cloud como AWS. Kubernetes provisiona un balanceador de
carga haciendo uso del balanceador de carga del proveedor
cloud.
o ExternalName: proporciona mecanismos basados en CNAME
para hacer accesible un servicio interno del clúster.
 Replication set y replication controller: como se ha comentado antes
el ni el pod ni el administrador han de encargarse de la gestión ni del
ciclo de vida de los pods, puesto que Kubernetes dispone de los
recursos necesarios para ello. Se trata de RS (Replication Set) y RC
(Replication Controller): unos mecanismos encargados de escalar y
replicar los componentes para cumplir con el estado definido en el
fichero de despliegue.
 Stateful sets: entendidos como controladores de pods que se encargan
de garantizar el orden y unicidad de los mismos.
 Daemon sets: garantiza que cada uno de los nodos del clúster ejecutan
una serie de pods. Por ejemplo cuando un nodo se añade al clúster ha
de ejecutar una serie de demonios6 que desempeñan funciones como
gestión de logs, gestión de almacenamiento… Dichos demonios son
eliminados cuando un nodo abandona el clúster.
 Trabajos, jobs: el flujo de trabajo en Kubernetes se gestiona en base a
trabajos. Se espera que cada contenedor realice una serie de tareas y
las acabe después de un determinado periodo de tiempo. Los jobs son
útiles si se necesita procesamiento único o por lotes en lugar de
ejecutar tareas de ejecución continua. Además existe la posibilidad de
programar y planificar esos trabajos haciendo uso del demonio cron7
convencional.
 Volúmenes: entendidos como los discos de los contenedores.
 Etiquetas: en formato de ‘clave:valor’ que permiten referenciar de
diferentes modos a los objetos.
 Nodo maestro: nodo encargado de controlar el clúster de Kubernetes
y realizar la asignación de tareas a los nodos trabajadores.
 Nodo trabajador o esclavo: máquina encargada de realizar las tareas
requeridas y asignadas por el nodo maestro.
 Kubelet: es el principal punto de contacto entre los nodos y el clúster.
Se trata de un servicio que se ejecuta en los nodos y se encarga de leer
los manifiestos del contenedor, garantizando que los contenedores
definidos se encuentren listos y ejecutándose.
 Kubectl: herramienta de configuración CLI de Kubernetes.
 Kubeadm: es un complemento para el aprovisionamiento de clúster de
forma segura y extensible.
6 Demonio: programa que se ejecuta en segundo plano y carece de interfaces e interacción

con el usuario.
7 Cron es un administrador de procesos en segundo plano que permite la planificación y
ejecución de tareas de forma periódica y puntual.

- 26 -
 Kube-proxy: proxy que se ejecuta en cada uno de los nodos del clúster
con el fin de gestionar el direccionamiento y hacer accesibles los
servicios a los demás componentes. No se trata de un simple
reencaminador de tráfico, sino que también desempeña funciones
como balanceador de carga y pequeñas nociones de alta
disponibilidad.
 Kube-scheduler: planificador. Es un componente que reside en el nodo
maestro y se encarga de asignar un nodo en el que ejecutar los pods
recientemente creados.
 Etcd: es un proveedor de almacenamiento persistente, muy ligero
desarrollado por CoreOS que proporciona el almacenamiento seguro
de todos los datos del clúster en cualquier instante de tiempo.
 Servidor API: proporciona una interfaz interna y externa de
Kubernetes haciendo uso de JSON (JavaScript Object Notation) sobre
HTTP/HTTPS a través de servicios REST (Representational State
Transfer). Es un componente primordial para el establecimiento de
comunicación y además es el único que establece comunicación
directa con etcd. Véase el ejemplo de la figura 23:
Figura 23: ejemplo API Kubernetes
Gran parte de los componentes y aspectos recientemente introducidos se ven

representados en la figura 24. Como se puede observar, existen diferentes flujos de
comunicación, los más importantes son:
 API server de nodo master  Kubelet: comunicación entre nodos para
la gestión del estado del clúster y ejecución de contenedores.
Fundamental para el despliegue y gestión de contenedores.
 API server  scheduler: comunicación del núcleo del clúster con el
planificador de despliegue y ejecución de contenedores. Fundamental
para la asignación de nodos a los despliegues.
 API server  etcd: comunicación directa del núcleo del clúster con el
proveedor de almacenamiento del mismo. Garantiza la consistencia y
coherencia de los datos almacenados.
- 27 -
Figura 24: arquitectura Kubernetes
Sin embargo, a la hora de crear un clúster con Kubernetes es necesario hacer

uso de algunos componentes más como por ejemplo los pod de red. Los pod de red
son un complemento que debe ser desplegado antes que cualquier aplicación y que
permite la comunicación entre los diferentes pods. Como se muestra en la tabla 2,
existen una serie de alternativas entre las que elegir en función de las necesidades y
del entorno de ejecución.
Tabla 2: pods de red
Nombre Principales características

Calico Requisitos:
 arquitectura amd64
 2 CPU
 2 GB RAM
 10 GB espacio en disco
 RHEL 7.x+, CentOS 7.x+, Ubuntu 16.04+, Debian 8.x+
Canal Requisitos:
 RHEL 7.x+, CentOS 7.x+, Ubuntu 16.04+, Debian 8.x+,
CoreOS Container Linux Stable
Flannel Funciona en las siguientes arquitecturas *:
 amd64
 arm
 arm64
 ppc64le
Romana Requisitos:
Weave Net Funciona en las siguientes arquitecturas *:
 amd64
 arm
 arm64
 ppc64le
- 28 -
*NOTA: como se muestra en la tabla Flannel y Weave Net pueden funcionar en

diversas arquitecturas. El modelo arquitectónico del clúster se define en un fichero
manifest8 en el momento de creación de los pod de red, por defecto se activa para la
arquitectura amd64 y puede ser cambiado por otro modificando y reaplicando el
fichero. Nótese que el fichero define la arquitectura de todo el clúster, por lo que
aunque soporta varias arquitecturas no funciona cuando en un clúster hay nodos de
varias. Sin embargo, como se muestra en el anexo D en el apartado de clúster
multiarquitectura, existen formas de hacer algunos cambios en clúster para
solucionar esta peculiaridad.
Adicionalmente existe otro servicio para resolución de nombres que se
despliega en forma de pod. Se llama kube-dns y para su funcionamiento requiere de
la instalación de algún pod de red de los mostrados en la tabla 2.
En los últimos tiempos, Kubernetes se ha convertido, con diferencia, en el
orquestador de contenedores más usado del mercado, debido principalmente a que
aporta muchas más ventajas que otras soluciones en el mercado.
Según [33], Kubernetes es, con diferencia, el orquestador de contenedores Docker
más usado en los últimos tiempos. Véase la figura 25 en la que se compara el interés
de Kubernetes, Docker Compose9 y Docker Swarm en el último año.
Figura 25: interés por orquestadores
El modelo arquitectónico de Kubernetes, está basado en la arquitectura

maestro-esclavo, que define un procedimiento para transferir datos entre dos tipos
de elementos, los maestros, que pueden obtener el uso del medio de comunicación,
iniciar los ciclos y gestionar la temporización, y los esclavos, que realizan
únicamente las transferencias de acuerdo con los ciclos generados por los maestros.
Sus principales características son:
 Escalabilidad: presenta un alto grado de escalabilidad que se traduce
en una gran capacidad de reacción y adaptación ante el crecimiento y
decrecimiento del uso de las aplicaciones.
8Se entiende por manifest un fichero que se usa para definir datos relativos a la aplicación y
en concreto a los pods de red.
9 Docker Compose es un complemento para la definición de aplicaciones multi contenedor
con Docker.
- 29 -
 Descubrimiento de servicios: no se necesitan mecanismos externos
para descubrir nuevos servicios puesto que Kubernetes asigna las
direcciones IP a los contenedores y un nombre DNS único para ellos.
 Balanceo de carga: distribuye el flujo de trabajo y/o de información
entre una serie de dispositivos con el fin de incrementar la capacidad
y disponibilidad de las aplicaciones.
 Auto reparación: si un contenedor falla o se elimina, Kubernetes tiene
capacidad de reemplazarlo automáticamente.
 Despliegues y cambios de versiones automáticos: existe la posibilidad
de actualizar y revertir la versión de los contenedores de forma
automática, progresiva y acorde al estado de la aplicación en cada
momento.
 Planificación: capacidad de decidir y asignar qué contenedores han de
ejecutarse en cada nodo de acuerdo a los recursos requeridos y otro
tipo de restricciones añadidas.
 Gestión de información sensible: dispone de un mecanismo de
almacenamiento de información privilegiada –típicamente
contraseñas, claves ssh…– que se gestionan de forma independiente a
los contenedores.
 Orquestación del almacenamiento: es capaz de gestionar distintos
tipos de almacenamiento para sus contenedores. Entre ellos destacan
algunos proveedores de nube pública como GCP (Google Cloud
Computing) y AWS y otros sistemas de almacenamiento en red como
NFS (Network File System), GlusterFS, Ceph, Cinder o Flocker.
 Ejecución de trabajos por lotes: a parte de los servicios, permite
gestionar cargas de trabajo por lotes reemplazando los contenedores
que fallen.
 Versatilidad: se trata de una plataforma muy versátil que abarca un
amplio abanico de posibilidades ya que puede ser desplegado:
o en máquinas físicas sobre distintos sistemas operativos como
Fedora, CentOS, Ubuntu…
o on-premise 10 con máquinas virtuales haciendo uso de
tecnologías como Vagrant, CloudStack, Vmware, OpenStack,
Fedora…
o en entornos cloud y plataformas PaaS como Google Container
Engine, Openshift, Azure y Deis, entre otras.
 Cuenta con el apoyo de grandes empresas como Amazon, Amadeus,
Huawei, Ebay o Philips entre otras.
A continuación en la figura 26 se muestra una captura de la interfaz gráfica
de Kubernetes:
10 En el ámbito del software se entiende que las aplicaciones on-premise son aquellas que
residen en las infraestructuras del usuario.

- 30 -
Figura 26: interfaz gráfica Kubernetes
2.3. NFV
2.3.1. Introducción
Típicamente, las redes de telecomunicaciones están compuestas de una
inmensa cantidad de dispositivos diferentes diseñados cada uno de ellos para
cumplir con una determinada función. Normalmente para lanzar un nuevo servicio
de red es necesaria la incorporación de otro dispositivo hardware en la
infraestructura, conllevando una serie de inconvenientes como: el coste del
dispositivo y su instalación, la vida útil –relativamente corta– de los equipos
hardware de hoy en día, inversión en infraestructuras, procesos de integración
complejos… Todas estas restricciones han llevado a cambiar el sistema de red
tradicional por un sistema de virtualización de funciones de red (NFV).
Las tecnologías NFV hacen uso de la virtualización: una técnica que permite
la creación de recursos hardware y software ficticios. Esta técnica que fue
introducida en allá por los años 60 por IBM [34] permite gestionar de forma muy
escalable y granular los recursos hardware de una máquina, permitiendo así un gran
aumento en el rendimiento de los servidores ya que antes sólo se utilizaba entre el 5
y el 15% de los mismos.
El concepto de NFV surgió cuando las empresas proveedoras de servicios de
telecomunicación se unieron con el objetivo de acelerar el proceso de despliegue de
servicios de red, aumentar su alcance y disminuir sus costes formando el ETSI11, una
11 ETSI, sitio web: http://www.etsi.org/

- 31 -
organización sin ánimo de lucro dedicada a la creación de estándares de
telecomunicaciones que cuenta con más de 800 miembros en todo el mundo.
La virtualización de las funciones de red (NFV) [35] es un enfoque de red en
evolución basado en la sustitución de dispositivos hardware tradicionales como
servidores DNS, DHCP (Dynamic Host Configuration Protocol), balanceador de
carga, firewall, aplicaciones NAT (Network Address Translation)… por dispositivos
de red basados en software que se ejecutan en máquinas y entornos virtuales de red.
2.3.2. Características
Beneficios de NFV:
 Permite la abstracción del hardware en el que se ejecutan las
funciones.
 Pueden ser desplegadas a través de contenedores, con todas las
ventajas que ello conlleva.
 Ofrece elasticidad, escalabilidad y automatización.
 Reduce los tiempos de despliegue y de instalación de funciones de red.
 Reduce notablemente los costes en equipamiento y en despliegue de
funciones de red.
 Menos consumo de energía en la red, al poder aprovechar un
dispositivo hardware para desplegar varias funciones de red distintas.
 Actualizaciones de red mucho más rápidas y sencillas.
La estandarización de NFV es liderada por ETSI, principalmente por ETSI
ISG NFV (ETSI Industry Specification Group NFV), grupo al que pertenecen más de
150 compañías internacionales de telecomunicación. Aunque ETSI es una
organización para el desarrollo de estándares, su objetivo principal se centra en
alcanzar el consenso de la industria en los aspectos técnicos y de negocio, acordando
métodos comunes para alcanzar los objetivos definidos.
ETSI está compuesta principalmente de cuatro grupos de trabajo que se
centran en diferentes áreas de NFV, son: la encargada de la parte de infraestructura,
la encargada de la fiabilidad y disponibilidad, la encargada de arquitectura y
software y la encargada de la parte de gestión y orquestación.
Debido al alcance y enfoque de este proyecto, los esfuerzos han sido centrados
en estudiar la última, MANO (Management and Orchestration), que se define en a
la especificación “ETSI GS NFV-MAN 001 V1.1.1 (2014-12)” [36].
MANO provee las funciones y complementos necesarios para gestionar y
administrar el ciclo de vida completo de las VNF (Virtual Network Function) y la
orquestación de la infraestructura y las redes de comunicación.
De acuerdo a la norma referenciada, como se muestra en la figura 27 [37], los
componentes principales de MANO son:
 NFVI (Network Function Virtualisation Infraestructure): abarca todos
los componentes software y hardware que proveen los recursos sobre
los que se despliegan las VNFs.
- 32 -
 NFVO (NFV Orchestrator): desempeña dos funciones principales. Por

un lado se encarga de la orquestación de recursos NFVI a través de
distintos VIMs, y por otro se encarga de la gestión del ciclo de vida de
los servicios de red (NS).
 VNFM (VNF Manager): es el responsable de la gestión del ciclo de vida
de las instancias VNF. Cada una de las instancias VNF tiene asociada
un VNFM que lo administra.
 VIM (Virtualised Infrastructure Manager): responsable de controlar y
gestionar los recursos de computación y de red de NFVI.
 Catálogo de servicios de red (NS catalogue): representa un repositorio
de servicios de red
 Catálogo de funciones virtuales de red (VNF catalogue): representa un
repositorio de todos los paquetes VNF.
 Repositorio de instancias NFV: representa un repositorio que
almacena instancias de VNF y de NS.
 Repositorio NFVI: almacena información sobre la disponibilidad de
los recursos NFVI.
 EM (Element management): es el responsable de gestionar la
funcionalidad de una VNF.
 OSS (Operations Support System) y BSS (Business Support System):
se encargan de proveer gestión y orquestación a los sistemas,
pudiendo proveer también la comunicación externa.
Figura 27: esquema ETSI NFV MANO
Es muy común desplegar microservicios en contenedores Docker, estudiados

en el capítulo 2.2.3, a los que en ocasiones se les añade una capa de abstracción para
- 33 -
cumplir con una determinada normativa. Por ejemplo, existen ciertas alternativas
que permiten desplegar VNF cumpliendo con la especificación de ETSI NFV MANO
como OpenBaton que será analizada a continuación.
Por otro lado, existen otras alternativas, como TOSCA (Topology and
Orchestration Specification for Cloud Applications) [38] un estándar que define un
modelo de datos gestionado por el grupo industrial OASIS12 que puede ser utilizado
para orquestar servicios NFV en la nube. Funciona haciendo uso de una serie de
modelos de datos y plantillas y es perfectamente compatible con soluciones que
cumplan con ETSI MANO.
2.3.3. Soluciones
A continuación se recogen una serie de soluciones e implementaciones de la
norma que permiten el despliegue de NFV.
OpenBaton
OpenBaton es una plataforma de código abierto que proporciona una
implementación completa de la especificación ETSI NFV MANO [39]. Surgió tras
una serie de procesos de diseño que tenían como objetivo la creación de un
framework personalizable capaz de orquestar servicios de red a través de
infraestructuras NFV, véase figura 28.
Figura 28: contexto OpenBaton
Es capaz de integrarse con VNFMs existentes a tavés de un modelo sencillo

de plug and play que publica APIs REST y AMQP (Advanced Message Queuing
Protocol) y diferentes SDK (Sofware Development Kit) en diferentes lenguajes de
programación como Java, Python y Go que permiten la comunicación y
sincronización entre ellos.
Soporta diversas alternativas VIM, basadas en mecanismos RPC que le
permiten controlar VNFs instaladas sobre entornos OpenStack, Docker, y Amazon.
Como se observa en la figura 29, la arquitectura de OpenBaton está basada
en la de NFV MANO, de ahí que tengan los componentes principales en común
(NFVO, VNFM, VIM, NFVI y OSS).
12 OASIS, sitio web: https://www.oasis-open.org

- 34 -
Figura 29: arquitectura OpenBaton
A parte de los componentes que tiene en común con la especificación NFV

MANO, OpenBaton presenta otros componentes, entre los que destacan:
 RabbitMQ: un componente de mensajería ligera que proporciona un
mecanismo de comunicación para la comunicación entre el OSS y el
NFVO con el VIM.
 En cuanto a gestores VNF existen varias alternativas:
o VNFM Genérico: es una implementación de la especificación
ETSI MANO y actúa como intermediario, haciendo uso del
mecanismo RabbitMQ, entre el orquestador NFV y las VNF.
Figura 30: VNFM genérico
o Juju VNFM, una versión de prueba que permite a OpenBaton

interactuar con Juju13 como VNFM.
o Docker VNFM que junto con Docker Vim Driver permiten a
OpenBaton desplegar contenedores sobre la infraestructura
Docker.
o Existe la posibilidad de crear un VNFM propio e integrarlo con
OpenBaton.
13 Juju es una complemento de codigo abierto para el modelado de aplicaciones y servicios
que facilita el desarrollo, despliegue y escalado de aplicaciones en entornos cloud.

- 35 -
 Interfaz de gestión web: dispone de una interfaz amigable para la
gestión del entorno al completo.
Figura 31: interfaz OpenBaton
Onap
Onap es una plataforma para la orquestación y automatización de funciones
de red físicas y virtuales que permite a los proveedores de redes, cloud y software
desplegar y automatizar nuevos servicios en tiempo real haciendo uso de
infraestructuras como EC2 (Elastic Compute Cloud) y OpenStack [40].
Cloudify
Cloudify es una plataforma de código abierto para la orquestación de
aplicaciones y servicios de red en plataformas cloud. Está pensado para automatizar
el despliegue y configuración de aplicaciones en entornos de cloud [41].
Utiliza un enfoque declarativo centrado en la especificación TOSCA en el que
los usuarios definen el estado deseado de la aplicación a través de variables y
plantillas sencillas escritas en yaml y Cloudify se encarga de alcanzar y mantener
dicho estado, al mismo tiempo que lleva a cabo tareas de monitorización con el fin
de asegurar que la aplicación funciona correctamente y cumple con los SLA (Service
Level Agreement) deseados.
Presenta múltiples modos de instalación entre los que destacan: a través de
ficheros RPM (Red Hat Package Manager), imágenes Docker, AWS y OpenStack y a
través de comandos.
Como se ha mencionado antes, Cloudify no es un mero orquestador de
servicios en la web, sino que se trata de un orquestador completo de aplicaciones y
servicios cloud. Por tanto, como se observa en la figura 32, Cloudify presenta un gran
alcance englobando la aplicación al completo: infraestructura, middleware, código
de la aplicación, contenedores, componentes de red, bases de datos y alarmas.
- 36 -
Figura 32: enfoque Cloudify
Uno de los casos de uso más comunes de Cloudify, relacionado con el ámbito
y las tecnologías de este proyecto, pasa por la gestión completa de un clúster de
Kubernetes que reside en un entorno de cloud -en concreto haciendo uso de alguno
de los proveedores de IaaS como Openstack, Azure o AWS-. Véase figura 33.
Figura 33: caso de uso Cloudify
2.3.4. Relación NFV-SDN

SDN (Software Defined Networking) es una arquitectura emergente que
supone el desacoplamiento del plano de control (inteligencia) y de datos
(conmutación) de las redes [42] .
Dicho desacoplamiento, como se muestra en la figura 34 [43], permite la
separación completa de la funcionalidad de la red diferenciándose principalmente
dos roles:
 Nodos de red: tradicionalmente conocidos como routers que se
encargan de la gestión de los datos
 Controlador o cerebro de red: entendido como el punto en el que
reside la inteligencia y funcionalidad de la misma. El controlador
puede gestionar y administrar un conjunto de nodos de forma global,
de forma que los cambios en la topología o los nodos de la red no
tengan que ser transmitidos a todos los nodos, sino que únicamente
han de ser transmitidos al controlador.
- 37 -
Figura 34: red tradicional VS SDN
En la figura 35 [44], se muestra el modelo arquitectónico de SDN. La

separación de componentes de que ofrece dicho nivel arquitectónico ofrece un nivel
de programación muy alto, automatización y control de la red que se traduce en
flexibilidad, escalabilidad y adaptación a cambios. Además, favorece la
virtualización de la red de modo que hace que SDN y NFV sean dos tecnologías de
computación en la nube totalmente complementarias.
Cabe mencionar que aunque SDN y NFV son tecnologías que están en cierto
modo relacionadas, no existe dependencia estricta entre ambas y pueden
desplegarse de forma independiente y complementaria.
Figura 35: arquitectura SDN
Como se muestra en la figura 35, la comunicación entre la capa de

infraestructura y la de control en las redes definidas por software se lleva a cabo a
través de OpenFlow [45]. OpenFlow es un protocolo de comunicación de capa dos
(capa de enlace) que proporciona acceso al plano de datos de un switch o de un
router a través de la red, es decir, es el protocolo que permite que los componentes
del plano de datos puedan ser gestionados y manipulados por los controladores de
red.
- 38 -
2.4. OPENSTACK
2.4.1. Introducción
OpenStack es una plataforma de código abierto que utiliza una serie de
recursos informáticos para construir y gestionar nubes públicas y privadas.
Se trata de un gran proyecto respaldado por más de 82 000 miembros y más
de 200 empresas del sector repartidas por 187 países alrededor del mundo. Es
administrado por OpenStack Foundation 14 , organización sin ánimo de lucro
encargada de gestionar el desarrollo y la comunidad que giran en torno al proyecto.
OpenStack está pensado para proporcionar una infraestructura como servicio
(IaaS), es decir, ofrece a los usuarios la capacidad de gestionar el hardware por
completo. Si bien es cierto que existen algunos complementos –como magnum–
que permiten la distribución de contenedores a través de OpenStack.
Su comportamiento es ideal en aquellos entornos que requieren de alta
escalabilidad, dinámicos y cambiantes.
Aunque el alcance de OpenStack es tan grande que podría abarcar el proyecto
al completo, a continuación se proporcionan una serie de detalles en lo que a
arquitectura y funcionalidad se refiere que pretenden servir de base para entender
qué papel juega en el despliegue de microservicios y VNF.
2.4.2. Componentes
La versión general de OpenStack ofrece una infraestructura como servicio a
través de una amplia gama de servicios independientes. Cada uno de esos servicios
ofrece una API que lo hace accesible y facilita su integración con el resto.
Como mínimo necesitaremos los siguientes servicios para hacer un
despliegue básico:
 Keystone: servicio de identidad, encargado de autenticar y autorizar
los servicios de OpenStack entre sí.
 Glance: servicio de imágenes. Se encarga de obtener y almacenar las
imágenes de disco de las máquinas virtuales.
 Nova: servicio de computación. Ofrece una forma de aprovisionar
instancias de computación, también conocidas como servidores
virtuales. Soporta crear máquinas virtuales, hacer uso de servidores
físicos…
 Neutron: servicio de networking. Ofrece provisionamiento de red en
los entornos virtuales basado en SDN. Algunas funciones disponibles
son DNS, DHCP, grupos de seguridad y balanceamiento de carga
entre otros.
Otros servicios de OpenStack son [46]:
 Aodh: servicio de alarmas.
 Barbican: gestión de claves.
14 OpenStack, sitio web: https://www.openstack.org/foundation/

- 39 -
 Ceilometer: servicio de monitorización que controla el entorno con el
fin de obtener informes de uso del mismo, estadísticas…
 Cinder: servicio de almacenamiento de bloques. Se encarga de proveer
almacenamiento persistente a las máquinas virtuales alojadas en la
nube.
 Cloudkitty: servicio de facturación y lógica de negocio.
 Designate: servicio DNS.
 Freezer: servicios de copias de seguridad y recuperación de desastres.
 Heat: servicio de orquestación.
 Horizon: ofrece una interfaz web de administración al usuario.
 Ironic: servicio de provisionamiento de hardware. Utilizado para
gestionar nodos físicos que se añaden a la nube.
 Karbor: protección de los datos de aplicaciones como servicio.
 Kolla: servicio de despliegue de contenedores.
 Kuryr: plugin para gestión de contenedores.
 Magnum: servicio de orquestación de contenedores.
 Manila: servicio de compartición del sistema de ficheros
 Mistral: servicio de flujo de trabajo.
 Monasca: servicio de monitorización.
 Murano: catálogo de aplicaciones.
 Octavia: balanceamiento de carga.
 OpenStack-Ansible: servicio de despliegue con Ansible15.
 Panko: gestión de eventos e indexado de metadatos.
 Rally: servicio de benchmark16.
 Sahara: servicio de procesamiento big data.
 Searchlight: servicio de indexado y búsqueda.
 Senlin: servicio de gestión de clúster.
 Solum: despliegue de software para automatización del ciclo de vida.
 Swift: servicio de almacenamiento de objetos. Permite almacenar
grandes cantidades de datos a través de un API sencillo. Es ideal para
almacenar datos sin estructurar que pueden crecer irregularmente.
 Tacker: orquestador NFV.
 Tricircle: servicio de automatización de networking para despliegues
multizona.
 Tripleo: servicio que ofrece un instalador para despliegues.
 Trove: ofrece bases de datos como servicio.
 Watcher: servicio de optimización.
 Zaqar: servicio de mensajería.
 Zun: servicio de gestión de contenedores.
15 Ansible: plataforma de software libre para la configuración y administración de

computadoras.
16 Benchmark: en informática se refiere a una prueba utilizada para medir el rendimiento de
un sistema o de sus componentes.

- 40 -
A continuación, en la figura 36 se muestra un esquema sencillo de los

componentes básicos de OpenStack.
Figura 36: servicios principales de OpenStack
OpenStack compute (conocido como nova) necesita al menos un hipervisor17

para poder funcionar. Tradicionalmente la elección del hipervisor a utilizar en
OpenStack suele ser una decisión difícil ya que las versiones actuales soportan varios
hipervisores, y cada uno de ellos presenta una serie de peculiaridades y
características que deben ser tenidas en cuenta en las decisiones de diseño del
proyecto. Por este motivo, hoy en día es posible planificar el uso de distintos
hipervisores sobre la misma instalación de OpenStack haciendo uso de unos
componentes llamados ComputeFilter e ImagePropertiesFilter. En caso de
necesitarlo, esta información puede ser ampliada en [47].
2.4.3. Arquitectura
OpenStack puede ser instalado en distintos sistemas operativos, entre los que
destacan Red Hat, Ubuntu, CentOS y SUSE. Aunque en función de su versión y el
tipo de entorno que se desee montar su arquitectura variará, pues puede ser
instalado en un solo nodo o en varios.
La instalación más sencilla y rápida es DevStack, una versión pensada para
desarrolladores que se instala a través de un conjunto de scripts en uno o varios
nodos, indicando simplemente una serie de parámetros de configuración. La
interfaz de DevStack se muestra en la figura 37.
17 Hipervisor: aplicación que separa el sistema operativo de una computadora y las
aplicaciones del hardware físico subyacente. Se trata de un concepto clave en la virtualización que
permite maximizar el uso de recursos como memoria y disco.
- 41 -
Figura 37: interfaz gráfica Devstack
Por otro lado, en entornos notablemente grandes y profesionales se suele instalar la

versión completa de OpenStack distribuida en nodos. Las tareas que cada uno de los
nodos ejecutará vienen determinadas por una serie de roles modificables, que
normalmente son:
 Controller node: encargado de proveer administración, networking y
alta disponibilidad. Además se encarga de ejecutar las funciones de
identidad, gestión de imágenes, gestión de las redes, gestión de
computación y bases de datos entre otras. En él también se pueden
concentrar funciones de telemetría, monitorización, almacenamiento
e interfaz de gestión web.
 Compute node: nodo sobre el que se lanzan las máquinas virtuales una
vez que son creadas. Debe soportar virtualización, normalmente
utiliza los siguientes hipervisores:
o KVM(Kernel-based Virtual Machine)
o LXC haciendo uso del complemento de virtualización libvirt18
o QEMU (Quick EMUlator)
o UML (User Mode Linux)
o VMware vSphere
o Xen
o XenServer
o Hyper-V
o Virtuozzo.
 Storage nodes: nodos de almacenamiento de bloques, objetos y ceph.
 Director: nodo encargado de preparar el entorno y de instalar los
demás nodos del sistema.
18 Libvirt, sitio web: https://libvirt.org/

- 42 -
La versión más básica multi nodo de OpenStack se compone de dos nodos,

un controlador y uno de computación. En la figura 38 se representa de forma gráfica
el reparto de los servicios en función del rol que desempeña cada nodo.
Figura 38: servicios OpenStack multinodo
Por otro lado, la versión Red Hat Enterprise Linux OpenStack Platform
presenta una arquitectura más compleja y recomendada para entornos en
producción en la que se recomienda disponer de 10 nodos, repartidos: 3 x controller,
3 x compute, 3 x storage y 1 x director.
De acuerdo a los componentes listados en el apartado anterior, la
arquitectura de OpenStack puede ser más o menos compleja. En la figura 77 del
anexo F, se encuentra representada la arquitectura lógica de una de las versiones
más básicas y reducidas de OpenStack. En ella se muestran los servicios principales,
introducidos anteriormente, y la comunicación entre ambos.
- 43 -
- 44 -
CONSIDERACIONES DE DISEÑO
3. CONSIDERACIONES DE DISEÑO
3.1. ESPECIFICACIONES Y RESTRICCIONES DE DISEÑO
A continuación se listan una serie de especificaciones y restricciones de
diseño que han condicionado el desarrollo del proyecto:
1. Con el fin de disponer un entorno lo más semejante a la realidad
posible, se ha decidido realizar el análisis y diseño en un conjunto de
nodos distintos en el que todos o parte de ellos se encuentren
físicamente separados.
2. Normalmente cuando se trata de desplegar aplicaciones y funciones
de red, se dispone de un conjunto de recursos hardware muy
diferentes entre sí que pueden disponer de pocos recursos hardware.
Considerando las características de los nodos, el alcance del proyecto
engloba diferentes situaciones posibles, de modo que se han analizado
y considerado escenarios con las siguientes peculiaridades que le
proporcionan una dificultad añadida. Son:
 Diversidad de arquitecturas entre nodos
 Despliegue y extensión del trabajo a ordenadores de placa
reducida, como Raspberry Pi.
3. Las VNF y los microservicios desplegados han de garantizar el
cumplimiento de los principios filosóficos de las tecnologías, es decir:
agilidad, aislamiento, ligereza, escalabilidad…
3.2. DECISIONES DE DISEÑO
Como se ha mencionado anteriormente, existen tecnologías como Cloudify
que están pensadas para la orquestación de aplicaciones y servicios de red en
plataformas cloud. Para su uso requieren de un entorno cloud que típicamente se
consigue haciendo uso de infraestructuras creadas con OpenStack o que son
proporcionadas a través de proveedores como Azure o Amazon Web Services. Por
tanto, un entorno para el despliegue y orquestación de microservicios y funciones
de red podría estar compuesto por Cloudify y OpenStack.
Los principios filosóficos de los microservicios están muy relacionados con la
ligereza, y agilidad de los servicios y de los entornos. Esto unido con el deseo de
hacer válido este trabajo en entornos considerablemente ligeros y reducidos ha
hecho que tecnologías que requieren de ciertas cantidades de recursos como
OpenStack y Cloudify hayan quedado apartadas de las implementaciones
principales. En concreto, en OpenStack se pueden desplegar microservicios, y
durante el desarrollo de este proyecto se ha hecho, la peculiaridad es que por las
características del producto, el entorno sobre el que se instala OpenStack no puede
ser precisamente ligero, y una de las decisiones de diseño tomadas ha sido: la
valoración de otras tecnologías que permitan el despliegue de microservicios y
funciones de red en entornos reducidos.
Las tecnologías con las que se ha decidido trabajar han sido: Docker,
Kubernetes y OpenBaton principalmente. Sin embargo, si se dispone del hardware
necesario, queda pendiente para el futuro del estudio, análisis y despliegue de
- 45 -
microservicios y funciones de red haciendo uso de tecnologías como OpenStack y
Cloudify.
- 46 -
IMPLEMENTACIÓN Y RESULTADOS
4. IMPLEMENTACIÓN Y RESULTADOS
4.1. Introducción al entorno
La prueba de concepto se ha basado en el despliegue de microservicios en la
red a través de contenedores valorando y estudiando todas las tecnologías tratadas
en el segundo capítulo.
Atendiendo a las características, requisitos y funcionalidad se han definido
principalmente tres escenarios diferentes que se analizan en el siguiente orden:
1. Despliegue de microservicios mediante contenedores en un clúster
Docker formado por un conjunto de nodos monoarquitectura.
Docker formado por un conjunto de nodos multiarquitectura.
Kubernetes formado por un conjunto de nodos monoarquitectura.
En cada uno de los escenarios se han realizado una serie de despliegues y
pruebas de rendimiento que permiten evaluar y estudiar cada tecnología en función
de varios factores y condicionantes de despliegue.
Además, de forma adicional y con el fin de desplegar una función de red real
y aplicable a las redes de hoy en día se ha creado y desplegado un firewall en un
contenedor según se recoge en el anexo E.
El primer escenario está formado por un conjunto de nodos agrupados en un
clúster monoarquitectura que son gestionados y orquestados con Docker Swarm. El
clúster está formado por los nodos que se muestran en la tabla 3:
Tabla 3: nodos primer escenario
Nodo SO Arq. IP Tipo Rol

GREDOS Ubuntu 16.04.4 LTS x86_64 138.100.49.16 Físico Master
Xenial
Leon Debian GNU/Linux x86_64 138.100.49.17 Físico Worker
9.4 (stretch)
ubuntu001 Ubuntu 16.04.4 LTS x86_64 138.100.49.51 Virtual Worker
Xenial
Xenial
Xenial
El segundo escenario está constituido por los mismos nodos que el primero
con la salvedad de que se ha añadido una Raspberry Pi 3, con arquitectura arm, con
el objetivo de probar la funcionalidad multiarquitectura de las tecnologías. Sus datos
se recogen en la tabla 4.
- 47 -
Tabla 4: nodos segundo escenario
Nodo SO Arq. IP Tipo Rol

GREDOS Ubuntu 16.04.4 x86_64 138.100.49.16 Físico Master
LTS Xenial
Leon Debian x86_64 138.100.49.17 Físico Worker
GNU/Linux 9.4
(stretch)
raspberrypi01 Raspbian armv7l 138.100.49.24 Físico Worker
GNU/Linux 9.4
(stretch)
ubuntu001 Ubuntu 16.04.4 x86_64 138.100.49.51 Virtual Worker
LTS Xenial
LTS Xenial
LTS Xenial
En el tercer escenario se dispone del mismo conjunto de nodos que en el

primero, la diferencia es que esta vez se agrupan formando un clúster orquestado y
gestionado a través de la plataforma Kubernetes. A día de hoy existen una serie de
limitaciones, detalladas más adelante, que impiden la existencia de un entorno
multiarquitectura haciendo uso de estos componentes, así que los nodos disponibles
en este escenario son los que corren bajo la arquitectura x86-64. Véase tabla 3.
4.2. Análisis detallado
A continuación se analizarán con detalle las medidas y pruebas realizadas en
los diferentes entornos. Este capítulo se complementa con los anexos, de forma que
se recomendará la lectura de los mismos a medida que se avance con el proceso.
4.2.1. Escenario 1. Docker Swarm monoarquitectura.
Partiendo de los nodos recogidos en la tabla 3 se ha construido el primer
escenario.
En el anexo B se recogen todos los pasos necesarios para la construcción de
un clúster haciendo uso de Docker, desde la instalación de la tecnología, hasta la
construcción del clúster, pasando por una serie de apartados que recogen los
conceptos básicos de manejo de la plataforma.
En este primer escenario se dispone de un conjunto de nodos agrupados en
forma de clúster que son accesibles y gestionables desde dentro de la red y desde
internet. Por simplicidad en el dibujo, los repositorios se han considerado
completamente externos a la red. El mapa de red del escenario se muestra en la
figura 39.
- 48 -
Figura 39: mapa de red del escenario I
Para la prueba de concepto se han desplegado tres servicios, con diferentes

números de réplicas con el objetivo de comprobar el funcionamiento y de realizar
una serie de medidas sobre la plataforma. La primera imagen en desplegar ha sido
un servidor web básico, llamado httpd que tiene un tamaño de 178MB.
En la figura 40 se representan los tiempos de despliegue del contenedor httpd
(de 178MB) frente al número de réplicas desplegadas. Se aprecia claramente una
relación lineal entre el número de réplicas y el tiempo de despliegue, de forma que
cuantas más réplicas o contenedores de una imagen se creen, más tiempo llevará
hacerlo. Nótese que dicha recta lineal presenta un coeficiente de correlación, R 2,
bastante cercano a la unidad, lo que indica que la recta puede representar con cierta
calidad los datos estudiados y la relación entre ambas variables.
Despliegue httpd escenario I

12
Tiempo despliegue (s)
10
6
y = 0,067x + 3,0389
4 R² = 0,9794
0
0 20 40 60 80 100 120
Número de réplicas
Tiempo neto Tendencia lineal
Figura 40: despliegue httpd escenario I
- 49 -
Analizando las medidas de tiempo y de rendimiento obtenidas tras los
despliegues, se concluye el número de réplicas de una imagen es inversamente
proporcional al tiempo que cuesta desplegar cada una de las réplicas; de modo que
cuantas más réplicas de una imagen se lancen, menos tiempo por réplica costará
hacerlo. Dicha relación está definida por una función exponencial decreciente que a
medida que aumenta el número de réplicas, eje de abscisas en nuestro caso, se
aproxima más a cero. Estos datos se muestran en la figura 41:
Tiempo/réplica httpd escenario I

4
3,5
Tiempo/réplica (s)
3
2,5
y = 2,6435e-0,225x
2 R² = 0,949
1,5
1
0,5
0
1 2 3 4 5 6 7 8 9 10 15 20 50 100
Tiempo/réplica Tendencia exponencial
Figura 41: tiempo de despliegue por réplica httpd escenario I
Las mismas conclusiones son obtenidas para el resto de imágenes. Sin

embargo, existen más factores que influyen a la hora de desplegar un microservicio,
como por ejemplo el tamaño y la funcionalidad del mismo y los recursos hardware
de los nodos.
A continuación en la figura 42 se muestra una comparativa entre los tiempos
de despliegue de tres imágenes distintas: httpd de 178 MB, mongo de 368MB y
wordpress de 408MB. En ella se puede deducir que, para este escenario, existe una
relación directamente proporcional entre el tiempo de despliegue de una imagen y
el tamaño de la misma.
- 50 -
Tiempos de despliegue escenario I

12
Tiempo de despliegue (s)

10
0
1 2 3 4 5 6 7 8 9 10 15 20 50 100
httpd 178 MB mongo 368 MB wordpress 408 MB
Figura 42: tiempos de despliegue escenario I
4.2.2. Escenario 2. Docker Swarm multiarquitectura.

El segundo escenario se construye a partir de los nodos representados en la
tabla 4.
Al igual que para el primer escenario, se recomienda la lectura del anexo B en
el que se recogen todos los pasos necesarios para el manejo y construcción de un
clúster haciendo uso de Docker.
En el segundo escenario, se dispone de un conjunto de nodos
multiarquitectura agrupados en forma de clúster que al igual que en el primer
escenario, son accesibles y gestionables desde dentro de la red y desde internet. Por
simplicidad en el dibujo, los repositorios se han considerado completamente
externos a la red. El mapa de red del escenario se muestra en la figura 43.
Figura 43: mapa de red del escenario II

- 51 -
Sobre el segundo entorno se han realizado las mismas medidas que sobre el
primero y como se ha mencionado anteriormente la única diferencia de del entorno
pasa por la incorporación del nuevo nodo que corre sobre una arquitectura distinta,
arm.
Parece razonable pensar que al haber incorporado un nuevo nodo el clúster
en su conjunto dispone de más recursos hardware y por tanto los tiempos de
despliegue deberían ser menores que en el primer escenario. Sin embargo, como se
esperaba, los resultados no son semejantes. A continuación en la figura 42 se
muestran los tiempos de despliegue de la imagen httpd en el primer y segundo
escenario. Cabe remarcar las diferencias que se observan entre ambos,
principalmente son:
 Aumento, casi en factor 10, de los tiempos de despliegue de las
imágenes. Pese a haber añadido un nodo más, los tiempos de
despliegue son casi 10 veces superiores.
 La relación entre el tiempo de despliegue y el número de réplicas no es
tan lineal como en el primer escenario. Se puede apreciar a simple
vista en la figura 44, y matemáticamente a través del coeficiente de
correlación que pese a que sigue siendo bastante alto, en concreto
0,9684, ha disminuido con respecto al primer escenario.
Despliegue httpd escenario II

140
120
100
80
60 y = 1,1589x + 4,826
R² = 0,9684
40
20
0
0 20 40 60 80 100 120
Tiempo neto II Tiempo neto I Tendencia lineal
Figura 44: despliegue httpd escenario II
Además, según se muestra en la figura 45, el tiempo destinado al despliegue

de cada réplica no tiene asintóticamente a cero como en el primer escenario.
Matemáticamente significa que este modelo no se ajusta bien a una función
exponencial decreciente que tienda a 0 según aumenta el número de réplicas y
muestra de ello es que el coeficiente de correlación ha caído hasta 0,429.
- 52 -
Tiempo/réplica httpd escenario II

6
Tiempo/réplica (s)
4 y = 2,8792e-0,063x
R² = 0,429
3
0
1 2 3 4 5 6 7 8 9 10 15 20 50 100
Tiempo/réplica Tendencia exponencial
Figura 45: tiempo de despliegue por réplica httpd escenario II
Las peculiaridades obtenidas en este entorno se justifican analizando y

estudiando detalladamente el estado del clúster en cada momento. Los retardos
obtenidos con respecto al primer escenario tienen bastante que ver con los recursos
hardware del clúster, principalmente del nuevo nodo.
Como se muestra en el anexo A, la Raspberry es el nodo del clúster con menos
recursos hardware. Sin embargo, pese a estar en desigualdad de condiciones, el
balanceador de carga de la plataforma Docker Swarm decide hacer un reparto
equitativo de los contenedores a través de todos los nodos del clúster. Por ejemplo,
en el caso del despliegue de 100 contenedores se han repartido de forma equitativa
entre todos los nodos según se muestra en la figura 46.
Reparto de contenedores
17% 16%
17% 17%
17% 16%
Gredos raspberrypi02 ubuntu001 ubuntu002 ubuntu003 Leon
Figura 46: reparto de contenedores
La causa de las irregularidades encontradas en los gráficos de este escenario

es la sobrecarga producida sobre el nodo raspberrypi02. Con el fin de corregirlas y
de sacar el máximo provecho de todos los nodos del clúster, cada uno en su medida,
- 53 -
se pueden hacer uso de otras técnicas y distinciones como por ejemplo las etiquetas.
Haciendo uso de las etiquetas, como se recoge en el anexo B, se puede conseguir una
mayor granularidad y distribuir el despliegue del servicio de forma que se aproveche
el hardware al máximo sin llegar a sobrecargarlo.
4.2.3. Escenario 3. Kubernetes monoarquitectura.
El tercer escenario se construye a partir de los nodos representados en la tabla
3.
En el anexo D se recogen todos los pasos necesarios para la construcción de
un clúster haciendo uso de Kubernetes, desde la instalación de la tecnología, hasta
la construcción del clúster, pasando por una serie de apartados que recogen los
conceptos básicos de manejo de la plataforma.
En el tercer escenario se dispone de un conjunto de nodos agrupados en
forma de clúster que al igual que en el primer escenario, son accesibles y
gestionables desde dentro de la red y desde internet. Por simplicidad en el dibujo,
los repositorios se han considerado completamente externos a la red. El mapa de
red del escenario se muestra en la figura 47.
Figura 47: mapa de red del escenario III
A continuación en la figura 48, se representan los tiempos de despliegue del

contenedor httpd sobre este escenario. Al igual que en el primer escenario se aprecia
claramente una relación lineal muy fuerte entre el tiempo de despliegue en función
del número de réplicas, que matemáticamente se explica con un índice de
correlación de 0,986. Por tanto el modelo puede ser definido de manera precisa a
través de la ecuación de la recta que se muestra en el gráfico.
- 54 -
Despliegue httpd k8s

200

150
y = 1,7998x - 3,8422
100
R² = 0,9863
50
0
0 20 40 60 80 100 120
-50
Tiempo neto III Tiempo neto I Lineal (Tiempo neto III)
Figura 48: despliegue httpd escenario I y escenario III
Sin embargo, cabe destacar que pese a que los nodos del clúster son los
mismos que en el primer escenario, los tiempos de despliegue de este son bastante
superiores a los anteriores. Esto es debido a que al instalar una plataforma que
gestiona Docker como es Kubernetes las labores de gestión y administración del
clúster se multiplican y como consecuencia el tiempo que se necesita para realizar
operaciones en el entorno aumenta. Del mismo modo, como se muestra en la figura
49, los tiempos de despliegue por réplica no tienden a cero a medida que se aumenta
el número de réplicas por servicio, como ocurría en el primer escenario y ahora la
función que mejor define el modelo de datos es una función logarítmica con un
coeficiente de correlación de tan sólo 0,2881.
No obstante, normalmente merece la pena asumir ese incremento del tiempo
por las prestaciones y mejoras, incluidas en el marco tecnológico, que ofrece la
plataforma a la hora de orquestar y gestionar microservicios con respecto al
orquestador de Docker Swarm.
Despliegue httpd k8s

5
Tiempo despliegue/réplica (s)
4,5
4
3,5
3
y = -0,405ln(x) + 2,5449
2,5 R² = 0,2881
2
1,5
1
0,5
0
0 20 40 60 80 100 120
Tiempo/réplica Logarítmica (Tiempo/réplica)
Figura 49: tiempos de despliegue por réplica httpd escenario III

- 55 -
Como se ha reflejado en el marco tecnológico, Kubernetes dispone de una
serie de componentes de red que pueden funcionar en varias arquitecturas. Sin
embargo, la elección de la arquitectura se hace en un fichero manifest en el
momento de creación de los pod de red y es común para todo el clúster. Lo que
significa que todos los nodos del clúster han tener en común la arquitectura. Esto
no deja de ser una limitación, y es por ello que se han estudiado alternativas y formas
de sacar el máximo partido de pod de red como Flannel y Weave Net que pueden
funcionar en varias arquitecturas pero no de forma simultánea. El problema que
aparece es que al elegir una determinada arquitectura, por ejemplo x86_64, todos
los nodos del clúster se descargan y ejecutan los contenedores que han sido creados
para dicha arquitectura, incluyendo los nodos que son de otras arquitecturas como
el nodo raspberrypi02. Obviamente esto trae consigo problemas puesto que
raspberrypi02 no será capaz de ejecutar dichos contenedores y el clúster no
funcionará. La solución, como se detalla en el anexo D, pasa por hacer una serie de
modificaciones que permitan discriminar la arquitectura de forma que cada nodo
del clúster consiga ejecutar los contenedores que son afines a su arquitectura. Con
dicho procedimiento se consigue formar un clúster multiarquitectura con
Kubernetes, sin embargo, pese a haber podido comprobar que cada nodo obtiene y
ejecuta satisfactoriamente los pods que corresponden a su arquitectura, no se han
podido realizar medidas de despliegue en dicho entorno ya que las limitaciones de
hardware del nodo raspberrypi02, y la exigencia por parte de Kubernetes de
deshabilitar el swap hacen que en ocasiones se le agote la memoria y se reinicie
constantemente.
Por otro lado, una vez concluido el análisis de los tres escenarios se
recomienda la lectura del anexo C en el que se detalla el procedimiento para la
instalación de OpenBaton y la creación y despliegue de funciones de red. Como se
explica en el anexo, una vez realizada toda la instalación de OpenBaton y los drivers
necesarios se consigue listar, gestionar y manipular las imágenes de Docker que
serán utilizadas para el despliegue de las funciones de red. Sin embargo, se ha
detectado que en el momento del desarrollo de esta memoria, la plataforma no es
capaz por completo de lanzar las imágenes y tratarlas como funciones de red. Dicho
comportamiento ha sido reportado a la comunidad y a efectos de esta memoria se
considera como un punto a resolver en el futuro.
- 56 -
PRESUPUESTO
5. PRESUPUESTO
Para la realización de este proyecto se han hecho uso de unos recursos
hardware y humanos específicos, por lo que se ha incurrido en un coste que se
analiza de manera detallada a continuación:
En cuanto a mano de obra, siguiendo los precios definidos en el documento
para un técnico de telecomunicaciones [48], el gasto en personal considerado se
recoge en la tabla 5.
Tabla 5: costes mano de obra
Concepto Unidades Precio Total (€)

ud. (€)
Horas de
320 28,92 9.254,40
trabajo
Teniendo en cuenta que los recursos hardware no han sido comprados para
la ocasión y por lo tanto no suponen un coste directo para el proyecto, el
presupuesto total del proyecto es 9.254,40€.
Sin embargo, en este presupuesto también se van a valorar diferentes
opciones a la hora de asumir los costes del equipamiento. Tradicionalmente los
recursos se compraban y se usaban, pero hoy en día existe cierta tendencia a alquilar
determinados componentes hardware como ordenadores y servidores, por lo que en
este presupuesto se van a contemplar ambas opciones.
En primer lugar, considerando la opción de compra, a la cantidad de
9.254,40€ obtenida en el cálculo anterior se le deben sumar los gastos de material
que se incluyen en la tabla 6.
Tabla 6: coste compra de hardware
Precio ud.
Concepto Unidades Total (€)
(€)
Pack completo
1 79,99 79,99
Raspberry pi 3
Servidor físico 2 1.000 2.000
Así pues, considerando la compra del equipamiento el presupuesto del

proyecto asciende a 11.334,39€.
En segundo lugar, en la tabla 7 se muestran los precios de alquiler de unos
equipos que se asemejan en características a los utilizados. Las características del
equipamiento hardware se encuentran recogidas en el anexo A. Teniendo en cuenta
que las empresas de alquiler [49] requieren un contrato mínimo de tres años y que
la duración de este proyecto ha sido de 4 meses, asumir el coste de los tres años
dispararía el precio del proyecto.
- 57 -
Tabla 7: coste alquiler hardware
Precio
Número
Concepto Unidades ud/mes Total (€)
meses
(€)
Alquiler
2 72,51 36 5.220,72
servidor físico
Considerando el alquiler de los servidores físicos, el coste del pack de

Raspberry pi 3 y la mano de obra, el coste del proyecto asciende a 14.555,11€, de los
cuales si sólo se pagasen los recursos alquilados durante los cuatro meses, el precio
sería de 9.914,47€.
Para concluir, en la figura 50 se muestra un gráfico comparativo en el que se
observan los precios de las diferentes modalidades recogidas. A ambas cantidades
habría que sumarles la cantidad de 79,99€ correspondiente a la compra del pack de
Raspberry pi 3 que no se representa en el gráfico por suponer una cantidad
demasiado pequeña que hace que no se vea con claridad.
COMPARATIVA PRESUPUESTO
Mano de obra Recursos
€5.220,72
€2.000,00
€9.254,40 €9.254,40
COMPRA ALQUILER
Figura 50: comparativa presupuestos
Nota: todos los precios aquí mencionados han sido tomados a fecha 25 de
junio de 2018.
- 58 -
CONCLUSIONES Y TRABAJOS FUTUROS
6. CONCLUSIONES Y TRABAJOS FUTUROS

6.1. CONCLUSIONES
Como se indicó en capítulos anteriores, los objetivos de este proyecto pasan
por la realización de un estudio de ingeniería lo más próximo posible a la realidad
del despliegue de microservicios y funciones de red en diferentes entornos
diseñados y pensados para la ocasión.
A través del estudio y la investigación se han adquirido multitud de
conocimientos relacionados con arquitecturas software, microservicios y NFV, que
han permitido la consolidación de unos conocimientos que posteriormente se han
plasmado a través de desarrollos teóricos y prácticos.
Siendo más concretos, el estudio realizado ha servido para la creación de
diversos escenarios, cada uno con sus características y peculiaridades, sobre los que
se han desplegado y estudiado diferentes microservicios y funciones de red. De
forma adicional, se ha desarrollado una función virtual de red, desplegable en un
contenedor que podría sustituir a un firewall tradicional desplegado en forma de
dispositivo físico en la red.
A nivel global, el proyecto ha resultado muy provechoso ya que ha permitido
la adquisición de multitud de conceptos, tecnologías nuevas y la ampliación de la
visión tecnológica actual. Por ello se considera que los objetivos se han cumplido
satisfactoriamente.
6.2. TRABAJOS FUTUROS
Como se ha detallado en el tercer capítulo, este proyecto tiene una serie de
especificaciones y restricciones de diseño que le otorgan un gran alcance y lo hacen
aplicable también en entornos reducidos que se caracterizan por la escasez de
recursos hardware.
La ampliación y extensión del proyecto a aquellos escenarios reducidos han
obligado a tomar una serie de decisiones de diseño han descartado algunas
tecnologías muy punteras e interesantes como OpenStack y Cloudify. Dichas
tecnologías ya han sido estudiadas y permiten la creación de un entorno de
computación en la nube (OpenStack) y la orquestación de aplicaciones y servicios
de red en la nube (Cloudify). Sin embargo, queda pendiente un diseño y análisis
profundo a nivel práctico en el futuro, cuando se disponga de los recursos hardware
necesarios para el mismo.
- 59 -
- 60 -
REFERENCIAS
7. REFERENCIAS
E.
[ Forbes, «Microservices in Java,» [En línea]. Available:
1] https://codeburst.io/microservices-in-java-never-a7f3a2540dbb. [Último
acceso: 25 junio 2018].
R.
[ Velasco, «IaaS, PaaS, CaaS, SaaS – ¿Qué significan estos conceptos de
2] Cloud Computing?,» 17 07 2016. [En línea]. Available:
https://www.redeszone.net/2016/07/17/iaas-paas-caas-saas-significan-
estos-conceptos-cloud-computing/. [Último acceso: 25 junio 2018].
Cisco,
[ «Fog Computing and the Internet of Things: Extend,» 04 2015. [En
3] línea]. Available:
https://www.cisco.com/c/dam/en_us/solutions/trends/iot/docs/computin
g-overview.pdf. [Último acceso: 25 junio 2018].
G.
[ Gonzalez, «Qué es el “Fog Computing” o computación en la niebla,» 22
4] 04 2014. [En línea]. Available:
https://hipertextual.com/archivo/2014/04/fog-computing/. [Último
Azure,
[ «¿Qué es la informática en la nube?,» [En línea]. Available:
5] https://azure.microsoft.com/es-es/overview/what-is-cloud-computing/.
[Último acceso: 25 junio 2018].
«Microservices
[ vs Monolithic Architecture,» [En línea]. Available:
6] https://www.mulesoft.com/resources/api/microservices-vs-monolithic.
A.
[ Schroeder, «Microservice Architectures,» [En línea]. Available:
7] https://pdfs.semanticscholar.org/presentation/324e/9c16a30d388a219497
7243a077c1499083f1.pdf. [Último acceso: 25 junio 2018].
IEEE,
[ IEEE- Std 1471-2000 IEEE Recommended Practice for Architectural
8] Description of Software-Intensive Systems, New York, 2000.
M.
[ Endrei, J. Ang, A. Arsanjani, S. Chua, P. Comte, P. Krogdahi, M. Luo y T.
9] Newling, Patterns: ServiceOriented Architecture and Web Services, 2004.
G.
[ Chun Lin, K. Eng Tat Desmond, N. Tayza Htoon y N. Van Thuat , Service
10] Oriented Architecture.
OMG,
[ «Corba,» [En línea]. Available: http://www.corba.org/. [Último
11] acceso: 25 junio 2018].
M.
[ Fowler, «Microservices,» 25 March 2014. [En línea]. Available:
12] https://www.martinfowler.com/articles/microservices.html. [Último
- 61 -
M.
[ McIlroy, E. N. Pinson y B. A. Tague, The Bell System Technical Journal,
13] p. 388, July-August 1978.
«The
[ Bell System Technical Journal,» July-August 1978. [En línea].
14] Available: http://emulator.pdp-11.org.ru/misc/1978.07_-
_Bell_System_Technical_Journal.pdf. [Último acceso: 25 junio 2018].
M.
[ Conway, «Conways Law,» 1968. [En línea]. Available:
15] http://www.melconway.com/Home/Conways_Law.html. [Último acceso:
25 junio 2018].
E.
[ Mueller, «What Is DevOps?,» 2 August 2010. [En línea]. Available:
16] https://theagileadmin.com/what-is-devops/. [Último acceso: 25 junio
2018].
«What
[ is an ESB?,» [En línea]. Available:
17] https://www.mulesoft.com/resources/esb/what-esb. [Último acceso: 25
junio 2018].
«RabbitMQ,»
[ [En línea]. Available: https://www.rabbitmq.com/. [Último
N.
[ Peck, «Microservice Principles: Decentralized Governance,» 5
19] September 2017. [En línea]. Available:
https://medium.com/@nathankpeck/microservice-principles-
decentralized-governance-4cdbde2ff6ca. [Último acceso: 25 junio 2018].
S.
[ Daya, N. Van Duy, K. Eati, C. M Ferreira, D. Glozic , V. Gucer, M. Gupta ,
20] S. Joshi, V. Lampkin, M. Martins, S. Narain y R. Vennam, Microservices
from Theory to Practice. Creating Applications in IBM Bluemix Using the
Microservices Approach, Redbooks, 2015.
M.
[ Fowler, «Microservices Resource Guide,» [En línea]. Available:
21] https://martinfowler.com/microservices/. [Último acceso: 25 junio 2018].
Amazon,
[ «¿Qué son los contenedores?,» [En línea]. Available:
22] https://aws.amazon.com/es/what-are-containers/. [Último acceso: 25
junio 2018].
T.
[ H. II, Advanced Microservices. A Hands-on Approach to Microservice
23] Infrastructure and Tooling, San Francisco, 2017.
«Docker
[ vs LXC,» [En línea]. Available:
24] https://www.upguard.com/articles/docker-vs-lxc. [Último acceso: 25 junio
2018].
R.
[ McKendrick y S. Gallagher, Mastering Docker, Birmingham: Packt, 2017.
25]
- 62 -
REFERENCIAS
Docker,
[ «What is a container,» [En línea]. Available:
26] https://www.docker.com/what-container. [Último acceso: 25 junio 2018].
K.
[ Casey, 13 September 2017. [En línea]. Available:
27] https://enterprisersproject.com/article/2017/9/microservices-and-
containers-6-things-know-start-time. [Último acceso: 25 junio 2018].
Docker,
[ «How nodes work,» [En línea]. Available:
28] https://docs.docker.com/engine/swarm/how-swarm-mode-
works/nodes/#manager-nodes. [Último acceso: 25 junio 2018].
F5,
[ «Load balancer,» [En línea]. Available: https://f5.com/glossary/load-
29] balancer. [Último acceso: 25 junio 2018].
Docker,
[ «Scale your service,» [En línea]. Available:
30] https://docs.docker.com/docker-cloud/apps/service-scaling/. [Último
Docker,
[ «Docker Swarm,» [En línea]. Available:
31] https://docs.docker.com/engine/swarm/key-concepts/. [Último acceso: 25
junio 2018].
H.
[ Saito, H.-C. Chloe Lee y C.-Y. Wu, DevOps with Kubernetes,
32] Birmingham: Packt, 2017.
Google
[ Trends, «Interés a lo largo del tiempo: Kubernetes, Docker
33] Compose, Docker Swarm,» [En línea]. Available:
https://trends.google.com/trends/explore?date=today%2012-
m,today%2012-m,today%2012-
m&geo=,,&q=Kubernetes,Docker%20Compose,Docker%20Swarm. [Último
Oracle,
[ «Brief History of Virtualization,» [En línea]. Available:
34] https://docs.oracle.com/cd/E26996_01/E18549/html/VMUSG1010.html.
«What
[ is NFV – Network Functions Virtualization – Definition?,» [En
35] línea]. Available: https://www.sdxcentral.com/nfv/definitions/whats-
network-functions-virtualization-nfv/. [Último acceso: 25 junio 2018].
ETSI,
[ «Network Functions Virtualisation (NFV); Management and
36] Orchestration,» 2014. [En línea]. Available:
http://www.etsi.org/deliver/etsi_gs/NFV-
MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf. [Último
F.
[ Zarrar Yousaf, P. Loureiro, F. Zdarsky y M. Liebsh, « ETSI NFV
37] management and orchestration (MANO) framework overview,» [En línea].
- 63 -
Available: https://www.researchgate.net/figure/ETSI-NFV-management-
and-orchestration-MANO-framework-overview-1_fig1_291019215.
«Why
[ is TOSCA Relevant to NFV? Explanation,» [En línea]. Available:
38] https://www.sdxcentral.com/nfv/definitions/tosca-nfv-explanation/.
Openbaton,
[ [En línea]. Available: https://openbaton.github.io/. [Último
ONAP,
[ [En línea]. Available: https://www.onap.org/. [Último acceso: 25
40] junio 2018].
Cloudify,
[ [En línea]. Available: https://cloudify.co/. [Último acceso: 25
41] junio 2018].
ONF:
[ Open Networking Foundation, «Software-Defined Networking: The
42] New Norm for Networks,» [En línea]. Available:
http://www.ramonmillan.com/documentos/bibliografia/SDNTheNewNor
mForNetworks_ONF.pdf. [Último acceso: 25 junio 2018].
A.
[ Maleki, M. Moahimenul Hossain, J. Georges, E. Rondeau y T. Divoux,
43] «An SDN Perspective to Mitigate the Energy Consumption of Core
Networks – GEANT2,» 225 06 2018. [En línea]. Available:
https://www.researchgate.net/figure/Traditional-Network-versus-
SDN_fig1_319876305. [Último acceso: 25 junio 2018].
opennetworking,
[ «Software-Defined Networking (SDN) Definition,» [En
44] línea]. Available: https://www.opennetworking.org/sdn-definition/.
opennetworking,
[ «OpenFlow Switch Specification,» [En línea]. Available:
45] https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-
switch-v1.5.1.pdf. [Último acceso: 25 junio 2018].
Openstack,
[ «Openstack projects,» [En línea]. Available:
46] https://www.openstack.org/software/project-navigator. [Último acceso: 25
junio 2018].
OpenStack,
[ «Feature Support Matrix,» [En línea]. Available:
47] https://docs.openstack.org/nova/latest/user/support-matrix.html. [Último
Tragsa,
[ «Tarifas 2015 para encomiendas sujetas a impuestos,» [En línea].
48] Available: http://www.tragsa.es/es/grupo-tragsa/regimen-
juridico/Documents/ACTUALIZACI%C3%93N%20TARIFAS%20AGOSTO/
Tarifas%202015%20para%20encomiendas%20sujetas%20a%20impuestos.
pdf. [Último acceso: 25 junio 2018].
- 64 -
REFERENCIAS
Skrenting,
[ «Alquiler de recursos hardware,» [En línea]. Available:
49] http://www.skrenting.com. [Último acceso: 25 junio 2018].
Golang,
[ «Download the Go distribution,» [En línea]. Available:
50] https://golang.org/doc/install. [Último acceso: 25 junio 2018].
OpenBaton,
[ «VIM Driver for Docker,» [En línea]. Available:
51] https://github.com/openbaton/go-docker-driver. [Último acceso: 25 junio
2018].
K.
[ R, «Multiplatform (amd64 and arm) Kubernetes cluster setup,» 01 2018.
52] [En línea]. Available:
https://gist.github.com/squidpickles/dda268d9a444c600418da5e1641239
af. [Último acceso: 25 junio 2018].
E.
[ Knorr, «What is cloud computing? Everything you need to know now,»
53] 10 07 2017. [En línea]. Available:
https://www.infoworld.com/article/2683784/cloud-computing/what-is-
cloud-computing.html. [Último acceso: 25 junio 2018].
- 65 -
- 66 -
ANEXOS
ANEXOS
- 67 -
- 68 -
ENTORNO DISPONIBLE
A. ENTORNO DISPONIBLE
El hardware utilizado para el desarrollo de este proyecto se recoge en la tabla
8.
Tabla 8: características entorno
NODO CPU RAM (GB)

Núm. Frecuencia (GHz)
GREDOS 12 4 32
Leon 12 4 32
raspberrypi02 4 1,2 4
ubuntu001 1 4 2
ubuntu002 1 4 2
ubuntu003 1 4 2
Todos los nodos funcionan sobre una arquitectura x86_64, a excepción de

raspberrypi02 que lo hace sobre armv7l.
- 69 -
- 70 -
DOCKER
B. DOCKER
Instalación
Docker en Ubuntu
Requisitos:
 Versión de 64 bits de alguna de las siguientes distribuciones de
Ubuntu:
o Artful 17.10 (Docker CE 17.11 Edge y superiores)
o Xenial 16.04 (LTS)
o Trusty 14.04 (LTS)
 Arquitecturas:
o x86_64
o armhf
o s390x (IBM z)
o ppc64le (IBM power)
La versión utilizada de Ubuntu es “Ubuntu Xenial”, en concreto Ubuntu
16.04.4 LTS, de forma que si se ejecuta el comando “lsb_release -a” la salida
obtenida es:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Codename: xenial
Por otro lado, el comando “lsb_release –cs” referenciado en el cuarto

paso, devuelve el nombre de la versión utilizada. En este caso: “xenial”
Será necesario conocer la arquitectura que se está utilizando. Puede ser
consultada ejecutando el comando “lscpu”. Se obtendrá una salida equivalente a:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 142
Model name: Intel(R) Core(TM) i7-7600U CPU @
2.80GHz
Stepping: 9
CPU MHz: 2904.002
BogoMIPS: 5808.00
Hypervisor vendor: KVM
Virtualization type: full
- 71 -
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0
Flags: fpu vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse
sse2 syscall nx rdtscp lm constant_tsc rep_good nopl
xtopology nonstop_tsc pni pclmulqdq monitor ssse3 cx16
sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand
hypervisor lahf_lm abm 3dnowprefetch retpoline kaiser avx2
rdseed clflushopt
Los pasos son:

1. Actualizar la lista de paquetes
sudo apt-get update
2. Instalar una serie de complementos que nos permitan hacer uso de apt
sobre HTTPS. Es posible que estos paquetes ya estén instalados
sudo apt-get install apt-transport-https \
ca-certificates curl software-properties-common
3. Añadir la clave GPG (GNU Privacy Guard) de Docker

curl -fsSL https://download.docker.com/linux/ubuntu/gpg |
sudo apt-key add –
Si se añade la clave correctamente debe aparecer en pantalla “OK”

4. Añadir el repositorio del que se van a descargar los paquetes de Docker.
En función de la arquitectura que estemos usando hay que ejecutar un
comando u otro.
Por ejemplo, si se hace uso de la arquitectura x86_64 / amd64, lanzar el
siguiente comando:
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable"
En caso de hacer uso de armhf, lanzar el siguiente comando:

"deb [arch=armhf] https://download.docker.com/linux/ubuntu \
5. Actualizar la lista de paquetes de apt con el objetivo de que incluya los

existentes en el repositorio añadido en el paso 4.
sudo apt-get update
- 72 -
DOCKER
6. Descargar la última versión de docker-ce

sudo apt-get install docker-ce
Con este comando se descarga y queda operativa la última versión de Docker

existente en el repositorio. En caso de requerir una versión específica continuar con
el paso 7.
La versión de docker puede ser comprobada con el comando “docker
versión”, obteniendo una salida parecida a la siguiente:
Client:
Version: 18.03.1-ce
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:17:20 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.1-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:15:30 2018
OS/Arch: linux/amd64
Experimental: false
7. Descargar una versión específica de docker-ce

El primer paso es listar las versiones que el repositorio ofrece:
apt-cache madison docker-ce
Se obtendrá una lista parecida a la siguiente:

docker-ce 18.03.1~ce-0~ubuntu <URL> <VERSION> <ARCH> Packages
………………………………………………………………………………………………………………………………………………………………
Para descargar, por ejemplo la versión 17.12.0, ejecutar el siguiente

comando:
sudo apt-get install -y docker-ce=17.12.0~ce-0~ubuntu
NOTA: Por defecto para hacer uso de Docker es necesario ser el usuario
administrador. Si se desea que un determinado usuario pueda hacer uso sin ser
administrador, basta con añadirlo al grupo docker:
sudo usermod -aG docker <NOMBRE-USUARIO>
- 73 -
Docker en Debian
Requisitos:
 Versión de 64 bits de alguna de las siguientes distribuciones de Debian
o Raspbian:
o Buster 10 (Docker CE 17.11 Edge only)
o Stretch 9 (stable) / Raspbian Stretch
o Jessie 8 (LTS) / Raspbian Jessie
o Wheezy 7.7 (LTS)
 Arquitecturas:
o x86_64
o armhf
La versión utilizada de Raspbian es “Raspbian stretch”, en concreto Raspbian
9.4, de forma que si se ejecuta el comando “lsb_release -a” la salida obtenida
es:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
Por otro lado, el comando “lsb_release –cs” referenciado en el cuarto

paso, devuelve el nombre de la versión utilizada. En este caso: “stretch”
Será necesario conocer la arquitectura que se está utilizando. Puede ser
consultada ejecutando el comando “lscpu”. Se obtendrá una salida equivalente a:
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model: 4
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1200.0000
CPU min MHz: 600.0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon
vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
Los pasos son:

sudo apt-get update
sobre HTTPS. Es posible que estos paquetes ya estén instalados
sudo apt-get install \
- 74 -
DOCKER
apt-transport-https \
ca-certificates \
curl \
gnupg2 \
software-properties-common
3. Añadir la clave GPG (GNU Privacy Guard) de Docker

curl -fsSL https://download.docker.com/linux/debian/gpg |
sudo apt-key add -

4. Añadir el repositorio del que se van a descargar los paquetes de Docker.
En función de la arquitectura que estemos usando hay que ejecutar un
comando u otro.
Por ejemplo, si se hace uso de la arquitectura x86_64 / amd64, lanzar el
siguiente comando:
"deb [arch=amd64] https://download.docker.com/linux/debian \
En caso de hacer uso de armhf, lanzar el siguiente comando:

echo "deb [arch=armhf]
https://download.docker.com/linux/debian \
$(lsb_release -cs) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list
En algunas versiones el uso del comando add-apt-repository no está

soportado. En ese caso será necesario añadir el repositorio manualmente en el
fichero /etc/apt/sources.list. Para ello, editar dicho fichero y añadir una
nueva línea, al final, que contenga:
deb-src [arch=<ARCH>] \
https://download.docker.com/linux/debian <CODE-NAME> stable
5. Actualizar la lista de paquetes de apt con el objetivo de que incluya los

existentes en el repositorio añadido en el paso 4.
sudo apt-get update
6. Descargar la última versión de docker-ce

sudo apt-get install docker-ce
Con este comando se descarga y queda operativa la última versión de Docker

existente en el repositorio. En caso de requerir una versión específica continuar con
el paso 7.
La versión de docker puede ser comprobada con el comando “docker
versión”, obteniendo una salida parecida a la siguiente:
Client:
- 75 -
Version: 18.03.1-ce
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:25:04 2018
OS/Arch: linux/arm
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.1-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:21:09 2018
OS/Arch: linux/arm
Experimental: false
7. Descargar una versión específica de docker-ce

El primer paso es listar las versiones que el repositorio ofrece:
apt-cache madison docker-ce
Se obtendrá una lista parecida a la siguiente:

docker-ce 18.03.1~ce-0~debian <URL> <VERSION> <ARCH> Packages
………………………………………………………………………………………………………………………………………………………………
Para descargar, por ejemplo la versión 17.12.0, ejecutar el siguiente

comando:
sudo apt-get install -y docker-ce=17.12.0~ce-0~debian
NOTA: Por defecto para hacer uso de Docker es necesario ser el usuario
administrador. Si se desea que un determinado usuario pueda hacer uso sin ser
administrador, basta con añadirlo al grupo docker:
sudo usermod -aG docker <NOMBRE-USUARIO>
Instalación genérica
Existe otra alternativa que en algunas ocasiones resulta más eficaz y exitosa,
sobre todo si se experimentan problemas con la instalación y los repositorios, que
pasa por hacer uso del script que se aloja en la siguiente url: https://get.docker.com/
Para instalarlo basta con ejecutar el siguiente comando:
curl -sSL https://get.docker.com | sh
- 76 -
DOCKER
Manejo
Nociones básicas
A continuación se recogen una serie de comandos de manejo básico de
Docker.
En primer lugar, el estado de ejecución del servicio Docker se puede consultar
y modificar con:
service docker status
service docker stop
service docker start
service docker restart
La versión de Docker instalada, puede ser consultada con el comando:

docker version
Se pueden obtener una serie de detalles como el número de contenedores

arrancados, parados, imágenes… y datos de versión de Docker, entre otros valores,
ejecutando el siguiente comando:
docker info
Gestión de imágenes y contenedores

Como se detalló en el marco tecnológico, un contenedor es una instancia en
ejecución de una imagen, así que para poder lanzar un contenedor será necesario
disponer de dicha imagen al menos en el momento de puesta en ejecución.
Listar imágenes con “docker images” o “docker image ls”
administrador@ubuntu001:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mongo latest f93ff881751f 11 days ago 368MB
httpd latest fb2f3851a971 5 weeks ago 178MB
hello-world latest e38bc07ac18e 7 weeks ago 1.85kB
Se observa que cada imagen proviene de un repositorio, tiene una etiqueta y

un identificador único.
En el caso de querer descargar alguna imagen, por defecto del repositorio
oficial de Docker Hub puede hacerse a través del comando “docker pull
<REPOSITORIO>/<IMAGEN>:<VERSIÓN>”. Si la versión no se especifica se
intentará descargar la última, “latest”. Por ejemplo, el comando “docker pull
portainer/portainer:latest” es equivalente al comando “docker pull
portainer/portainer”
Se pueden buscar imágenes en el repositorio a través del comando
“docker search <BUSQUEDA>”. Ejemplo: “docker search apache”
Como se mencionó en el apartado de contenedores, existen repositorios
públicos y privados. Para acceder a los privados es necesario autenticarse a través
del comando “docker login” que pedirá un usuario y contraseña.
- 77 -
Para lanzar un contenedor se utiliza el comando “docker run
[OPCIONES]”. De forma que para poner en ejecución el contenedor de httpd, un
servidor web muy básico bastaría con ejecutar “docker run httpd:latest”.
Sin embargo, está escuchando por el puerto 80 del contenedor, no del host en el que
se ejecuta, así que si queremos publicar el puerto entre el contenedor y el host será
necesario añadir el parámetro –p 80:80 que indica que el puerto 80 del host ha de
ser publicado. Por tanto, para ejecutar el mismo contenedor haciendo público el
puerto 80, y además ejecutándolo en segundo plano (opción –d), el comando es:
“docker run -d -p 80:80 httpd:latest”. Además, otra de las
características de los contenedores estudiadas en el capítulo 2, es su aislamiento, de
forma que un contenedor por defecto no tiene acceso al sistema de ficheros del nodo
en el que se lanza. Para compartir un sistema de ficheros entre el host y el
contenedor hay que añadir el parámetro –v <PATH HOST>:<PATH CONTENEDOR>
al comando docker run. Ejemplo: “docker run -d -p 80:80 –v
/var/www:/var/www httpd:latest”
Para conseguir que un contenedor se inicie automáticamente con el inicio del
nodo anfitrión se utilizar el parámetro “—restart”, que admite tres valores:
 “-no”: hará que el contenedor no inicie cuando inicia el sistema

 “-on-failure[<INTENTOS>]”: reinicia el contenedor si ha
ocurrido algún fallo, y se le puede indicar el número máximo de
reintentos.
 “-always”: reinicia el contenedor siempre.
Ejemplo: “docker run --restart=always mongo”
En cuanto a gestión de contenedores:
 Listar contenedores en ejecución: “docker ps”

 Listar todos los contenedores: “docker ps –a”
 Mostrar en directo el uso de recursos de los contenedores:
“docker stats”
 Arrancar un contenedor: “docker stop <ID CONTENEDOR>”
 Detener un contenedor: “docker start <ID CONTENEDOR>”
 Reiniciar un contenedor: “docker restart <ID CONTENEDOR>”
 Eliminar un contenedor: “docker rm <ID CONTENEDOR>”
 Eliminar, de forma forzada, un contenedor: “docker rm -f <ID
CONTENEDOR>”
 Listar procesos dentro de un contenedor: “docker top <ID
CONTENEDOR>”
 Ejecutar un comando dentro de un contenedor: “docker exec -ti
<ID CONTENEDOR> sh -c "echo a "”
Es relativamente común que surja la necesidad de ejecutar el
intérprete bash dentro de un contenedor: “docker exec -ti <ID
CONTENEDOR> bash”
- 78 -
DOCKER
 Se pueden monitorizar los logs de un contenedor con: “docker logs

–f <ID-CONTENEDOR>”
Construcción de imágenes
El proceso más común consiste en crear una imagen a través de un
Dockerfile, un fichero que recoge una serie de instrucciones y argumentos con las
indicaciones de creación de la imagen. Los comandos más comunes que se recogen
en un Dockerfile se muestran en la tabla 9.
Tabla 9: instrucciones Dockerfile
Comando Función
ADD Copia un fichero del sistema de ficheros del host al
contenedor
CMD Es el punto de ejecución del contenedor. Sólo puede haber
una instrucción de tipo CMD en el fichero
ENV Añade una variable de entorno al contenedor
EXPOSE Abre un puerto en el contenedor
FROM Indica la imagen que sirve de base para la creación del
contenedor. Es obligatorio y debe ser la primera instrucción
MAINTAINER Valor opcional con los datos del desarrollador
ONBUILD Sirve para ejecutar instrucciones a posteriori, cuando la
imagen se utiliza como base para otras
RUN Ejecuta un comando y guarda el resultado como una nueva
capa
USER Designa el usuario dentro del contenedor
VOLUME Sirve para crear volúmenes compartidos entre el contenedor
y el host
WORKDIR Asigna el directorio de trabajo del contenedor
Un ejemplo sencillo de Dockerfile que permite crear una imagen basada en

debían que dispone de un servidor web publicado en el puerto 80, es el siguiente:
FROM debian
MAINTAINER Daniel Moreno Belinchón "dmorenobelinchon@gmail.com"
RUN apt-get update && apt-get install -y apache2
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2
EXPOSE 80
ADD ["index.html","/var/www/html/"] #Añado mi propio fichero
ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
La imagen definida en el fichero se construye con el comando “docker

build”, pasándole una serie de parámetros. Por ejemplo para construir la imagen,
asignándole nombre, repositorio, y versión, ejecutar el siguiente comando:
docker build -t repo1/apache01:v1.2 .
Se ejecutará con:
docker run -d -p 80:80 repo1/apache01:v1.2
- 79 -
Existen varias formas de distribuir las imágenes. La más extendida es
haciendo uso de repositorios, a los que se pueden subir las imágenes con “docker
push <REPOSITORIO>/<IMAGEN>:<VERSIÓN>” y descargarlas con “docker
pull <REPOSITORIO>/<IMAGEN>:<VERSIÓN>”.
Otra forma de distribuir las imágenes es haciendo uso de ficheros. Una
imagen puede ser guardada en un fichero con el siguiente comando:
docker save –o <nombre-fichero> <nombre-imagen>
Posteriormente, para cargar una imagen de un fichero:

docker load –i <nombre-fichero>
Clúster Docker
A continuación se recogen los pasos necesarios para la puesta en marcha del
clúster definido en el apartado 4.2.2, formado por los nodos de la siguiente tabla:
Tabla 10: nodos clúster Docker
Nodo Rol
GREDOS Master
Leon Worker
ubuntu001 Worker
ubuntu001 Worker
ubuntu001 Worker
raspberrypi01 Worker
En primer lugar, hay que iniciar el clúster en el nodo Master. El comando a

ejecutar es “docker swarm init –advertise-addr <IP-MASTER>” El
comando y la salida obtenida se muestran a continuación:
daniel@GREDOS:~$ docker swarm init --advertise-addr 138.100.49.16
Swarm initialized: current node (wbi26phdlpzqfm6xyx8bszofq) is now

a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-

2e2gurvr52q4e7dugkdfq88ro9029uqbm15v7vunf11aqktzgt-
atkajrj15iit2dyrif4848k2i 138.100.49.16:2377
To add a manager to this swarm, run 'docker swarm join-token manager'

and follow the instructions.
Como se muestra al iniciar el cluster, la interfaz RPC de Docker Swarm está

escuchando en el puerto 2377.
Para añadir los nodos al clúster es necesario disponer del token que se obtiene
al crearlo. En caso de necesitar volver a generarlo, puede hacerse a través del
siguiente comando:
- 80 -
DOCKER
docker swarm join-token worker
A continuación se añaden todos los nodos trabajadores al clúster ejecutando

el siguiente comando en cada uno de ellos:
docker swarm join --token SWMTKN-1-
2e2gurvr52q4e7dugkdfq88ro9029uqbm15v7vunf11aqktzgt-
atkajrj15iit2dyrif4848k2i 138.100.49.16:2377
En este momento el clúster está constituido por los 5 nodos. Los nodos del
clúster y su estado pueden ser consultados a través del comando “docker node
ls” como se muestra en la figura 51.
Figura 51: nodos clúster Docker usando CLI
De forma análoga, el clúster puede ser gestionado haciendo uso del

contenedor Portainer. Véase figura 52:
Figura 52: resumen clúster a través de Portainer
El próximo paso es desplegar un servicio, multicontenedor, en el clúster.

Todos los pasos pueden realizarse tanto a través de la interfaz web
(haciendo uso de portainer), como a través de CLI.
- 81 -
A modo de ejemplo, se va a desplegar un servicio con 8 réplicas basadas en
httpd, un servidor web básico comúnmente conocido como Apache. Al tratarse de
un servicio web es deseable publicar un puerto para hacerlo accesible, por eso se
ha añadido al comando el parámetro -p 80:80. El comando para desplegar el
servicio es el siguiente:
docker service create --name servicioHTTPD --replicas 8 -p 80:80
httpd
Nótese que, de forma básica, se ha definido el estado óptimo del servicio: 8

réplicas. Al no especificarse nada más, estas réplicas serán distribuidas en los nodos
de acuerdo a las decisiones que tome Docker Swarm en cada momento teniendo en
cuenta los recursos que el contenedor requiere y los que hay disponibles en cada
nodo.
Como se muestra en la figura 53, los servicios pueden ser listados con el
comando “docker service ls” y con el comando “docker service ps
<NOMBRE-SERVICIO>” se pueden obtener los detalles del servicio.
Figura 53: servicios y nodos Docker Swarm
El servicio desplegado puede ser escalado con el comando: “docker

service scale <ID SERVICIO>=<NÚMERO DE TAREAS>”, como se muestra
en la figura 54.
Figura 54: ejemplos servicio Docker Swarm
Se pueden establecer restricciones de forma que los contenedores vayan

destinados a uno o un conjunto de nodos del clúster. Suele hacerse a través de
etiquetas. Las etiquetas se establecen con el siguiente comando: “docker node
update --label-add <CLAVE>=<VALOR> <NODO>”. En el clúster, se han
definido una serie de etiquetas básicas que permiten distribuir los contenedores de
forma acorde a las necesidades. En la figura 43 se muestran dos etiquetas por nodo,
son “id” y “arq” y permiten clasificar a los nodos con el objetivo de hacer
despliegues más precisos. Por ejemplo se podría desplegar un servicio en aquellos
nodos cuya arquitectura sea “x86_64” y se haría con el siguiente comando:
“docker service create --name ejemploEtiqueta --replicas 8 --
constraint 'node.labels.arq == x86_64' mongo”
- 82 -
OPENBATON
C. OPENBATON
Existen varias alternativas a la hora de instalar OpenBaton: sobre Linux,
sobre MacOS, a través de un contenedor Docker y haciendo uso del instalador
Vagrant.
Según el alcance de este proyecto, se ha optado por la versión de OpenBaton
que permite la creación y gestión de VNF sobre el motor de Docker sin hacer uso de
infraestructuras de nube pública como OpenStack o Azure.
Aunque durante el desarrollo de este proyecto se han probado tanto la
instalación manual sobre Linux como la instalación haciendo uso de contenedores
Docker, aquí se recogerá la segunda de ellas por la sencillez y rapidez de instalación
que la caracterizan.
Los componentes principales que se necesitan son:
 OpenBaton: se trata del framework principal que gestionará el
despliegue de VNF. Requiere de RabbitMQ para su funcionamiento.
 RabbitMQ: mecanismo de mensajería ligero que proporciona un
sistema de comunicación asíncrono basado en una cola.
 Docker VNFM para OpenBaton: es el responsable de la gestión del
ciclo de vida de las instancias VNF. Junto con el driver VIM de Docker
permite a OpenBaton desplegar contenedores en forma de VNF sobre
Docker Engine. Requiere de:
o Compilador Go
o RabbitMQ
 Docker VIM Driver: junto con Docker VNFM permite el despliegue de
servicios de red (NS) sobre Docker. También requiere la instalación de
Go.
a. Instalación Go
La instalación del compilador Go se recoge suficientemente detallada en la
página oficial [50].
b. Instalación VIM Driver para Docker
A continuación se recogen los pasos necesarios para la descarga y puesta en
marcha del driver VIM para Docker [51]:
1. Descargar el repositorio albergado en github
git clone git@github.com:openbaton/go-docker-driver.git
2. Acceder a la carpeta con el código

cd go-docker-driver/main
3. Compilar el código
go build -o docker-driver
- 83 -
4. Ejecutar el driver con:
./docker-driver -conf config.toml -level DEBUG
Siendo “config.toml” un fichero que recoge los parámetros de

configuración del driver. A continuación se muestra uno a modo de
ejemplo:
type = "docker"
workers = 5
username = "openbaton-manager-user"
password = "adminGredos2018"
logLevel = "DEBUG"
brokerIp = "localhost"
brokerPort = 5672
En la figura 56 se muestra una captura del driver Docker VIM en

funcionamiento.
Figura 55: Docker VIM driver en marcha
c. Instalación VNFM Docker

Los pasos de descarga y de instalación del manager VNF se recogen a
continuación:
1. Descargar los archivos del repositorio
wget https://github.com/openbaton/go-docker-
vnfm/releases/download/5.0.0/go-docker-vnfm-darwin-amd64 -
O docker-vnfm
2. Asignar permisos de ejecución a los archivos descargados

chmod +x docker-vnfm
3. Ejecutar el driver
./docker-vnfm -conf config.toml
Siendo “config.toml” un fichero que recoge los parámetros de

configuración del driver. A continuación se muestra uno a modo de
ejemplo:
type = "docker"
endpoint = "docker"
- 84 -
OPENBATON
allocate = true
workers = 1
description = "The Vnfm description"
username = "openbaton-manager-user"
password = "adminGredos2018"
logLevel = "INFO"
brokerIp = "localhost"
brokerPort = 5672
En la figura 57 se muestran los mensajes aparecidos por consola una vez

puesto en marcha componente VNFM.
Figura 56: VNFM en marcha
d. Instalación OpenBaton
Como se ha mencionado anteriormente, en este apartado se recoge la puesta
en marcha de OpenBaton en su versión contenedorizada.
Los pasos son:
1. Descargar la imagen del repositorio
docker pull openbaton/standalone
2. Ejecutar la imagen con los parámetros adecuados

docker run --name openbaton -d -p 8080:8080 -p 5672:5672 -
p 15672:15672 -p 8443:8443 -e
RABBITMQ_BROKERIP=138.100.49.16 -e
RABBITMQ_ADMIN_PSWD=adminGredos2018 openbaton/standalone
A continuación se lanzará un contenedor que dispone de RabbitMQ y el

framework de OpenBaton.
La interfaz web de OpenBaton está accesible a través del puerto 8080 del host
sobre el que se haya lanzado el contenedor. En este caso, como se muestra en la
figura 58 la URL es http://localhost:8080
- 85 -
Figura 57: inicio sesión OpenBaton
El usuario por defecto es admin y la contraseña openbaton

Una vez se inicie sesión se visualizará la ventana principal de OpenBaton
mostrada en la figura 59, en la que se muestra un mensaje que informa que no hay
recursos disponibles y sugiere que se añada un driver VIM.
Figura 58: interfaz principal OpenBaton
e. Unión OpenBaton & Drivers

Una vez puestos en marcha ambos drivers y los componentes necesarios de
OpenBaton, los próximos pasos son integrarlos y hacerlos funcionar todos juntos de
forma que desde la plataforma OpenBaton y haciendo uso de los drivers
previamente ejecutados se puedan desplegar VNF sobre el motor de Docker.
Los siguientes pasos se guiarán en base a capturas de pantalla para hacerlos
más ilustrativos.
Si no hay problemas de conectividad entre el VNFM y OpenBaton, en la
interfaz web se debe visualizar el manager de VNF de Docker (puesto en marcha en
el anexo C.c). Véase figura 60.
- 86 -
OPENBATON
Figura 59: managers VNFM en OpenBaton
El próximo paso es añadir un punto de presencia (PoP) en OpenBaton para

que sea capaz de gestionar el motor de Docker. Para que este paso se complete
satisfactoriamente ha de estar en funcionamiento el driver VIM instalado con el
anexo C.b. Para añadirlo, navegar por el menú lateral: “Manage PoPs PoP
Instances  Register a new PoP” y añadir los datos del punto de presencia. En este
caso, se ha creado a partir del siguiente fichero json:
{
"name": "vim-instance",
"authUrl": "unix:///var/run/docker.sock",
"tenant": "notenant",
"username": "admin",
"password": "adminGredos2018",
"type": "docker",
"location": {
"name": "Madrid",
"latitude": "40.4893538",
"longitude": "-3.6827461"
}
}
Una vez añadido, aparecerá en la lista como se muestra en la figura 61.
Figura 60: instancias VIM OpenBaton
Pulsando sobre dicha instancia VIM se mostrarán los detalles de la misma

pudiéndose ver que OpenBaton tiene acceso al control de Docker ya que lista y
muestra sus redes y sus imágenes. Véase figura 62.
- 87 -
Figura 61: PoP añadido y funcionando en OpenBaton
Nota: si todo esto está funcionando correctamente, cada vez que se entre en
el PoP de Docker y se pulse sobre refrescar en la consola del VIM driver en ejecución
deben aparecer mensajes de depuración indicando que está recibiendo y
contestando peticiones. Véase la figura 63.
Figura 62: mensajes Docker VIM Driver
- 88 -
OPENBATON
f. Creación de un paquete VNF

Por último, antes de desplegar una VNF es necesario crearla definiendo dos
ficheros: “Metadata.yaml” y “vnfd.json”.
El contenido de los mismos se muestra a continuación. “Metadata.yaml”:
name: MongoDB
description: MongoDB
provider: TUB
nfvo_version: 5.0.0
vim_types:
- docker
image:
upload: "check"
names:
- "mongo:latest"
link: "mongo:latest"
image-config:
name: "mongo:latest"
diskFormat: QCOW2
containerFormat: BARE
minCPU: 0
minDisk: 0
minRam: 0
isPublic: false
Y el contenido de “vnfd.json” es:

{
"name": "MongoDB",
"vendor": "TUB",
"version": "0.2",
"lifecycle_event": [],
"configurations": {
"configurationParameters": [{
"confKey":"KEY",
"value":"Value"
}],
"name": "mongo-configuration"
},
"virtual_link": [{
"name": "new-network"
}],
"vdu": [{
"vm_image": [
],
"scale_in_out": 2,
"vnfc": [{
"connection_point": [{
"virtual_link_reference": "new-network"
}]
}]
- 89 -
}],
"deployment_flavour": [{
"flavour_key": "m1.small"
}],
"type": "mongodb",
"endpoint": "docker"
}
Una vez definidos ambos ficheros con el comportamiento y características de

la VNF, se empaquetan en un paquete tar que puede ser subido directamente a
OpenBaton.
tar –cvf paquete1.tar *
El fichero “paquete1.tar” generado será subido a la plataforma de

OpenBaton a través de “VNF Packcages  Upload VNF Package”
g. Despliegue de VNF
Una vez se disponga de los paquetes en la plataforma OpenBaton, su creación
es inmediata. Es suficiente con navegar por “NS Descriptors  On Board NSD 
Compose NSD” para crear y desplegar una VNF. Véase figuras 64 y 65.
Figura 63: catálogo NSD OpenBaton
Figura 64: resumen OpenBaton
- 90 -
OPENBATON
En principio quedaría lanzada la función de red completamente, pero existe

una peculiaridad encontrada en OpenBaton que hace que en determinadas
ocasiones no sea capaz de encontrar las imágenes y por tanto no se puedan lanzar
los contenedores como funciones virtuales de red. Dicho comportamiento ha sido
reportado a la comunidad y a efectos de esta memoria se considera como un punto
a resolver en el futuro.
- 91 -
- 92 -
KUBERNETES
D. KUBERNETES
Instalación
Requisitos:
 Al menos una máquina con:
o Ubuntu 16.04+
o Debian 9
o CentOS 7
o RHEL 7
o Fedora 25/26 (best-effort)
o HypriotOS v1.0.1+
o Container Linux (comprobado con 1576.4.0)
 Al menos 2 GB de RAM por máquina. Puede funcionar con menos,
pero el funcionamiento se verá afectado y ralentizado.
 Al menos 2 CPUs por máquina.
 Conectividad completa entre las máquinas del clúster.
 Deshabilitar el swap en los nodos para conseguir un buen
funcionamiento de kubelet. Los pasos para deshabilitarlo se recogen
en el último apartado de este anexo.
El proceso de instalación aquí recogido es válido en Ubuntu, Debian y
HypriotOS.
Kubernetes es usado como orquestador de Docker, así que será necesario
tener instalado Docker previamente. Las instrucciones de instalación se encuentran
recogidas en el anexo B.
Los pasos son:
sudo apt-get update
sobre HTTPS y curl para la transferencia de URL. Es posible que estos
paquetes ya estén instalados
sudo apt-get install apt-transport-https curl
3. Añadir la clave GPG (GNU Privacy Guard) de Kubernetes

curl -s https://packages.cloud.google.com/apt/doc/apt-
key.gpg | sudo apt-key add -

4. Añadir el repositorio del que se van a descargar los paquetes de
Kubernetes.
sudo add-apt-repository “deb http://apt.kubernetes.io/
kubernetes-xenial main”
- 93 -
sudo apt-get update
6. Instalar los componentes kubelet, kubeadm y kubectl.

Con el comando “sudo apt-cache showpkg kubeadm” se puede
observar que kubeadm depende de los paquetes kubelet y kubectl, así que
con el siguiente comando deberían instalarse los tres:
sudo apt-get install kubeadm
En caso de que detectar algún error o la falta de alguno de los paquetes,

pueden instalarse manualmente con el siguiente comando:
sudo apt-get install kubelet kubeadm kubectl
Manejo
Nociones básicas
A continuación se recogen una serie de comandos de manejo básico de
Kubernetes.
 Comprobación de versión de kubectl: “kubectl version”

 Obtener información del clúster: “kubectl cluster-info”
 Obtener información del entorno y del contexto actual: “kubectl
config view” y “kubectl config current-context”
 Creación de recursos: “kubectl create –f <RUTA-FICHERO>”
 Los nodos del clúster se pueden listar con: “kubectl get nodes”
y “kubectl get nodes --show-labels”
 Obtener detalles de un nodo: “kubectl describe node <NODO>”
 Los espacios de nombres se pueden listar con: “kubectl get
namespaces”
 Los deployments se pueden listar con: “kubectl get
deployments”
 Los trabajos se pueden listar con: “kubectl get jobs”
 Si se desea obtener información general del entorno, puede ejecutarse:
“kubectl get all”
 Los servicios se pueden listar con: “kubectl get services”
 Los pods se pueden listar con: “kubectl get pods”. Nota: si se
desea listar los pods de todos los espacios de nombres, ejecutar
“kubectl get pods --all-namespaces”. También puede ser
útil listarlos ordenados por nombre: “kubectl get pods --sort-
by=.metadata.name”
 Listar sólo pods en ejecución: “kubectl get pods --field-
selector=status.phase=Running”
 Obtener detalles de un pod: “kubectl describe pod <POD>”
 Los nodos del clúster se pueden listar con: “kubectl get nodes”
- 94 -
KUBERNETES
Gestión de deployments y pods

El lanzamiento de un único pod se hace a través del comando “kubectl
run <NOMBRE> --image=<IMAGEN>”. Puede admitir parámetros que indiquen
si se desea compartir algún puerto, el número de réplicas… Por ejemplo, para crear
un deployment con 4 réplicas de la imagen httpd: “kubectl run testDeploy -
-image=httpd --port=80 --replicas=4”
Se puede escalar un deployment fácilmente con “kubectl scale --
replicas=2 deployments/<NOMBRE-DEPLOYMENT>”
Un deployment se elimina con “kubectl delete
deployments/<NOMBRE-DEPLOYMENT>”
Se puede ejecutar cualquier comando dentro de un pod ejecutar:
“kubectl exec –ti <COMANDO>”. Por ejemplo: “kubectl exec -ti
<NOMBRE-POD> bash”
Es posible monitorizar los logs de un pod con: “kubectl logs –f
“<NOMBRE-POD>”
De forma análoga a Docker, en Kubernetes también se pueden etiquetar los
nodos con el fin de poder distribuir y gestionar el clúster de forma mucho más
granular. Se hace a través del comando “kubecetl label node <NOMBRE-
NODO> <CLAVE >=<VALOR>”. Por ejemplo: “kubectl label node
ubuntu001 arquitectura=x86_64”.
Como se ha mencionado anteriormente, con el comando “kubectl run
<NOMBRE> --image=<IMAGEN>” se pueden desplegar individual y
colectivamente los pods en el clúster. Sin embargo, en Kubernetes resulta muy
común hacer despliegues más completos y complejos haciendo uso de ficheros. Los
procedimientos se detallan a continuación:
Para el despliegue de un único pod, crear un fichero llamado
“deploy1.yaml” y añadirle el siguiente contenido:
apiVersion: v1
kind: Pod
metadata:
name: deploy1
spec:
containers:
- name: deploy1
image: mongo
securityContext:
privileged: true
seLinuxOptions:
level: "s0:c123,c456"
nodeSelector:
id: ubuntu002
Notas: el contenido del fichero deploy1.yaml forzará la ejecución de un pod

basado en la imagen mongo en el nodo que tenga como id el valor ubuntu002. En
- 95 -
caso de no tener preferencias sobre el nodo en el que ejecutar el pod las dos últimas
líneas pueden ser eliminadas o comentadas en el fichero. Por otro lado, las cuatro
líneas marcadas en negrita en el fichero permiten que el pod se ejecute con todos los
permisos sobre el contenedor (permitiendo escalamientos a súper usuarios, acceso
al kernel…)
Posteriormente crear el recurso con “kubectl create -f
ejemplo_deploy1.yaml”
Para el despliegue de un deployment multipod, crear un fichero con el
siguiente contenido:
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd1
spec:
selector:
matchLabels:
app: httpd
replicas: 100 # número de réplicas
template: # Crear el deployment a partir de plantilla
metadata:
labels:
app: httpd
spec:
containers:
- name: httpd
image: httpd
ports:
- containerPort: 80
# nodeSelector:
# id: ubuntu002
Posteriormente crear el recurso con “kubectl create -f <NOMBRE-

FICHERO>.yaml”
De forma rápida y sencilla, puede desplegarse un pod en un nodo específico
fácilmente con el siguiente comando: “kubectl run mongo --
image=mongo:latest --restart=Never --overrides='{
"apiVersion": "v1", "spec": { "nodeSelector": { "id":
"ubuntu001" } } }'”
Siendo id una etiqueta establecida con el comando “kubectl label …”
referenciado anteriormente.
- 96 -
KUBERNETES
Clúster Kubernetes
A continuación se recogen los pasos necesarios para la puesta en marcha del
clúster definido en el apartado 4.2.3, formado por los nodos de la tabla 11:
Tabla 11: nodos clúster Kubernetes
Nodo Rol
GREDOS Master
Leon Worker
ubuntu001 Worker
ubuntu002 Worker
ubuntu003 Worker
Los pasos son los siguientes:

1. Inicializar el nodo master:
sudo kubeadm init --apiserver-advertise-
address=138.100.49.16
Es normal que este proceso tarde un poco tiempo, en función de la

velocidad de procesamiento y la conexión de red, pues durante este
proceso el nodo master se descarga una serie de imágenes y pone en
marcha el clúster.
La salida de dicho comando también proporciona el comando que hay que
ejecutar en los demás nodos del clúster. Puede ser anotado u obtenido en
cualquier momento con el siguiente comando:
sudo kubeadm token create --print-join-command
2. Como sugiere el mensaje obtenido tras ejecutar el comando del primer paso, con
el fin de poder gestionar el clúster sin necesidad de ser el usuario administrador
ejecutar los siguientes comandos:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
3. Como se estudió en el capítulo del marco tecnológico, existen varias alternativas

para escoger un pod de red. A modo recordatorio, el pod de red es un
componente que se debe desplegar antes que las aplicaciones y que permitirá la
comunicación entre pods. Para este ejemplo se escogerá el proveedor Weave. Se
activa con el siguiente comando:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-
version=$(kubectl version | base64 | tr -d '\n')"
4. Una vez aplicada la configuración de Weave es necesario completar la instalación

con:
sudo curl -L git.io/weave -o /usr/local/bin/weave
sudo chmod a+x /usr/local/bin/weave
- 97 -
En este punto deben estar en ejecución una serie de pods en el nodo
master, son: etcd (almacenamiento), administración y api (apiserver y
controller), dns, proxy, scheduler (planificador) y el componente de red
instalado en los pasos 3 y 4. Véase figura 66.
Figura 65: listado de pods Kubernetes
5. Si no se desea montar la parte de interfaz gráfica de Kubernetes continuar con el

paso 6.
5.1. Aplicar configuración de interfaz gráfica y generar el pod adecuado
ejecutando el siguiente comando:
kubectl create -f
https://raw.githubusercontent.com/kubernetes/dashboard/mas
ter/src/deploy/recommended/kubernetes-dashboard.yaml
5.2. Generar el fichero “dashboard-admin.yaml” con el siguiente contenido:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-system
5.3. Se crea el recurso haciendo uso del fichero del paso 5.2:
kubectl create -f dashboard-admin.yaml
5.4. Por último es necesario lanzar un proxy en forma de pod que escuche en
nuestra dirección IP y en el puerto 443 y nos permita acceder a la consola
gráfica:
sudo nohup kubectl proxy --address="138.100.49.16" -p 443 -
-accept-hosts='^*$' &
En este punto ya está lista la interfaz gráfica. Aparte de los pods que se
muestran en la figura 65, debe aparecer uno nuevo en ejecución del dashboard.
- 98 -
KUBERNETES
La interfaz gráfica será accesible a través de la siguiente URL:
y su contenido se muestra en la figura 67.
Figura 66: interfaz gráfica Kubernetes
6. Añadir tantos nodos como se desee con el comando obtenido en el paso 1. Si

necesita volver a generarse otro comando con otro token, puede hacerse con:
Una vez se han añadido los nodos, se puede comprobar el estado del clúster
con “kubectl get nodes” como se muestra en las figuras 68 y 69.
Figura 67: listado de nodos CLI Kubernetes
- 99 -
Figura 68: listado de nodos gráfico Kubernetes
El próximo paso sería ejecutar una aplicación multicontenedor en el clúster.

Antes de hacerlo, cabe mencionar que por consideraciones de seguridad Kubernetes
no permite ejecutar pods del clúster en el nodo master. En caso de querer poder
desplegar pods en dicho nodo, se puede habilitar ejecutando el siguiente comando:
kubectl taint nodes --all node-role.kubernetes.io/master-
- 100 -
KUBERNETES
Clúster Kubernetes multiarquitectura

A continuación se recogen los pasos a seguir para conseguir montar un clúster
multiarquitectura con Kubernetes [52]. Los nodos que se añadirán son:
Tabla 12: nodos clúster multiarquitectura k8s
Nodo Rol Arquitectura

GREDOS Master x86_64
Leon Worker x86_64
raspberrypi02 Worker armv7l
ubuntu001 Worker x86_64
La inicialización del clúster es la misma que la recogida en el anexo anterior,

así que han de realizarse los cinco primeros pasos, y después seguir con este anexo.
Una vez inicializado el clúster con los cinco primeros pasos del anexo
anterior, ese necesario hacer una serie de modificaciones en el entorno con el fin de
conseguir que cada nodo sea capaz de obtener y ejecutar los pods creados para su
arquitectura. Para ello, se va a ampliar la configuración del kube-proxy con el
objetivo de diferenciar internamente las arquitecturas de los nodos para que estos
puedan ejecutar los pods del clúster. Los pasos a seguir son:
1. Editar el DaemonSet del proxy ejecutando el siguiente comando:
kubectl edit daemonset kube-proxy --namespace=kube-system
Se abrirá un editor de texto con el fichero de configuración del kube-

proxy, al que hay que añadir, después de la línea “hostNetwork: true”
y bajo la siguiente estructura “spec: template: spec:”el siguiente
contenido:
nodeSelector:
beta.kubernetes.io/arch: amd64
A continuación se muestra un extracto del fichero editado, con los

números de línea:
…
48 dnsPolicy: ClusterFirst
49 hostNetwork: true
 50 nodeSelector:
 51 beta.kubernetes.io/arch: amd64
52 restartPolicy: Always
53 schedulerName: default-scheduler
54 securityContext: {}
…
El fichero, con las dos líneas añadidas, debe guardarse con el nombre
“daemonset-arm.yaml”. Por ejemplo, si se edita con el editor vi y se
desea guardar en “/home/Daniel/daemonset-arm.yaml” el
- 101 -
comando de guardado será “:x /home/Daniel/daemonset-
arm.yaml”
2. Ahora será necesario editar el fichero “daemonset-arm.yaml” con el
fin de adaptarlo a la arquitectura arm. Con el fin de hacer más fácil la
edición del fichero a continuación se plasmará el contenido completo del
mismo, indicando las líneas que se añaden con el carácter ‘’ y las que se
eliminan con el carácter ‘’.
# Please edit the object below. Lines beginning with a '#'
will be ignored,
# and an empty file will abort the edit. If an error occurs
while saving this file will be
# reopened with the relevant failures.
#
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
 creationTimestamp: 2018-06-14T18:34:07Z
 generation: 1
labels:
k8s-app: kube-proxy
 name: kube-proxy
 name: kube-proxy-arm
namespace: kube-system
 resourceVersion: "339"
 selfLink: /apis/.../.../.../
 uid: 85bb52a1-7001-11e8-a165-309c23228a8c
spec:
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kube-proxy
template:
metadata:
creationTimestamp: null
labels:
k8s-app: kube-proxy
spec:
containers:
- command:
- /usr/local/bin/kube-proxy
- --config=/var/lib/kube-proxy/config.conf
 image: k8s.gcr.io/kube-proxy-amd64:v1.10.4
 image: k8s.gcr.io/kube-proxy-arm:v1.10.4
imagePullPolicy: IfNotPresent
name: kube-proxy
resources: {}
securityContext:
privileged: true
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
- 102 -
KUBERNETES
volumeMounts:
- mountPath: /var/lib/kube-proxy
name: kube-proxy
- mountPath: /run/xtables.lock
name: xtables-lock
- mountPath: /lib/modules
name: lib-modules
readOnly: true
dnsPolicy: ClusterFirst
hostNetwork: true
nodeSelector:
 beta.kubernetes.io/arch: amd64
 beta.kubernetes.io/arch: arm
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: kube-proxy
serviceAccountName: kube-proxy
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
- effect: NoSchedule
key: node.../uninitialized
value: "true"
volumes:
- configMap:
defaultMode: 420
name: kube-proxy
name: kube-proxy
- hostPath:
path: /run/xtables.lock
type: FileOrCreate
name: xtables-lock
- hostPath:
path: /lib/modules
type: ""
name: lib-modules
templateGeneration: 1
updateStrategy:
rollingUpdate:
maxUnavailable: 1
type: RollingUpdate
status:
 currentNumberScheduled: 1
 desiredNumberScheduled: 1
 numberAvailable: 1
 numberMisscheduled: 0
 numberReady: 1
 observedGeneration: 1
 updatedNumberScheduled: 1
- 103 -
3. Por último, es necesario aplicar los cambios establecidos en el fichero con
el comando:
kubectl create -f daemonset-arm.yaml
4. Añadir tantos nodos como se desee con el comando obtenido en el paso 1.

Si necesita volver a generarse otro comando con otro token, puede hacerse
con:
Una vez se han añadido los nodos, se puede comprobar el estado del
clúster con “kubectl get nodes” como se muestra en la figura 57.
Figura 69: nodos multiarquitectura en Kubernetes
Como se indicó en el capítulo de estado del arte, con este procedimiento se

consigue formar un clúster multiarquitectura con Kubernetes y desplegar servicios
en el clúster logrando que cada nodo del clúster lance los pods de su arquitectura.
Sin embargo, en nuestro entorno existe una peculiaridad: debido a las
limitaciones de hardware del nodo raspberrypi02 no se ha conseguido alcanzar
estabilidad en el clúster, de forma que dicho nodo se reinicia una vez transcurre un
determinado tiempo debido al agotamiento de memoria y la incapacidad de hacer
uso del swap por ser requisito de la plataforma.
- 104 -
KUBERNETES
Desactivar swap
Uno de los requisitos de Kubernetes es desactivar el swap en todos los nodos.
Antes de comenzar con los pasos de desactivación conviene hacer una pequeña
introducción sobre qué es el swap y qué aporta.
Uno de los componentes hardware de un ordenador es la memoria RAM, una
memoria de acceso aleatorio que permite almacenar los datos y el código máquina
de los programas y procesos en ejecución. Se trata de una memoria volátil y limitada
que permite lectura y escritura de forma generalmente muy rápida.
El swap o espacio de intercambio se utiliza cuando la cantidad de memoria
RAM está llena. Si el sistema operativo necesita más recursos de memoria y la RAM
está ocupada al completo, las páginas de memoria inactivas serán movidas al espacio
de intercambio. Aunque el espacio swap puede ser muy útil para aquellos equipos
que disponen de muy poca memoria RAM, no debe ser considerado como un
reemplazo de la misma ya que el espacio de intercambio reside en los discos duros
y tiene un tiempo de lectura y escritura mucho mayor que el de la memoria RAM.
Tradicionalmente, se considera que el espacio de las particiones de swap debe
ser el doble de la memoria física en aquellos sistemas que tienen hasta 2 GB de RAM,
y el tamaño de la memoria física para aquellos sistemas con más de 2 GB de RAM.
En los sistemas Linux se puede comprobar el espacio de swap asignado y
usado con el comando free.
daniel@GREDOS:~$ free -h
total used free shared buff/cache available
Mem: 31G 7,1G 10G 110M 13G 23G
Swap: 31G 0B 31G
Los pasos para la desactivación del swap son los siguientes:

1. Añadir la siguiente línea:
Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
Al final del fichero:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf
2. Reiniciar los servicios con los siguientes comandos:

sudo systemctl daemon-reload
sudo systemctl restart kubelet
3. Por último poner el comando de desactivación de swap.

sudo swapoff -a
- 105 -
- 106 -
CREACIÓN Y DESPLIEGUE DE UN FIREWALL
E. CREACIÓN Y DESPLIEGUE DE UN FIREWALL

Para el desarrollo del proyecto y la prueba de concepto se ha creado un
contenedor en el que se despliega una función de red muy común, un firewall. Se
trata de una solución basada en iptables19 que proporciona una interfaz web para la
gestión completa de objetos, reglas, estadísticas, interfaces y análisis de tráfico.
A continuación se muestran una serie de capturas que ilustran su
funcionamiento.
La figura 57 muestra la interfaz principal del firewall. En ella aparecen una
serie de gráficos que muestran el tráfico que se recibe y se transmite por cada una
de las interfaces de red del firewall, el tráfico que cumple cada una de las reglas (de
entrada, de salida y tráfico reenviado) y un gráfico comparativo que muestra el
tráfico total de entrada, salida y reenviado:
Figura 70: interfaz principal del firewall
19 Iptables es un firewall integrado en el kernel de Linux que permite la definición de reglas
en base a tablas.
- 107 -
En la figura 58 se muestra un listado de todas las interfaces de red del firewall
en modo tabla. Si se hace clic en alguna de las filas se mostrará el tráfico que se ha
recibido y enviado por esa interfaz.
Figura 71: listado de interfaces del firewall
Con el fin de hacer más sencilla la gestión y definición de reglas se ha

habilitado una sección de objetos que permite definir hosts y redes sobre los que
aplicar las reglas. Véase figura 59.
Figura 72: listado de objetos del firewall

- 108 -
CREACIÓN Y DESPLIEGUE DE UN FIREWALL
A continuación, en la figura 60 se muestra un listado de reglas definidas:
Figura 73: listado de reglas del firewall
Las reglas pueden ser creadas de forma muy sencilla, como se muestra en la
figura 61.
Figura 74: creación de regla en el firewall
- 109 -
Por último, como se muestra en la figura 62, existe la posibilidad de hacer
nateo de puertos y redireccionar el tráfico.
Figura 75: listado reglas NAT en el firewall
El firewall virtual desplegado se corresponde con el de la figura 76,

compuesto por 6 interfaces de red en las que cinco de ellas se corresponden a redes
internas y una a la externa.
Figura 76: mapa red FW
- 110 -
ARQUITECTURA OPENSTACK
F. ARQUITECTURA OPENSTACK
Figura 77: arquitectura lógica OpenStack

- 111 -
- 112 -
INSTALACIÓN DEVSTACK
G. INSTALACIÓN DEVSTACK
A continuación se recogen los pasos de instalación de DevStack, una versión
pensada de OpenStack para desarrolladores que se instala a través de un conjunto
de scripts de forma rápida y sencilla.
Pasos:
1. Crear el usuario stack con el que se instalará y gestionará la plataforma
sudo useradd -s /bin/bash -d /opt/stack -m stack
2. Dar privilegios al usuario para que se pueda completar la instalación

echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee
/etc/sudoers.d/stack
3. Entrar como usuario stack

sudo su - stack
4. Descargar DevStack
git clone https://git.openstack.org/openstack-
dev/devstack
5. Crear el fichero de configuración de OpenStack. En su forma más

sencilla es suficiente con proveer la contraseña de administración,
base de datos, rabbit y servicios. Editar el fichero ~/local.conf y
añadir el siguiente contenido
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
6. Arrancar la instalación. Puede tardar más de 20 minutos.

./stack.sh
Una vez finalizada la instalación se dispondrá de una versión con keystone

(servicio de identidad), glance (servicio de imágenes), nova (computación), cinder
(almacenamiento de bloques), neutron (gestión de networking) y horizon
(componente gráfic0).
Si se desea, por ejemplo, poder gestionar y controlar el despliegue de
contenedores en OpenStack pueden instalarse de forma adicional los siguientes
componentes: magnum (orquestación de contenedores), heat (orquestación),
barbican (gestión de claves), zun (servicio de contenedores) y kuryr (plugin de
contenedores). Para ello, modificar el fichero referenciado en el paso 5 y añadir el
siguiente contenido:
[[local|localrc]]
DATABASE_PASSWORD=password
- 113 -
RABBIT_PASSWORD=password
SERVICE_TOKEN=password
SERVICE_PASSWORD=password
ADMIN_PASSWORD=password
enable_plugin barbican https://git.openstack.org/openstack/barbican

enable_plugin heat https://git.openstack.org/openstack/heat
enable_plugin magnum https://git.openstack.org/openstack/magnum
enable_plugin magnum-ui https://github.com/openstack/magnum-ui
VOLUME_BACKING_FILE_SIZE=20G
enable_plugin devstack-plugin-container
https://git.openstack.org/openstack/devstack-plugin-container
enable_plugin zun https://git.openstack.org/openstack/zun
enable_plugin kuryr-libnetwork
https://git.openstack.org/openstack/kuryrlibnetwork
enable_plugin zun-ui https://git.openstack.org/openstack/zun-ui
En este punto se dispondrá de una versión personalizada de DevStack que

contendrá los componentes citados anteriormente para la gestión de contenedores.
Figura 78: gestión de instancias en DevStack
Figura 79: gestión de contenedores en DevStack
- 114 -
INSTALACIÓN DEVSTACK
A continuación en las figuras 65 y 66 se muestra la creación y ejecución de un

contenedor:
Figura 80: ejemplo contenedor en DevStack I
Figura 81: ejemplo contenedor en DevStack II
- 115 -

TFG Daniel Moreno Belinchon

Cargado por

Copyright:

Formatos disponibles

TFG Daniel Moreno Belinchon

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Daniel Moreno Belinchon

Cargado por

Copyright:

Formatos disponibles

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

PROYECTO FIN DE GRADO

TÍTULO: DESPLIEGUE DE MICROSERVICIOS MEDIANTE TÉCNICAS DE

TUTOR: D. ANTONIO DA SILVA FARIÑA

DEPARTAMENTO: INGENIERÍA TELEMÁTICA Y ELECTRÓNICA

MIEMBROS DEL TRIBUNAL CALIFICADOR:

PRESIDENTE: D.ª MARÍA PILAR OCHOA PÉREZ

FECHA DE LECTURA: DE DE 2018

Daniel Moreno Belinchón

Figura 1: evolución a arquitecturas de microservicios

Por otro lado, NFV proporciona la capacidad de virtualizar componentes y

El capítulo tres recoge una serie de consideraciones de diseño que han

2. ANTECEDENTES Y MARCO TECNOLÓGICO

Figura 2: tipos de servicios en la nube

Figura 3: nube pública

 Privadas: cuando los recursos ofrecidos no son accesibles para todo el

Figura 4: nube privada

 Híbridas: cuando se combinan ambos tipos para obtener un tipo de nube

Figura 5: nube híbrida

Figura 6: implementaciones de SOA

1 OMG es un consorcio fundado en 1989 dedicado al cuidado y establecimiento de estándares

Las arquitecturas basadas en microservicios plantean la distribución de

Figura 8: monolito VS microservicios

Aunque se trata de una arquitectura que está de moda y parece muy

puede leer uno de los principios de Unix y posteriormente de las arquitecturas

Figura 9: extracto de The Bell System Technical Journal

Aunque no hay un patrón estrictamente definido para las arquitecturas

Ley de Conway [15]: “Any organization that designs a system (defined

Figura 11: equipos multidisciplinares

En consecuencia se dispondrá de equipos multidisciplinares que serán capaces de

Sin embargo, con las arquitecturas basadas en microservicios se pretende que

Figura 12: aplicación descentralizada

Figura 13: descentralización de datos

2 Continuous delivery o entrega continua es un mecanismo de ingeniería de software basado

en el desarrollo en ciclos cortos que permite la liberación de software en cualquier momento.

entornos es muy importante monitorizar continuamente el servicio con el fin de

Aspecto Arquitectura monolítica Arquitectura de microservicios

Figura 14: comparación monolito y microservicios

Teniendo en cuenta los aspectos principales -como agilidad, independencia y

Figura 15: arquitectura sin contenedores

Por otro lado, con el fin de conseguir aislamiento entre procesos y

Figura 16: virtualización VS contenedores

Existen varias técnicas que nos permiten hacer uso de contenedores:

Figura 17: histórico descargas Docker

Debido a las características y ventajas que presenta Docker, este trabajo se

 Registro Docker: repositorio de imágenes, público o privado, en el que

3 Docker Hub accesible a través de https://hub.docker.com/

Figura 18: arquitectura típica Docker

 Clúster: conjunto o agrupación de nodos físicos o virtuales que

 Balanceo de carga: técnica basada en distribuir el flujo de trabajo y/o

Figura 19: arquitectura Docker Swarm

5 Framework: framework es un entorno de trabajo que reúne conceptos, prácticas y criterios

para enfrentarse y resolver ciertos problemas

 Gestión de servicios: permite configurar detalladamente los

Figura 20: interfaz Portainer

Figura 22: interfaz Docker-swarm-visualizer

6 Demonio: programa que se ejecuta en segundo plano y carece de interfaces e interacción

ejecución de tareas de forma periódica y puntual.