Geo-distributed efficient deployment of containers with Kubernetes

Cloud Computing is an emerging technology that is used not only by developers but also by end-users. It has vital importance in the Information Technology (IT) industries as its future would create a great transition from conventional IT services. These days, containerization in cloud computing has become an important research area. The selection of container orchestration tools is one of the difficult tasks for the organizations involved in the management of the vast number of containers. These tools have their strengths, weaknesses, and functionalities which need to be considered. This paper presents a comparative analysis of the container orchestration tools. This analysis would help the professionals to decide whether they need an orchestrator bound to a single technology or an orchestrator which provides the independent solution. In this paper, four popular orchestration tools viz., Kubernetes, Docker Swarm, Mesos, and Redhat OpenShift are analyzed on various parameters viz., security, deployment, stability, scalability, cluster installation, and learning curve. We observed that Kubernetes has the best scheduling features whereas Docker Swarm is easy to use. We also found that Mesos has good scalability whereas OpenShift is a highly secure orchestration tool.

Compared to the traditional approach of using virtual machines as the basis for the development and deployment of applications running in Cloud-based infrastructures, container technology provides developers with a higher degree of portability and availability, allowing developers to build and deploy their applications in a much more efficient and flexible manner. A number of tools have been proposed to orchestrate complex applications comprising multiple containers requiring continuous monitoring and management actions to meet application-oriented and non-functional requirements. Different container orchestration tools provide different features that incur different overheads. As such, it is not always easy for developers to choose the orchestration tool that will best suit their needs. In this paper we compare the benefits and overheads incurred by the most popular open source container orchestration tools currently available, namely: Kubernetes and Docker in Swarm mode. We undertake a number of benchmarking exercises from well-known benchmarking tools to evaluate the performance overheads of container orchestration tools and identify their pros and cons more generally. The results show that the overall performance of Kubernetes is slightly worse than that of Docker in Swarm mode. However, Docker in Swarm mode is not as flexible or powerful as Kubernetes in more complex situations.

Internet of Things (IoT) is the developing technology that enables devices to communicate without human interaction. IoT utilizes cloud computing services to collect and process data for IoT devices and to manage the device remotely. Cloud computing is not efficient enough to handle the fast stream of data produced by the IoT, therefore scaling up IoT applications to meet demands of high peak becomes easier and highly automated in fog computing. Containers are mostly used as virtualization solutions for IoT in fog computing. It enables the execution of small microservices to large applications. However, the rise of many lightweight containers has resulted in new application architectures and fundamentally changing how applications are deployed and visualized. Due to this change, container orchestration tools were proposed. These tools allow users to coordinate and manage containers. However, container orchestration tools need to meet the requirements of IoT applications and constraints imposed on the nodes in fog. This paper presents a systematic literature review on the selection of orchestration tools for the efficient deployment of IoT applications in fog computing. Moreover, the performance of IoT applications must be considered by applying different metrics. This paper aims to propose potential research directions to address identified gaps in the selection of orchestration tools.

Modern developers typically run their workloads through cloud-native environments such as Docker and Kubernetes. Docker is a platform that runs and manages containers. With the birth of Docker, interest in containers and technology has grown. As one of the container orchestration tools that control and manage containers running on multiple hosts, Kubernetes has a very large share and is used by many cloud companies, making it the standard for practical container orchestration tools. Therefore, in this paper, by analyzing the Kubernetes event timeline, we present the future direction of Kubernetes and Docker, which are key tools in the cloud-native environment.

Containerization is a cutting-edge DevOps technology which unifies the IT operations and Development domains. In recent times, virtualization using Virtual Machines has become an overkill for its large overhead on systems. As a lightweight alternative, containerization offers containers that constitute a package of an application along with all its dependencies that is required for it to execute. Containerization platforms help in building containers from images. Docker is a widely popular containerization platform. Containerization Orchestration tools manage these containers. Kubernetes is the front-runner of the emerging market of container orchestration tools. These software work together seamlessly in order to successfully implement containerization both locally and on the cloud. In this paper, we aim to deploy the container orchestration tool Kubernetes on a local system with a Docker sample container. The purpose of this is to ensure that all the configurations and management needed for a Docker container is set successfully on the local system before it is deployed onto the cloud or on the premise. The on-premise deployment use case is very important in domains such as finance and healthcare where organizations hesitate to upload confidential information on to the cloud for security reasons but still require scaling of their applications.

The last five years can safely be termed a Kubernetes Tsunami in the IT world. Kubernetes has been around since 2014, and it conquered not only the service catalogs of the major cloud providers but also most data centers around the world. Looking at the statistics reveals that if you want to run workloads in containers at scale, there is actually no other container orchestration tool around. In a report from Red Hat from 2021 asking organizations which container orchestration tool they use, you would still see mention of things like Mesosphere and Docker Swarm, but without a notable share and only with news coverage talking about “end-of-life.”

