Container Orchestration with Kubernetes part 01

Introducing Kubernetes and Container Engines

Objectives

After completing this section, you should be able to get an overview of what Kubernetes and Container are, how they improve the software life cycle, and samples of different container runtimes.

Traditional Applications vs Kubernetes and Container

Traditional software applications typically depend on other libraries, configuration files, or services that are provided by the runtime environment. The application runtime environment is a physical host or virtual machine (VM) and application dependencies are installed as part of the host.

For example, consider a Python application that requires access to a common shared library that implements the TLS protocol. A system administrator installs the required package that provides the shared library before installing the Python application.

The major drawback to a traditional deployment is that the application’s dependencies are mixed with the runtime environment. Because of this, an application might break when any updates or patches are applied to the base operating system (OS).

For example, an update to the TLS shared library removes TLS 1.0 as a supported protocol. Updating the library breaks a Python application that is strictly dependent on TLS 1.0. The system administrator must downgrade the library to keep the application running, but this prevents other applications from using the benefits of the updated package.

To alleviate potential breakages, a company might maintain a full test suite to guarantee OS updates do not affect applications.

Furthermore, applications must be stopped before updating the associated dependencies. To minimize downtime, organizations use complex systems to provide high availability. Maintaining multiple applications on a single host often becomes cumbersome, and any update has the potential to break one of the applications.

Kubernetes and Container
Kubernetes and Container

Containerized Applications (Kubernetes and Container)

Deploying applications using containers is an alternative to the traditional methods. A container is a set of one or more processes that are isolated from the rest of the system.

Kubernetes and Container provide many of the same benefits as virtual machines, such as security, storage, and network isolation. Containers require fewer hardware resources and are quick to start and terminate. They also isolate the libraries and the runtime resources, such as CPU and storage, and minimize the impact of OS updates.

Beyond improving efficiency, elasticity, and reusability of hosted applications, container usage improves application portability. The Open Container Initiative (OCI) provides a set of industry standards that define a container runtime specification and a container image specification. The image specification defines the format for the bundle of files and metadata that form a container image. When you build a container image compliant with the OCI standard, you can use any OCI-compliant container engine to execute the contained application.

There are many container engines available to manage and execute containers, including Rocket, Drawbridge, LXC, Docker, and Podman.

The following are other major advantages to using containers:Low hardware footprint

Containers use OS-internal features to create an isolated environment where resources are managed using OS facilities such as namespaces and cgroups. This approach minimizes the amount of CPU and memory overhead compared to a virtual machine hypervisor. Running an application in a VM isolates the application from the running environment, but it requires a heavy service layer to achieve the level of isolation provided by containers.Environment isolation

Containers work in a closed environment where changes made to the host OS or other applications do not affect the container. Because the libraries needed by a container are self-contained, the application can run without disruption. For example, each application can exist in its own container with its own set of libraries. An update made to one container does not affect other containers.Quick deployment

Containers deploy quickly because there is no need to install the entire underlying operating system. Normally, to support isolation, a host requires a new OS installation, and any update might require a full OS restart. A container restart does not require stopping any services on the host OS.Multiple environment deployment

In a traditional deployment scenario using a single host, any environment differences could break the application. By using containers, all application dependencies and environment settings are encapsulated in the container image.Reusability

The same container can be reused without the need to set up a full OS. For example, the same database container that provides a production database service can be used by each developer to create a development database during application development. By using containers, there is no longer a need to maintain separate production and development database servers. A single container image is used to create instances of the database service.

Often, a software application with all of its dependent services (databases, messaging, file systems) are made to run in a single container. This can lead to the same problems associated with traditional software deployments to virtual machines or physical hosts. In these instances, a multicontainer deployment might be more suitable.

Furthermore, containers are an ideal approach when using microservices for application development. Each service is encapsulated in a lightweight and reliable container environment that can be deployed to a production or development environment. The collection of containerized services required by an application can be hosted on a single machine, removing the need to manage a machine for each service.

In contrast, many applications are not well suited for a containerized environment. For example, applications accessing low-level hardware information, such as memory, file systems, and devices may be unreliable due to Kubernetes and Container limitations.

Summary

In this blog, you learned:

  • Applications running in containers are decoupled from the host operating system’s libraries.
  • Among other features, container orchestration platforms provide tooling to automate the deployment and management of application containers.

Leave a Comment

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

Scroll to Top