In June, the Linux Foundation started a project based on Kubernetes, which was developed by Google to manage its complex environment. Companies like Google, eBay, Jive, Facebook, and Lithium have moved to this environment.
The application-centric cloud is a complete change from the approach of having a single platform deal with an application, and it's a revolution for the application to adapt to the hardware. It abstracts everything away from the application, such as resources and operational considerations, so the application developer need not worry about the environment that the application will run in because it's in a container that is abstracted from the hardware.
The old environment was extremely complicated because both applications and operations had to worry about the details of how to operate the application. To manage this, Google created its containers through Project Borg and then turned its focus to the management of these containers, thus creating Kubernetes. Google generates two billion containers a week. Everything in Google, including virtual machines, runs within containers. They also enable the capacity to be split among multiple environments.
Kubernetes has to manage billions of containers and created applications by composing these containers and pods (containers have a common basis). This allows Google to create an environment that is fairly homogeneous and creates a standard foundation for applications to scale no matter what hardware is underneath the container environment. Kubernetes also allocates containers to the appropriate resources, restarting jobs and moving containers when resources require it.
In July 2015, Kubernetes 1.0 was launched. Companies like Red Hat contributed significantly to the open source community to get this ready. The authors recognized that they had to move this to a foundation so that the rest of the industry could work and participate to ensure that all their needs were met. The key is that Kubernetes is built upon a single software stack and abstraction layer. The working group realized that everybody's environment is different and wanted internal communities to work on modifying Kubernetes to meet everyone's else's needs.
Kubernetes uses declarative, context-based rules that enable the descriptions to be portable. There were 400 contributors to this project at the start of the project, which has enabled a lot of input from the community to reach the project. The Kubernetes environment becomes a target environment that is universal for the industry, regardless of the underlying infrastructure. It supports load-balancing, scaling, health checking, and micro service management. It can work in a cloud environment like AWS, a virtualization environment (VMware, Azure, and KVM), and a base operating system like Windows or Linux.
A target-neutral management tool was needed to be able to manage microservices, containers, and pods. It was important that the design point was the ability of Kubernetes to deploy a single container in less than 5 ms. It was also important that the project enabled containers and micro services to schedule across environments. The health monitoring is extremely good, since you are managing multiple instances of the same application.
Kubernetes works with the network and storage, as we discussed in the previous columns. There is work on rollback of these services that is deployed. It deals with phased rollouts or phased upgrades while the environment continues to run. If it sees that it needs the new capacity, it can bring up a new set of containers and deploy the workload associated with the Pod. One of the keys to making this work is an excellent scripting language that can also use other tools given the magnitude of the management technology.
Therefore, when people ask how to manage the application-centric cloud with containers, micro-services, and virtualization, we look to the community that is building the tools because the traditional management systems fail us in this new environment.