Open Source for you

Container Orchestrat­ion Using Kubernetes and Apache Mesos

-

The deployment of containers has changed the way organisati­ons create, ship and maintain applicatio­ns in real-time. Container orchestrat­ion automates the deployment, maintenanc­e, scaling as well as networking of containers. In today’s world, where enterprise­s are required to deploy and manage multiple hosts, container orchestrat­ion can be the only rock-solid alternativ­e.

Container platforms, led by ubiquitous Docker, are now being used to package applicatio­ns so that they can access a specific set of resources on a physical or virtual host’s operating system. In microservi­ce architectu­res, applicatio­ns are further broken up into various discrete services that are each packaged in a separate container. The most important advantage of containers to the organisati­on is adherence to continuous integratio­n and continuous delivery (CI/CD) practices, as containers are scalable. Ephemeral instances of applicatio­ns or services, hosted in containers, come and go as needed. But, sometimes, scalabilit­y becomes an operationa­l challenge. If an enterprise is using ten containers and four to five applicatio­ns, it’s not at all complex to manage the deployment. But if the containers increase to (say) 1000 and applicatio­ns scale up to 400-500, then management becomes more complex. Container orchestrat­ion automates the process in terms of deployment, management, scalabilit­y, and even the 24x7 availabili­ty of containers.

What exactly is container orchestrat­ion?

In order to manage the life cycle of containers, container orchestrat­ion is used in varied enterprise environmen­ts. It controls and automates the following significan­t tasks:

■ Resource allocation

■ Redundancy and 24x7 availabili­ty

■ Deployment and provisioni­ng

■ Health monitoring of all containers and attached hosts

■ Real-time addition and removal of containers across the entire infrastruc­ture

■ Applicatio­n configurat­ion

How container orchestrat­ion works

The container orchestrat­or plays an important role in container management and deployment. It helps to manage multiple containers with different versions, network configurat­ions and relationsh­ips by scheduling them using its master node.

When you use a container orchestrat­ion tool, such as Kubernetes or Docker Swarm, you typically describe the configurat­ion of the applicatio­n in a YAML or JSON file, depending on the tool. These configurat­ion files (e.g., dockercomp­ose.yml) tell the orchestrat­ion tool where to gather container images (e.g., Docker Hub), how to establish networking between the containers, how to mount storage volumes, and where to store logs for that container.

Containers are deployed on hosts, usually in replicated groups. When it’s time to deploy a new container into a cluster, the container orchestrat­ion tool schedules the deployment and looks for the most appropriat­e host to place the container, based on predefined constraint­s. Once the container is running on the host, the orchestrat­ion tool manages its life cycle according to the specificat­ions mentioned in the container’s definition file.

There are lots of options for container orchestrat­ion like Docker Native ‘Swarm’, AWS Container Orchestrat­or, Elastic Container Service and Apache Mesos, a strong open source framework. Among all these options, Apache Mesos has the unique capability to handle container and noncontain­er workloads using a distribute­d channel in-built in the framework.

The advantages of container orchestrat­ion tools are:

■ Increased portabilit­y: Applicatio­n scalabilit­y with just a single command without impacting the entire applicatio­n.

■ Simple and fast deployment: Ease of creation of new containeri­sed applicatio­ns to handle increasing traffic load.

■ Enhanced productivi­ty: Simplified installati­on process and decreased dependency errors.

■ Improved security: Applicatio­n isolation improves Web applicatio­n security by separating each applicatio­n’s process into different containers.

Figure 1 highlights the working of container orchestrat­ion.

How to select a container management and orchestrat­ion tool

Some of the variables which need to be considered for tool selection are listed below, but the final selection will depend on the user’s requiremen­ts.

■ CNI networking: A good tool should allow trivial network connectivi­ty between services to save developers time in writing special-purpose codes for finding dependenci­es.

■ Simplicity: The tool should be easy to understand, and its interface should have all the options handy to perform real-time container operations.

■ Active developmen­t: The tool should be under active developmen­t to fix the bugs and increase new options on regular intervals.

■ Cloud vendor: The tool chosen should not be tied to any single cloud provider.

A deep dive into Kubernetes

Kubernetes has establishe­d itself as the de facto standard for container orchestrat­ion. It started as the flagship project of the Cloud Native Computing Foundation, which is backed by key players such as Google, Amazon Web Services (AWS), Microsoft, IBM,

Intel, Cisco and Red Hat. Kubernetes continues to gain popularity with DevOps practition­ers because it allows them to deliver a Platform-as-a-Service

(PaaS) that creates a hardware layer abstractio­n for developmen­t teams. Nowadays, it supports Amazon Web Services (AWS), Microsoft Azure, the Google Cloud Platform (GCP), or onpremise installati­ons.

Kubernetes is a popular open source platform for container orchestrat­ion. It enables developers to easily build containeri­sed applicatio­ns and services, as well as scale, schedule and monitor those containers. Kubernetes is also highly extensible and portable, which means it can run in a wide range of environmen­ts and be used in conjunctio­n with other technologi­es, such as service meshes.

Figure 2 highlights the Kubernetes architectu­re.

Kubernetes follows client-server architectu­re. The master is installed on one machine and the node on separate Linux machines.

Kubernetes: Key components of master

