Container Basics – Container Management and Application

Container Management and Application

The container technology has been widely applied in microservices and cloud computing not only because it is lightweight but also owing to such important factors as flexible and agile management as well as orchestration system support.

  1. Container Management

Clustering, flexibility, and agility characterize container application. How to effectively manage container clusters constitutes an important aspect of container technology implementation and application. Cluster management tools (orchestration tools) enable users to launch containers in clusters and help implement network interconnection besides providing load balancing capabilities and such assurances as extensibility, error tolerance, and high availability (HA). Examples of container cluster management tools that have currently drawn wide attention and seen extensive application include Kubernetes, Apache Mesos, Docker Swarm, and Docker Compose.

  • Kubernetes

Kubernetes[I] is an open-source distributed container management platform launched by Google based on its internal large-scale cluster management system Borg. It is also known as K8S, an abbreviation derived by replacing the eight letters “ubernete” with “8”. Kubernetes delivers cluster management capabilities, multitenancy application support, transparent service registration and discovery mechanism, and load balancing, fault discovery, and self-healing capabilities.

The following figure shows the Kubernetes architecture, which is composed of one or more masters and one or more nodes.

Figure 2.13 Kubernetes architecture

A master consists of multiple important components, for example, Etcd for storage, Scheduler for scheduling, HA component Controller Manager for cluster control, and API server for cluster coordination for external communication.

A node consists of two important components: kubelet that manages the lifecycle of pods in clusters and kube-proxy that is responsible for network configuration on Kubernetes.

Kubernetes contains the following critical operation units:

  • Pod: the smallest unit that runs applications or services on Kubernetes. It is designed to provide support for multiple containers in a pod to share a network address and file system.
  • Service: a proxy abstraction service for access to pods, mainly used for service discovery and load balancing within the cluster.
  • Replication Set: scales the number of pod replicas.
  • Scheduler: scheduling controller for resource objects in the cluster.
  • Controller Manager: manages and synchronizes resource objects in the cluster.
  • Etcd: distributed key/value pair (k, v) storage service to store status information of the entire cluster.
  • Kubelet: pod lifecycle event generator.
  • Labels: key/value pairs that are attached to objects to specify identifying attributes of objects.
  • Deployment: pod object manager that integrates go-live deployment, rolling update, replica creation, go-live task suspension/restoration, and rollback functions.
  • Volumes: directories that store data. At the time of container launch, the specified parameters are automatically mounted within the container. Volumes can be static and dynamic, with different lifecycles.
  • Stateful Set: Generally, a newly created pod is stateless, resulting in the failure to find the previously mounted volume after the pod hangs and is restarted. To resolve this issue, the Stateful Set is used to retain the pod status.

The workflow of a Kubernetes pod is described as follows:

(1) Submit a request.

A user submits a YAML file to the API server, requesting creation of a pod. The YAML file contains details about this pod, including the number of replicas, images, labels, names, and exposure of ports. Upon receipt of such a request, the API server saves spec data in the YAML file to Etcd.

(2) Allocate resources.

The scheduler regularly listens for resource changes (that is, for pods created in the first step, which are waiting for allocation) in the Etcd database through the watch interface of the API server. When detecting a new pod, the scheduler selects an eligible node according to the scheduling policy, binds the pod to this node, and at the same time updates pod allocation information in the Etcd database.

(3) Create containers.

Kubelet on the target node detects new pod allocation information in the Etcd database through the watch interface of the API server. Then it passes data of this pod to the container runtime for handling of the lifecycle of the pod. Later, Kubelet obtains pod status information from the container runtime and sends the updated status information to Etcd via the API server.

(4) Synchronize the resource status.

To ensure that this pod runs properly on the node (a pod may be killed for particular reasons), the Replication Set component in the Controller Manager regularly listens for the latest status of the pod in Etcd through the API server before synchronizing the number of replicas in this pod. In this manner, the number of running replicas is always the same as that of replicas specified by the user.

Figure 2.14 Kubernetes’s pod creation flowchart

  • Apache Mesos

Apache Mesos[II] originated from an open-source project of UC Berkeley for abstracting and managing cluster resources and later has been widely used at Twitter. Mesos abstracts, manages, and schedules resources across the data center. With functionality similar to a host operating system, it enables multiple applications to run in a cluster and share resources.

