Related content:

Kubernetes is an open-source container orchestration manager. It is often confused with container models such as Docker but it is not the same thing. Kubernetes can be used to orchestrate the use of Docker containers but it is not a container itself.

A container manager is an important component of a cloud compute based architecture but it can also be used in stand-alone situations running on a monolithic server. All of the major cloud compute service providers offer Kubernetes as a container manager. There are other alternatives but Kubernetes is very popular. It is an open-source project and therefore free to deploy without the need for licenses. Third-party providers may add enhancements and offer managed installations of Kubernetes for a price. Trading off the managed provision instead of using your own systems engineers and administrators may be a cost-effective alternative.

There is a lot of ground to cover and this time we will just get to know the fundamentals of what Kubernetes is and some contextual background to how it works compared with other historical architectures. Later articles will drill down into the various capabilities in more detail.

What Is Kubernetes?

Kubernetes is an increasingly popular open-source manager for containerized workloads and services. This popularity ensures there are plenty of experts available and a growing collection of tools that can be used to ease the installation and extend its capabilities.

Kubernetes was originally developed by Google and based on their experience of running massive server farms handling huge workloads. Since it was open-sourced in 2014, the community at large have contributed improvements as well. Having been in existence for some time and used on an industrial scale by Google, Kubernetes is now a mature system and well-supported.

Kubernetes uses these containers to describe a service with a more portable solution than virtualization can offer:

• Docker as a wrapper for Containerd (this is becoming less popular).
• Containerd stand-alone.
• CRI-O.
• Groups of containers in a Kubernetes Pod.
• Podman groups of containers.
• Any other container types that support the Kubernetes Container Runtime Interface (CRI).

Kubernetes will start a new container if a currently running one fails. It orchestrates the resources and provides resilience.

A Taxonomy Of Architectural Designs

To properly grasp the revolutionary approach containerized services offer, it is important to see them in the context of the earlier architectures that sought to provide improved computing throughput.

The provenance of containerized architectures has evolved from many earlier designs. Each generation offered systemic improvements and eliminated short-comings. The goal has always been to reduce the manual intervention needed and to efficiently utilize all of the available computing resource.

The older architectures are still relevant because cloud compute based containers are good for very specific kinds of work but don’t completely replace high performance systems used for compute intensive tasks. They add to our repertoire of solutions in a very elegant way.

Servers can be organized as individual monolithic machines or combined in different ways operate as a single system. At one extreme, we need huge and high-performance systems to tackle compute intensive workloads. At the other extreme, small and agile Microservices require very few computing resources.

These are the various architectures:

• Monolithic stand-alone servers.
• High-Availability configurations.
• Network connected clusters.
• Grid-based supercomputers.
• Distributed opportunistic deployment.
• Virtualized CPU deployment.
• Containerized services deployment.

Monolithic Stand-alone Servers

This is the time-honored traditional solution. Building your own physical servers required some skill to tune the performance and sys-admin resources to configure them and keep them working. It is still viable when dedicated systems are needed as render servers in a VFX pipeline.

The application choice may determine which operating system you need. That may then also dictate the hardware vendor you select. In the case of UNIX based applications, make sure the CPU type (Intel vs ARM) is also taken into consideration:

• MacOS applications can only run on Apple hardware.
• Windows applications can generally run on any Intel platform. Including Apple hardware courtesy of the BootCamp loader.
• Linux is the most portable.

One major benefit is that you get all of the CPU power available for your workflow. The downside is that a single process can hog the resources and cause problems for other activities. Managing these resources requires skilled admin staff to configure the system limits so the applications can run efficiently without dominating the machine at the expense of the others.

Aside from Apple, few computer manufacturers also engineer their own OS. UNIX is well served by the Linux community. There are over 250 different alternative distributions for different uses. The most common ones are:

• Debian based.
• Ubuntu and its derivatives.
• Red Hat based (including Fedora).
• SUSE based.

High-availability Configurations

High availability is useful when robust uninterrupted operation is needed. It requires some hardware redundancy. The simplest configuration uses two host servers that mirror each other’s configuration and share the same storage. They are cross-coupled with a ‘heartbeat’ monitor which is observed regularly by the other host. Should the heartbeat fail to arrive, the servers can fail-over one way or the other very rapidly and continue providing the service without significant interruption. The systems engineers would be alerted to the fault so they can rectify it.

Network Connected Clusters

A cluster will provide resilience and very long uptimes for large compute tasks spanning several years.

Clustered operation connects multiple servers together and can distribute work across all the machines. A new process is started on the cluster rather than on an individual machine. The cluster can then load balance across all the machines.

Because the machines are all connected via the network, a single node can have its workload redistributed to the rest of the cluster so it can be detached and physically moved to another location before being reattached remotely. The entire cluster can be relocated one machine at a time without interrupting long-running processing jobs and restarting them again.

Grid-based Supercomputers

Grid architectures are useful for tasks that require massive CPU resources that can be vended and requested as a single service.

Grid-connected systems allow tasks to be parallelized across the grid in a similar way to the rendering process in a Graphics Processing Unit (GPU). This is sometimes called Single Instruction Multiple Destination (SIMD) processing.

