What is it ?:
Kubernetes is a newly released Google’s Container-as-a-Service solution. Its an orchestration middleware built on top of another popular technology Docker which is known for creating and managing lightweight linux containers from where application can be built and run out of.
Building blocks of Kubernetes:
While Docker itself works with individual containers, Kubernetes provides higher-level organizational constructs to support common cluster-level usage patterns, currently focused on service applications. Some of the important constructs/concepts are described below.
- POD: Relatively tightly coupled group of containers that are scheduled onto the same physical node. Containers in a POD all use the same network namespace/IP (and port space) and defines a set of shared storage volumes. They serve as a unit of scheduling, deployment and replication.
- LABELS: Loosely coupled cooperating pods are organized using key/value labels. Each POD can have a set of key/value set on it.
- KUBERNETES NODE: It is a physical node that has services necessary to run Docker containers and be managed from master systems
i. Docker: Takes care of the details of downloading images and running containers.
ii. Kubelet: Takes a set of container manifests (YAML that describes a POD) and ensures that the containers described in them are started and continue running.
iii. Kubernetes Proxy: A simple network proxy that reflects services as defined in the Kubernetes API on each node and can do simple TCP stream forwarding.
- KUBERNETES MASTER: It is split into a number of components that work together to provide an unified view of the cluster.
i. etcd: All persistent master state is stored in an instance of etcd. Configuration data can be stored here reliably.
ii. Kubernetes API Server: Serves up the main Kubernetes APIs and validates and configures data for every POD, SERVICE(configuration unit for proxies that run on every worker node) and replicationCONTROLLER (ensures there is a specified number of replicas of each template.)
iii. Controller Manager Server: Watches etcd for changes to replicationCONTROLLER objects and uses public Kubernetes API to implement the replication algorithm.
Quick Look Architecture:
Where is Kubernetes useful ?:
Developing and deploying applications out of linux container environments has its own advantages. Especially with Docker, containers can be used to provide standardized environment for development, QA and production teams. Packaging and deployment of these apps can become easy and seamless. As a result, the dev-ops teams can ship faster and run the same app, unchanged, on laptops, data center VMs and cloud platforms.
Kubernetes tries to build an orchestration layer on of top this framework, trying to decide how PODS (collection of closely tied containers) can be deployed onto a physical machine. With such an approach, Kubernetes can be viewed as a good application deployment tool for the PaaS (Platform-as-a-Service) layer.
Can Kubernetes be used on top of Openstack:
One way of leveraging Kubernetes would be to use it in deploying applications on top of VMs provided by Openstack (at the IaaS layer).
Once VMs (along with the required networking and storage setup) have been allocated for their respective projects, application deployment engineers could view these VMs as actual physical machines allocated to their Business Unit and choose to run their container friendly applications on top. They would even be able to manipulate POD sizes and leverage the distributed VM footprint provided by an IaaS scheduling solution (Openstack - nova scheduling) keeping high availability in mind.
Is Kubernetes trying to solve both IaaS + Paas:
As described in the architecture above, a POD becomes the least granularity construct which can be deployed on a single physical bare metal host. Since a POD can be categorized as a collection of lightweight containers running applications ideally belonging to a single project owner, we are arguably left with the fact that a single physical host is locked down to serve only one project at a time as against to the Openstack approach of being able to control deployment of every single VM on any physical machine purely on the basis of its cpu, disk and memory usage, resulting in a truly shared cloud.
As an IaaS solution, the approach taken from Kubernetes can end up having limitation towards achieving high availability across data centers and also leaves IaaS providers with the task of identifying and categorizing selective applications that are ready to use such scheduling scenarios.
Kubernetes as compared with Openstack
Is it a substitute ?:
Kubernetes could potentially be seen as a substitute for Openstack in providing docker based container scheduling and deployment. Light weight linux containers as against virtualized guest environments, being the basic difference in their offerings respectively.
Docker with Openstack:
Kubernetes is heavily integrated with Docker, having said that, Openstack open-source community is currently working with the Docker team for providing a driver than can seamlessly be loaded into Openstack for providing a container-as-a-service solution orchestrated by openstack nova itself.
Once a full feature set driver is available, we are potentially looking at Openstack to be a single stop solution provider for managing virtual machines as well as light weight linux containers at an IaaS level.
Developer community strength:
Kubernetes is fairly new and will need time to gather a strong open source community around it. Inevitably, the immediate directions of the product will be decided by Google developer community. Kubernetes is written in GO, a language released by google 3 years back. Openstack is pure python, a world accepted language for coding and product development.
Missing other required Openstack like services:
With the current capabilities, Kubernetes can be viewed as an orchestration layer for managing light-weight containers deployed by Docker. All other key cloud (IaaS) components like Identity-as-a-Service, Image-as-a-Service, Networking-as-a-Service(along with SDN solutions) are still missing from the picture.
It does not have the concept of projects/tenants yet which, in a typical private cloud setup, relates directly to company wide organizational structures of groups and projects.
Initial support focused for Google Cloud Engine:
Initial development for Kubernetes was done on GCE and hence many of the instructions and scripts are built around that. Development cycles will require a Google Cloud Platform account with billing enabled.