The following figure shows the Mesos architecture, which consists of one or more master nodes, one or more slave nodes, and a number of framework applications.

Figure 2.14 Architecture of Apache Mesos

The master node is responsible for managing frameworks and slave nodes and allocating resources on slave nodes to associated frameworks. The slave node manages local task assignments. The framework is an external computing application that is hot-swappable. Common frameworks include Marathon, Hadoop, and MPI. After registration, frameworks can connect to Mesos for unified management and resource allocation.

A framework mainly has two components: scheduler and executor. The scheduler interacts with the master node and schedules tasks to slave nodes according to the availability of resources. The executor obtains variables from the framework and executes tasks on slave nodes.

The workflow of Mesos is described as follows:

(1) Aggregate resource information.

The slave node uploads information about available resources on itself to the master node, which, as a resource pool, maintains collected resource information.

(2) Assign tasks.

The master node allocates available resources to the framework scheduler of an application. The scheduler checks whether such resources are eligible to support task execution and, if not, notifies the master node that it rejects the allocated resources (in this case, the master node allocates the resources to other frameworks); if yes, accepts such resources.

(3) Dispatch tasks.

The framework scheduler dispatches the task to the master node, which accepts it and uses the executor to run the application on the slave node.

  • Docker Swarm

Docker Swarm[III] is a container management tool launched by Docker in December 2014. With quite simple functions, it is mainly used to manage Docker clusters, exposing the latter to users as a virtual whole.

Docker Swarm, as a component of Docker, shows its biggest advantage in the integration of its own API into the Docker API, making it easy for developers to integrate Docker applications with Docker Swarm. Currently, Rackspace and other platforms have adopted Docker Swarm. Users also find it easy to use Docker Swarm on public cloud platforms such as Amazon Web Services (AWS).

Docker Swarm consists of manager and worker nodes, as shown in Figure 2.15. The manager node receives user requests and assigns tasks to worker nodes. In addition, it can also perform duties of worker nodes. Worker nodes receive and execute tasks scheduled by the manager node.

Figure 2.15 Architecture of Docker Swarm

All nodes have basic Docker execution components, namely Docker daemon and load balancer, which provide an environment for the running of containers. Some important components for master and slave nodes are listed as follows:

  • Master node: Manager CLI (Swarm command-line tool), Scheduler, and discovery service
  • Slave node: Swarm Agent
  • Service discovery component: The physical and communication environment in the cluster is complicated, resulting in inaccurate prediction of service interruption. This component provides service assurance for the cluster. When a slave node is down, the service discovery component can immediately detect it and instructs the scheduler to restore the failed service on another node.

The workflow of Docker Swarm is described as follows:

(1) Cluster operation

A user uses the Manager CLI of the master node to plan application deployment.

(2) Application distribution

The scheduler distributes the application within the cluster. The Swarm Agent is responsible for communication between nodes in the cluster.

(3) Service HA

Docker Swarm uses the service discovery component to maintain information about applications running on slave nodes, ensuring that the number of stably running applications in the cluster meets the related requirement to achieve HA of services.

  • Docker Compose

Compose[IV] is another orchestration tool launched by Docker for users to define and deploy application services. Note that Compose only supports deployment of applications on a single node. If orchestration is required for a cluster, the Docker Swarm should be used to deploy applications in a cluster.

  • Comparative Analysis of Tools

This section provides a comparative analysis of Kubernetes, Apache Mesos, Docker Swarm, and Docker Compose projects on GitHub in terms of their activity. The analysis result, to some extent, reflects the open-source community’s interest in and support for the four orchestration tools.

From such indicators as pull requests, issues, commits, branches, releases, contributors, watch, star, and fork, developers are obviously most interested in Kubernetes, followed by Apache Mesos, Docker Swarm, and Docker Compose.

In terms of releases, Kubernetes and Apache Mesos both have a large number of iterations in the aggregate, followed by Docker Compose and Docker Swarm. From a combined view of the interest in projects and the aggregate number of iterations, it can be seen that Kubernetes and Docker Mesos are at the first tier of orchestration tools. By contrast, Docker Swarm and Docker Compose are at the second tier due to less attention paid to them.

Figure 2.16 Comparison of container orchestration tools on GitHub in activity[1]

Besides the preceding tools, Rancher[V] and Docker Machine[VI] are also common container cluster management tools. Of course, different tools have different functions to address different needs. Thanks to the rapid development of these cluster management tools, the container technology becomes increasingly easy to be accepted and adopted by users at the stages of production and implementation.

  • Container Usage Scenarios

