Container Management and Orchestration Implementations

mentations

Unlike systems based on ETSI’s MANO architecture, container orchestration tools are not typically designed with NFV as the primary use case. Rather, they are intended to help Cloud operators manage their infrastructure and to help developers deploy and scale services more easily. Since these are also important features required in a Fog scenario, they warrant consideration in this context too. Furthermore, because they have existed for longer and have a broader purpose, these projects are generally more mature offering more features and greater stability.

Kubernetes [107] is a container orchestration tool originally designed by Google to automate operation, scale, and deployment of containers across a cluster of machines. As well as deploying services, Kubernetes has a major focus on maintaining the services that it deploys, with policies for automatic scaling and failover. In order for a master to control the workers a client must be installed on each worker node. These software components are compatible with both ARM and x86 architectures. As of 2019, a sub-project under Kubernetes

named KubeEdge has been announced [106] that specifically aims to address

the challenges of applying Kubernetes to edge networks.

Swarm [63] is a native clustering tool for Docker which now comes packaged

with the Docker engine. It uses the Docker remote API to manage and run containers on multiple hosts. It also uses an agent on each host which is man- aged by a single Swarm manager. Swarms orchestration consists of clustering; it makes a group of Docker hosts appear as a single machine. Services are run from the manager machine and are served to the Swarm workers.

Fleet [83] is a cluster management tool from CoreOS that acts as a founda-

tion layer for other higher layer container orchestration solutions. Fleet is built upon the Linux init system, specifically systemd, which is responsible for ini- tialising and managing services. Fleet extends this functionality across a cluster of machines. In order to use Fleet, agents (the CoreOS operating system) must be installed on all hosts.

MESOS [12] is a cluster management tool that provides a distributed sys-

tems kernel abstraction: it clusters a group of servers and makes them appear as one. MESOS is designed to work at large scale with examples including thou- sands of hosts. Similar to Fleet, MESOS offers management of the lower layers, but also supports the higher layer orchestration through Platform-as-a-Service

(PaaS) solutions such as Mesosphere Marathon. To use MESOS there must be a master node, and agents must be installed on the workers.

Rancher [162] is a container management platform from Rancher Labs that

offers orchestration through a framework called Cattle. It is a fork from Swarm and thus offers similar orchestration capabilities. As well as this, Rancher sup- ports MESOS, Swarm, and Kubernetes.

Mirantis [127] Recently Mirantis have created MCP Edge [126] which specif-

ically aims at deploying from the core to the edge of the network. This aims to offer production grade cloud control over the edge of the network, providing the usual benefits such as system monitoring and support for CI/CD.

Some of these tools offer more complete solutions to NFV and orchestration than others. When considering which is appropriate, it is important to note that when using a complete solution, extending or adapting the design can be challenge. On the other hand, when using general or half-stack solutions, there is greater flexibility for the design of a new system and architecture. As the relative youth of NFV, most of these solutions are missing features required for deployment. One of theses being VNF forwarding graphs. Some have this in concept but production ready standardised implementations do not exist.

The OpenStack consortium has a work in progress solution of this [149] so they

may be waiting for that to be finished. On top of this, these orchestrators are typically designed with the notion that the resource is going to be physically homogeneous and networked similarly and thus are not well suited for Fog based environments.

2.4

Summary

This chapter has detailed background and related work around scalable network monitoring, NFV, and computing towards the edge. Several pieces of work have been identified on their relevance towards to the aim of this thesis. With the objective to design and verify a scalable and responsive monitoring system in mind, the current technologies of SDN NFV and Orchestration currently lack the features to fully achieve this. As a result further research in edge orchestration, scalablity, and monitoring is required before this thesis can be realised. This said, best practices and failures of past research can help in directing this work.

The technologies and research gaps have been highlighted that are required to realise scalable and monitoring responsive monitoring for the Cloud-to-Fog continuum. It is clear that work is required on advancing NFV service over- lays, edge VNF orchestration, SDN monitoring methodology, and connections between these technologies. Specifically, background and related work have detailed:

• The potential benefits of SDN, NFV, and Fog Computing for network

monitoring and remediation

• The lack of SDN monitoring frameworks that focus on scalability and

adaptability whilst still retaining monitoring capability

• The lack of standardised and usable solutions for traffic routing between

virtualisation and network infrastructures

• The limited research on the potential for scalablity and function of a

framework that considers monitoring across the network

Finally, the findings from this chapter including existing tools, standards, and observed successful practicalities from related research are considered in

the design and implementation of both the Siren and Tennison frameworks described in this thesis.

Chapter 3

Designing Responsive and

Scalable Network Monitoring

This chapter describes a design for a responsive and scalable network moni- toring systems. Initially, Section 3.1 goes into detail on why a new design is required, highlighting gaps in current systems, as well as advantages of emerg- ing technologies. Based on the motivations discussed, Sections 3.2 and 3.3 go into detail on the design requirements as well as design considerations, covering topics of SDN scalability, monitoring, and orchestration methodology.

In summary, this chapter details the motivations, requirements, design con- siderations, and architecture for components of a novel SDN network monitoring

system: Tennison, as well as a Cloud-to-Fog orchestration system: Siren.