The game of abstraction of infrastructure is going fast. If you don’t keep up, you could end up in a world where people point their finger at and whisper “legacy”.
Looking back a decade, hardware evolved quick and virtualization technologies came to the rescue, allowing higher densities of workloads on one or multiple physical servers in the form of virtual machines. Applications ran in those VMs would benefit from high availability, so if a physical server fails another server takes over the virtual machine. The hypervisor technology creates hardware abstraction. However, the virtual machine is still bound to the underlying hypervisor and most probably to the hardware the hypervisor is using. This would mean that you can move virtual machines between the same type of hypervisor and hardware, but for example moving a VMware VM to Hyper-V is not possible without conversion. The same goes for moving to or between public cloud providers, no technical challenge there but the portability is not good enough. In other words, moving from and to another platform is not a one-click action.
Being tied to a specific platform of choice is not very convenient but was accepted for many years. Applications would run in virtual machines and those virtual machines would be on a hypervisor platform.
Containers form the new wave of innovation and modernization of applications. Containers run in virtual machines which are called ‘container host s’. While running in virtual machines, the platform creates abstraction of the underlying infrastructure (the hypervisor).
This would mean that you can a run one container host on Hyper-V and another on VMware and deploy the same container to it. Using containers, organizations are not tied to specific platforms but can be platform agnostic.
Management of containers is a different ball game comparing to management of virtual machines. A virtual machine would typically run one application and the VM would exist as long as the application did. In the container landscape, an application can consists out of multiple containers that are created when needed and destroyed when not used. This requires a different type of toolset and Kubernetes is the swiss knife that has all the tools build-in.
Kubernetes is a container orchestrator platform, but it has a lot more capabilities. Seeking agnostic infrastructure, you can use Kubernetes to abstract the infrastructure away from your applications. The container hosts mentioned above are included within Kubernetes and become ‘worker nodes’ where containers are deployed. Kubernetes now orchestrates your container landscape, it notices if more containers are needed or when containers can be removed because of inactivity. Because the Kubernetes nodes can run anywhere you’d like, and Kubernetes manages where containers are deployed, your application is now highly portable and abstracted from any platform.
Kubernetes itself also needs to run somewhere and is also distributed in multiple virtual machines, which is referred to as a ‘Kubernetes Management Cluster’.
In part 2 of this blog series we’ll go in full detail how Kubernetes works.
The major cloud providers were not ignoring the container era, thus are providing customers Kubernetes clusters as a service. They are called Amazon’s Elastic Kubernetes Service (EKS), Microsoft’s Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). The Kubernetes cluster is abstracted as well in a PaaS service by the cloud providers, but you could run it anywhere you’d like. Same for the worker nodes, you could make use of AKS and run your Kubernetes worker nodes in AWS, Google cloud, and Azure Stack HCI simultaneously. Now.. that’s a true hybrid cloud.
In this blog series we’re explicating the relationship between ‘traditional’ infrastructure, modern Hyper-converged infrastructure and Kubernetes. From an IT-Pro point-of-view.