The Cloud Computing paradigm promoted the outsourcing of IT infrastructure and enterprise applications paving the way to save costs of building and maintaining computing infrastructures on-premise. In this environment, scale up of applications to attend demands in high peaks become easier and highly automated. Virtualization was a key technology to enable these characteristics. Nowadays, Container technology became popular as an alternative to Virtual Machines, and is being widely applied, as a consequence, Orchestration tools are being extensively applied in the Cloud environment. Despite its success, when it comes to the Internet of Things (IoT), Cloud Computing falls short to meet several requirements. Fog Computing appear as a complimentary technology to the Cloud to deliver the missing requirements in the IoT scene. Managing services deployed in a Fog Environment is a complex task and infrastructure management and orchestration tools can make it seamless. In this paper, we evaluate how Containers can affect the overall performance of applications in Fog Nodes. We analyze different Container Orchestration tools and how they meet Fog requirements to run applications. We also propose a Container Orchestration Framework for Fog Computing infrastructures.

Resource management is the principal factor to fully utilize the potential of Edge/Fog computing to execute real-time and critical IoT applications. Although some resource management frameworks exist, the majority are not designed based on distributed containerized components. Hence, they are not suitable for highly distributed and heterogeneous computing environments. Containerized resource management frameworks such as FogBus2 enable efficient distribution of framework’s components alongside IoT applications’ components. However, the management, deployment, health check, and scalability of a large number of containers are challenging issues. To orchestrate a multitude of containers, several orchestration tools are developed. But, many of these orchestration tools are heavyweight and have a high overhead, especially for resource-limited Edge/Fog nodes. Thus, for hybrid computing environments, consisting of heterogeneous Edge/Fog and/or Cloud nodes, lightweight container orchestration tools are required to support both resource-limited resources at the Edge/Fog and resource-rich resources at the Cloud. Thus, in this paper, we propose a feasible approach to build a hybrid and lightweight cluster based on K3s, for the FogBus2 framework that offers containerized resource management framework. This work addresses the challenge of creating lightweight computing clusters in hybrid computing environments. It also proposes three design patterns for the deployment of the FogBus2 framework in hybrid environments, including (1) Host Network, (2) Proxy Server, and (3) Environment Variable. The performance evaluation shows that the proposed approach improves the response time of real-time IoT applications up to 29% with acceptable and low overhead.KeywordsEdge computingFog computingContainer orchestrationInternet of ThingsResource management framework

Fog computing (also known as edge computing) is a decentralized computing architecture that seeks to minimize service latency and average response time in IoT applications by providing compute and network services physically close to end-users. Fog environment consists of a network of fog nodes and IoT applications are composed of containerized microservices communicating with each other. Due to limited resources of fog nodes, it is often not possible to deploy all the containers of an application on a single fog node. Therefore, communicating containers need to be distributed on multiple fog nodes. Distribution and management of containerized IoT applications is always a critical issue to the system performance in a fog environment. Kubernetes, an open-source system, has grown into a container orchestration standard by simplifying the deployment and management of containerized applications. Despite the progress made by the academia and industry with respect to container management and the wide-scale acceptance of Kubernetes in cloud environments, container management in fog environment is still in the early stage in terms of research and practical deployment. This article aims to fill this gap by analyzing the expediency of Kubernetes container orchestration tool in the fog computing model. The paper also highlights limitations with the current Kubernetes approach and provide ideas for further research to adapt to the needs of the fog environment. Lastly, we provide experiments that demonstrate the feasibility and industrial practicality of deploying and managing containerized IoT applications in the fog computing environment.

Containers are becoming the de facto standard to package and deploy\napplications and micro-services in the cloud. Several cloud providers (e.g.,\nAmazon, Google, Microsoft) begin to offer native support on their\ninfrastructure by integrating container orchestration tools within their cloud\noffering. At the same time, the security guarantees that containers offer to\napplications remain questionable. Customers still need to trust their cloud\nprovider with respect to data and code integrity. The recent introduction by\nIntel of Software Guard Extensions (SGX) into the mass market offers an\nalternative to developers, who can now execute their code in a hardware-secured\nenvironment without trusting the cloud provider.\n This paper provides insights regarding the support of SGX inside Kubernetes,\nan industry-standard container orchestrator. We present our contributions\nacross the whole stack supporting execution of SGX-enabled containers. We\nprovide details regarding the architecture of the scheduler and its monitoring\nframework, the underlying operating system support and the required kernel\ndriver extensions. We evaluate our complete implementation on a private cluster\nusing the real-world Google Borg traces. Our experiments highlight the\nperformance trade-offs that will be encountered when deploying SGX-enabled\nmicro-services in the cloud.\n