Not all tasks are suitable for grid-computing because they cannot be parallelized easily. If they depend on the output of earlier tasks, then serial processing is mandated.

The grid controller passes instructions and delegates tasks to the nodes. They can all reach the shared storage. There is also fast interconnection between the nodes (not shown) so they can rapidly exchange data between them. This architecture doesn’t lend itself to virtualization but it could be provided as a resource for the cloud-based computing to call on when some compute intensive work is needed.

Distributed Opportunistic Deployment

This approach is useful where workloads can be deferred until later in the day and batched up for delegation to satellite machines.

Distributed opportunistic deployment across small PC machines has been adopted by VFX companies to use desktop office systems as overnight render nodes. When the staff go home, rendering tasks can be delegated to machines that are otherwise idle. This is quite effective because you get about 16 hours of processing time multiplied by the available machines without needing to deploy additional hardware. Provided the tasks are scheduled to exit before the staff return the next morning, nobody notices. Graphics software such as Maya has built in render node support for this.

Virtualized CPU Deployment

Virtualization is useful when CPU and OS emulation is needed for platform hardware that is otherwise unavailable. When deployed on a larger scale, it can provide scalable and flexible solutions that are more efficient than running monolithic servers.

The roots of virtualization go back to very early technologies where source code was either interpreted or compiled for execution. Virtualization exploits software emulation much like the internals of BASIC language interpreters in late 1970’s vintage personal computers.

Virtualized computing emerged in the 1980’s when Digital Research and Intel collaborated on running multiple instances of DOS concurrently in a single machine. Wine emerged in 1993 and supported Windows software running on Linux machines. Multi Arcade Machine Emulator (MAME) was released in 1997, VMWare emerged in 1999 and Parallels followed in 2006 when running Windows in a virtual machine was popularized on the Apple macOS platform.

These techniques have become increasingly open-sourced. This led to server-based implementations. Public cloud based services running on hugely powerful hardware became available as a consequence:

• Amazon founded AWS in 2002 with cloud services arriving in 2006.
• Microsoft launched Azure in 2008 under a different project name.
• Google Cloud Platform (GCP) also arrived in 2008.

Multiple Virtual Machines (VM) can run on a single physical CPU. Each VM is partitioned from the others. This isolates applications more effectively than running them in a monolithic server. Security is improved because they communicate with messages rather than accessing shared memory.

Virtualized machines require a supervisor process. Multiple supervisors need an additional management layer. This supervisor of supervisors gives rise to the term Hypervisor. It provides the context for the virtual machines to run in.

Containerized Services Deployment

Containers are an excellent and optimal solution to support highly portable Microservice architectures. Use them to build lightweight services that run independently inside a single machine.

Docker containers have been available for some time. There are new and more flexible container types available. Compatibility is ensured if they implement the Kubernetes API correctly. Then they should just drop in to an existing installation and just work.

Migrating to a cloud compute based architecture provides more advantages.

When this is scaled up to hundreds or even thousands of containers running a Microservice infrastructure, it becomes too unwieldy to operate manually.

Kubernetes orchestrates the container lifecycles. It ensures that they are available and ready when called on and if they crash, it can restart them again automatically without any fuss.

When comparing Virtualization with Containerization, note how the containerized approach removes the operating system from the containers and implements that support in the container runtime as logical resources. All the containers now share the same operating environment. Mixing operating systems is not relevant now because there is no need to use OS and hardware dependent coding in the application code.

Each container has its own private resources:

• Separate file system.
• Private share of CPU compute capacity.
• Private memory allocation.
• Private process space.

The applications running in the containers cannot affect or interfere with one another. The container runtime separates them from the underlying computing platform. Provided the runtime has been ported, the same containers can be deployed anywhere regardless of the operating system at the foundation level.

Containers offer these advantages:

• Easier and quicker to create and deploy than virtual machines.
• Facilitates Continuous Integration where modules are worked on separately and deployed asynchronously.
• Easy to roll-back the changes.
• Easy to observe and monitor.
• Development platforms are identical to the live deployment infrastructure. Testing accurately reflects the live behavior.
• They can run anywhere the orchestration and runtime support is available. Private or public, monolithic or cloud architectures all behave consistently.
• Everything is abstractly managed as an application rather than a process running on a specific CPU. The application support is virtualized to remove hardware and OS specific dependencies. The application works with logical rather than physical resources.
• Suitable for deploying loosely coupled Microservice architectures.
• Containers are isolated from each other.
• Predictable performance.
• Very efficient use of available resources.
• High packing density with many containers on a single machine.

Conclusion

Kubernetes managed containers replace the simple virtualization of a single CPU in a Virtual Machine (VM) with a more portable lightweight solution for running services.

The hosting machine is fully utilized with resources being used optimally. Services are started and stopped on a demand driven basis across the available computing real-estate.

Where virtualization emulates entire monolithic servers with their operating system support, containers are more portable and completely platform independent.

Virtualization and containerized architectures can be deployed on personal desktop or laptop computers for development. Move containers to your live cloud-based architecture without any changes where they will behave identically.