Thinking Outside the Box by Putting Code in a Box

Let's face it, Google has deployed A LOT of code. Not only do they manage code for  applications from Youtube to Google Maps to, well... Google search, they do so across at least a million servers. Over the course of 15 years of application deployment, they learned that the old way sucked.

So, as Google does, they built their own solution – Kubernetes.

Why Kubernetes?

The "old way" dates back to the start of computers. A developer would write an application and it would be installed onto each computer that needed to use said application. Single deployments like this are difficult to update. Further, if there was more than one program installed onto the same machine, there was nothing preventing one of them from hogging all of the resources.

Each application could be deployed onto its own computer, however this is difficult and expensive to scale – especially since it would leave many servers underutilized.

The next best solution was through virtualization. This allowed a physical computer to be split into multiple logical computers. Although it allowed for better scalability and resource allocation, it still required all the overhead of an operating system per deployment.

Faced with this conundrum, Google created the idea of conntainerization. Rather than separating apps onto separate virtual machines, they could all exist on the same machine, but be contained within a boundry. The boundry allowed each application deployment to have resources reserved for it while sharing the OS level kernel with the other applications.

What is Kubernetes?

Kubernetes originates from Greek, meaning helmsman or pilot. It is also commonly referred to as K8s because between K and s there are eight letters that nobody was quite sure how to pronounce.

K8s, as we know it today, is the product that Google open-sourced through the Kubernetes project in 2014. It is an orchestration tool that allows you to create, deploy and manage clustered resources.

It is portable and can be used with public, private, hybrid, and multi-cloud environments; extensible by being pluggable, modular, composable, hookable; and is self-healing with features like auto-replication, auto-placement, auto-scaling, and auto-restart.

How do the pieces work together?

Cluster

At the highest level, there are clusters. These clusters are groups of logically connected nodes. Each cluster will have a control plane that orchestrates the nodes and facilitates interaction from the developers.

Each node will have a kublet, kube-proxy, and pods of containers. Containers are the lowest level, but the most important. They house the actual units of work that we want to be performed, packaged as microservices.

This design framework promotes usability and scalability, even in complex systems.

Control Plane

where we define, deploy and manage the life cycle of our pods

• Kube-API Server: allows for interaction with Kubernetes from the command line. kubectl is a powerful command allowing you to create, edit, and remove deployments.
• Kube-scheduler: Assigns newly created pods and containers to nodes based on the set of given rules including resources, policies, and replications.
• Kube-controller-manager: Core control loop pushing the current state towards the desired state.
• etcd: the key-value store where all data for the cluster is stored.

Node(s)

Where the work is done

• Kublet: Agent ensuring that each pod has the necessary containers running
• Kube-proxy: network proxy that maintains communication between nodes
• Pod: Logical collection of containers
  • Containers: Lowest level item in the K8s hierarchy. They are cognizant of Namespaces (what they are allowed to see) and Cgroups (what they are allowed to use). These should also be agnostic to the OS system. A common framework for building these containers is Docker. You can define containers using a Dockerfile and run each container as an executable.
• Container runtime: Software environment that runs the containers.

The beauty of Kubebernetes is that you don't have to pay attention to most of what was described above. Although you can interact with K8s in an imperative fashion through their API, it is much easier to use its declarative features.

By defining a desired state, made up through a series of Dockerfiles and YAML files, Kubernetes will determine how to deploy and manage this code for you. Hence, its definition as a helman, or pilot.

Benefits of using Kubernetes

Containers have become popular because they provide extra benefits, such as:

• Simple and quick creation and deployment
• Defining states in files allows continuous development, integration, and deployment
• Portability across server locations and OS type
• Resource isolation: predictable application performance.
• Resource utilization: High efficiency and density.
• Load balanced traffic to containers
• Self-healing by checking in with containers and restarting failed or stalled services
• Rolling updates and rollbacks

Using this tool allows you to spend more time on the development of your products and less time dealing with the tricky and time consuming aspects of server management.