Like virtual machines, containers provide the isolation function, but with much less resource usage. In the past few years, it has seen more and more widespread application in a variety of scenarios.

According to A Survey on the Development of Open-Source Cloud Computing Technologies in China (2018)[VII] issued by the China Academy of Information and Communications Technology (CAICT), in 2017, 30.1% of enterprises adopted the container technology in their production environments, an increase of 6.8 percentage points compared with 2016, 36.3% of enterprises used containers in their test environments, and 24.5% of enterprises were evaluating the container technology. Insufficient technology penetration (43.7%), lack of success stories (41.4%), and security concerns (33.8%) are three major contributors to the low adoption rate of the container technology.

The survey also collected data about container usage scenarios and found that 57.9% of enterprises listed operation and maintenance (O&M) automation as the most common scenario involving the use of containers. Other usage scenarios include fast delivery at development and test stages (34%), multi-environment consistency management (31.25), continuous integration/continuous deployment (CI/CD, 29.4%), and microservices (22.7%).

This document identifies cloud computing, DevOps, microservices, and O&M automation as common usage scenarios of the container technology, which are briefly described and analyzed in the following sections.

  • Cloud Computing

Platform as a Service (PaaS) and Container as a Service (CaaS) are both service models of cloud computing, aimed at offering software R&D platforms or service infrastructure to users as a service. By virtue of its inherent advantages to DevOps and CI/CD, CaaS has gained momentum for rapid development.

Many cloud service providers, from Google, Microsoft, and Amazon outside of China to Huawei, Alibaba, and Tencent in China, include container services as part of their public clouds. Examples of such public clouds are Google Kubernetes Engine (GKE)[VIII], Microsoft’s Azure Kubernetes Service (AKS)[IX] and Azure Container Instances (ACI[X]), and Amazon’s Elastic Container Service (ECS[XI]) and Elastic Container Service for Kubernetes (EKS[XII]).

A 2017 RightScale report[XIII] found that, among all services offered by cloud service providers, Docker stole the limelight with presence in AWS ECS (35%), Azure container services (11%), and GKE (8%).

Enterprise-class PaaS cloud service providers in China include DaoCloud, Shurenyun, TenxCloud, and Alauda, which cooperate with governments and finance and telecom sectors, helping organizations build state-of-the-art cloud-native application platforms. Among these service providers, an overwhelming majority has chosen Docker as their container runtime engine.

  • DevOps

Currently, the development process of software systems usually consists of coding, unit testing, integration testing, and bug handling, as shown in Figure 2.17. Systems are becoming increasingly complicated, and so are dependencies between modules. In this context, many bugs fail to be discovered until project integration. Worse still, the longer away from the development stage, the higher cost you will pay for bug fixing.

Figure 2.17 Traditional software system development process

DevOps is an IT O&M-oriented end-to-end workflow based on IT automation and CI/CD to optimize development, testing, and O&M, among others.

DevOps is a new model that combines development with operations, with emphasis placed on communication and cooperation between development and O&M personnel. It features an automated process that makes software building, testing, and release more convenient, frequent, and reliable. In addition, DevOps shortens the wait time at each stage and reduces redundant and manual labor, thus significantly cutting down the problem resolving cost and becoming an effective solution to the aforementioned issues.

Figure 2.18 Closed loop of DevSecOps capabilities

One of the key metrics for measuring the success of DevOps is its role in improving the influence of development on operations. The container technology can play a critical role throughout the DevOps process. In practice, the development team should not think their work is complete by just delivering code to the operations team, but should also learn how code is executed in the production environment. For this purpose, they can leverage the container technology to release applications in the form of container images, which cover not only application code but also the entire stack of the basic operating system and dependent libraries. Furthermore, they may even configure a runtime environment. Such consistent deployment of applications reduces the operating expense (OPEX).

According to a 2017 RightScale report[35], over 84% of enterprises had an 80% adoption rate of DevOps; of all DevOps tools, Docker had an adoption rate of 35% and Kubernetes’s adoption rate also increased from 7% in 2016 to 14% in 2017.

  • Microservices

In a microservice architecture, an application is structured as a collection of loosely coupled modules that provide different services, each of which can be independently deployed, maintained, and expanded. Services communicate with one another through RESTful APIs.