With the exponential growth of the Internet of Things (IoT), edge computing is in the limelight for its ability to quickly and efficiently process numerous data generated by IoT devices. EdgeX Foundry is a representative open-source-based IoT gateway platform, providing various IoT protocol services and interoperability between them. However, due to the absence of container orchestration technology, such as automated deployment and dynamic resource management for application services, EdgeX Foundry has fundamental limitations of a potential edge computing platform. In this paper, we propose EdgeX over Kubernetes, which enables remote service deployment and autoscaling to application services by running EdgeX Foundry over Kubernetes, which is a product-grade container orchestration tool. Experimental evaluation results prove that the proposed platform increases manageability through the remote deployment of application services and improves the throughput of the system and service quality with real-time monitoring and autoscaling.

Edge computing paradigm has been proposed to support latency-sensitive applications such as Augmented Reality (AR)/ Virtual Reality(VR) and online gaming, by placing computing resources close to where they are most demanded, at the edge of the network. Many solutions have proposed to deploy virtual resources as close as possible to the consumers using virtual machines and containers. However, the most popular container orchestration tools, e.g., Docker Swarm and Kubernetes, do not take into account the locality aspect during deployment, resulting in poor location choices at the edge of the network. In this paper, we propose an edge deployment strategy to tackle the lack of locality awareness of the container orchestrator. In this strategy, the orchestrator collects information about latency and the real-time resource consumption from the current container deployments, providing a bird's-eye view of the most demanded locations and the best places for deployment to cover the largest number of clients. We evaluated the proposed model using 16 AWS regions across the globe and compared to the standard deployment strategies. The experimental results show our edge strategy reduces the average latency between serving container to the clients by up to 4 times compared to the standard deployment algorithms.

As cloud computing evolves, data center ad-ministrators increasingly rely on orchestration tools to manage the complexities of resource provisioning, application deployment, and system scaling. This paper presents a comparative analysis of orchestration tools designed for both virtual machines (VMs) and containers, which are the two predominant technologies for running ap-plications in modern data centers. We explore the core functionalities, advantages, and limitations of widely used orchestration platforms such as OpenStack, Chef, Ansible, Docker Swarm, Kubernetes, and Mesos. Focusing on con-tainer orchestration, which has gained prominence for its lightweight nature, we discuss the operational benefits of reduced overhead, faster deployment, and scalability. We also highlight the challenges in ensuring high availability, fault tolerance, and network resilience in distributed sys-tems using these tools. Furthermore, this study evaluates the trade-offs between VMs and containers in terms of performance, isolation, and resource utilization, offering guidance for data center managers and software engineers in selecting the optimal orchestration platform. The paper concludes with recommendations for future developments in orchestration technologies that can further optimize cloud infrastructure management.

Edge computing is a viable approach to improve service delivery and performance parameters by extending the cloud with resources placed closer to a given service environment. Numerous research papers in the literature have already identified the key benefits of this architectural approach. However, most results are based on simulations performed in closed network environments. This paper aims to analyze the existing implementations of processing environments containing edge resources, taking into account the targeted quality of service (QoS) parameters and the utilized orchestration platforms. Based on this analysis, the most popular edge orchestration platforms are evaluated in terms of their workflow that allows the inclusion of remote devices in the processing environment and their ability to adapt the logic of the scheduling algorithms to improve the targeted QoS attributes. The experimental results compare the performance of the platforms and show the current state of their readiness for edge computing in real network and execution environments. These findings suggest that Kubernetes and its distributions have the potential to provide effective scheduling across the resources on the network's edge. However, some challenges still have to be addressed to completely adapt these tools for such a dynamic and distributed execution environment as edge computing implies.

The container scaling mechanism, or elastic scaling, means the cluster can be dynamically adjusted based on the workload. As a typical container orchestration tool in cloud computing, Horizontal Pod Autoscaler (HPA) automatically adjusts the number of pods in a replication controller, deployment, replication set, or stateful set based on observed CPU utilization. There are several concerns with the current HPA technology. The first concern is that it can easily lead to untimely scaling and insufficient scaling for burst traffic. The second is that the antijitter mechanism of HPA may cause an inadequate number of onetime scale-outs and, thus, the inability to satisfy subsequent service requests. The third concern is that the fixed data sampling time means that the time interval for data reporting is the same for average and high loads, leading to untimely and insufficient scaling at high load times. In this study, we propose a Double Threshold Horizontal Pod Autoscaler (DHPA) algorithm, which fine-grained divides the scale of events into three categories: scale-out, no scale, and scale-in. And then, on the scaling strength, we also employ two thresholds that are further subdivided into no scaling (antijitter), regular scaling, and fast scaling for each of the three cases. The DHPA algorithm determines the scaling strategy using the average of the growth rates of CPU utilization, and thus, different scheduling policies are adopted. We compare the DHPA with the HPA algorithm under different loads, including low, medium, and high. The experiments show that the DHPA algorithm has better antijitter and antiload characteristics in container increase and reduction while ensuring service and cluster security.