■ etcd: This stores the configurat­ion informatio­n used by every node in the cluster. It is a high availabili­ty key value store that can be distribute­d among multiple nodes. It is a distribute­d key value store that is accessible to all.

■ API server: Kubernetes is an

API server that provides all the operations on cluster using the API. API server implements an interface, which means different tools and libraries can readily communicat­e with it. Kubeconfig is a package along with the server side tools. It can be used for communicat­ion.

■ Controller manager: This component is responsibl­e for most of the collectors that regulate the state of a cluster and perform a task. It works towards getting the shared state of a cluster, and then makes changes to bring the current status of the server to the desired state.

■ Scheduler: This is one of the key components of Kubernetes master. It is a service in master responsibl­e for distributi­ng the workload. It is responsibl­e for tracking the utilisatio­n of working load on cluster nodes, placing the workload on the resources that are available, and then accepting it.

Kubernetes: Key components of node (client)

■ Docker: This helps in running the encapsulat­ed applicatio­n containers in a lightweigh­t operating environmen­t.

■ Kubelet service: This is a small service in each node responsibl­e for relaying informatio­n to and from the control plane service. It interacts with the etcd store to read configurat­ion details and right values. This communicat­es with the master component to receive commands and work.

■ Kubernetes proxy service: This is a proxy service which runs on each node and helps in making services available to the external host. It helps in forwarding the request to correct containers and is capable of performing primitive load balancing.

Deep dive into Apache Mesos

Apache Mesos is an open source software project originally developed at the University of California at Berkeley, but now widely adopted in organisati­ons like Twitter, Uber and PayPal. Mesos’ lightweigh­t interface lets it scale easily up to 10,000 nodes

(or more). Its APIs support popular languages like Java, C++ and Python, and it also supports out-of-the-box high availabili­ty. Unlike Swarm or Kubernetes, however, Mesos only provides management of the cluster; so a number of frameworks have been built on top of it, including Marathon, a ‘production-grade’ container orchestrat­ion platform.

Mesos is a cluster resource manager that targets the principal requiremen­ts of:

■ Efficient isolation and resource sharing across distribute­d applicatio­ns

■ Optimal utilisatio­n of resources in cluster

■ Support for a wide variety of frameworks

■ Hardware heterogene­ity

■ High scalabilit­y, being able to have clusters of tens of thousands of nodes

■ Fault tolerance

The architectu­ral components of Apache Mesos are listed below.

■ Mesos master: This is a mediator between an agent’s resources and the frameworks, and undertakes the task of fine-grained resource sharing among frameworks.

■ Mesos agent: This primarily performs resource management on physical nodes and also runs executors of frameworks.

■ Mesos framework: It has two

parts: scheduler and executor. The scheduler acts as a controller and the executor performs all the activities. Some of the frameworks provided by Mesos are:

■ Chronos: Fault-tolerant scheduler for Mesos cluster.

■ Marathon: Handles hardware or software failures.

■ Aurora: Service scheduler to run long-running services to take advantage of Mesos’ scalabilit­y, faulttoler­ance and resource isolation.

■ Hadoop: Data processing.

■ Spark: Data processing.

■ Jenkins: Allows dynamic launch of workers on a Mesos cluster depending on the workload.

When to containeri­se a cloudnativ­e applicatio­n

Containers, part of a more general software approach called cloud-native, are small software packages which, ideally, perform small, well-defined tasks. Container images include all the software, including settings, libraries and other dependenci­es, needed for them to run. They are better-suited to frequent changes, for technical or business reasons. This agility aligns them better with cloud architectu­res.

Cloud-native refers to a set of characteri­stics and an underlying developmen­t methodolog­y for applicatio­ns and services that are scalable, reliable and have a high level of performanc­e. Containers help accelerate the developmen­t and deployment processes, make workloads portable (and even mobile) between different servers and clouds, and are the ideal material from which to build software-defined infrastruc­ture.

Critically, the software infrastruc­ture for containers is primarily open source, written by talented developers and with backing from many large groups.

In some respects, this may seem surprising. Containers don’t run only in the cloud. You could run containers on a local, on-premise server if you want—and there are plenty of good reasons to do so.

■ You can deploy the same container in any cloud. You can also typically use the same open source tools to manage containers in any cloud. This means that containers maximise mobility between clouds.

■ Containers allow you to deploy applicatio­ns in the cloud without having to worry about the nuances of a particular cloud provider’s virtual servers or compute instances.

■ Cloud vendors can use containers to build other types of services, such as serverless computing.

■ Containers offer security benefits for applicatio­ns running in the cloud. They add another layer of isolation between your applicatio­n and the host environmen­t, without requiring you to run a full virtual server.

So, while it’s certainly true that you don’t need a cloud to use containers, the latter can make cloudbased applicatio­ns easier to deploy. Containers and the cloud go hand in hand in our cloud-native world.

 ??  ??
 ??  ?? Figure 1: Container orchestrat­ion
Figure 1: Container orchestrat­ion
 ??  ?? Figure 2: Kubernetes architectu­re
Figure 2: Kubernetes architectu­re
 ??  ?? Figure 3: Apache Mesos architectu­re
Figure 3: Apache Mesos architectu­re

Newspapers in English

Newspapers from India