In essence, microservices are designed to resolve more serious and practical problems with services of specific functionality and abstract capabilities. The biggest advantage of the microservice architecture lies in the lowered degree of coupling between modules. This means that each service can be developed and maintained by a separate team. Different services may even use different programming languages and architectures. As a result, each service can be implemented with the most suitable technique. All these contribute to an enhanced application development efficiency, a more clear structure, and reduced learning costs.

The following figure is an example of conversion from the monolithic architecture to the microservice architecture. The former couples the PHP service with modular functions, while the latter splits the application into different modules, providing an API for each isolatable module, to achieve the purpose of providing services via logical management of APIs.

Figure 2.19 Comparison of the monolithic architecture and microservice architecture

The core architecture of microservices consists of two components: API server and microservice applications. The API server, as the core of the entire microservice architecture, incorporates functions such as authentication, authorization, request logging, request log monitoring, and load balancing. Microservice applications can be packaged into containers to provide services through RESTful APIs within the system. Following is an example of the container-based microservice architecture.

Figure 2.20 Container-based microservice architecture

With the emergence of microservices come a variety of microservice architectures. Spring Cloud[2] and Dubbo[3] are typical examples of the first-generation architecture, which has been widely adopted and used in production environments owing to its stability. The second-generation architecture is a service mesh[4], which comes in various forms and typically represented by Linkerd[XIV] from Buoyant and Istio[XV] from the collaborative work of Google, IBM, and Lyft.

  • Fast Deployment and Delivery

The preceding sections dwell upon the advantages of containers in the implementation model and design. In fact, containers are good also in their support for fast deployment and delivery of complicated systems to cut down a lot of work on installation and configuration. Typically, infrastructure platforms such as OpenStack can be deployed using the container technology to deliver automated and agile O&M management.

Kolla[XVI] is an OpenStack project aimed at containerized deployment of all components. As we all know, it usually takes a lot of time and energy to install and deploy OpenStack. In reality, people always want to put more energy in service logic implementation rather than setup and deployment of the platform environment.

If Kolla is used to deploy OpenStack, after the operating system is installed, it takes only 10 minutes, give or take, to complete installation of an OpenStack system with various community functions. This containerized deployment is similar to block building. It makes all operations, from installation to upgrade, more graceful.

(To be continued)

[1] This is based on statistics as of July 31, 2018.

[2] Spring Cloud builds on Spring Boot to provide tools for developers to quickly build some of the common patterns in JVM-based cloud application development, including configuration management, service discovery, intelligent routing, and micro-proxy.

[3] Dubbo is a high-performance service framework open-sourced by Alibaba. Able to be seamlessly integrated with the Spring framework, Dubbo makes it possible for applications to output/input services through high-performance RPCs.

[4] A service mesh is an infrastructure layer for handling inter-service communication. In practice, the service mesh generally consists of a series of lightweight network proxies, which are deployed with applications and are transparent to the latter.

[I] Kubernetes, https://kubernetes.io/

[II] Apache Mesos, http://mesos.apache.org/

[III] Docker Swarm, https://github.com/docker/swarm

[IV] Docker Compose, https://github.com/docker/compose

[V] Rancher, https://rancher.com/

[VI] Docker Machine, https://github.com/docker/machine

[VII] A Survey on the Development of Open-Source Cloud Computing Technologies in China (2018), http://www.caict.ac.cn/kxyj/qwfb/ztbg/201804/t20180426_158539.htm

[VIII] Google Kubernetes Engine https://cloud.google.com/kubernetes-engine/

[IX] Azure Kubernetes Service https://azure.microsoft.com/en-us/services/container-service/

[X] Azure Container Instances https://azure.microsoft.com/en-us/services/container-instances/

[XI] Amazon Elastic Container Service https://amazonaws-china.com/cn/ecs/

[XII] Amazon Elastic Container Service for Kubernetes https://amazonaws-china.com/cn/eks/?nc2=h_m1

[XIII] 2017 State of the Cloud Report, https://www.rightscale.com/lp/2017-state-of-the-cloud-report

[XIV] Linkerd, https://linkerd.io/

[XV] Istio, https://github.com/istio

[XVI] Kolla, https://www.openstack.org/software/releases/queens/components/kolla

Leave a Reply

Your email address will not be published. Required fields are marked *