Kubernetes: a humble introduction
Not just another container orchestrator
At Renault Digital, we always oversee what is a short term hype and what can provide high value to our organization.
Three years ago, we made the choice to adopt Kubernetes as a long term alternative to Docker Swarm. Now, it has become a DevOps Framework unlike the basic orchestrator it used to be.
Now, it has become a DevOps Framework unlike the basic orchestractor it used to be.
At the beginning, it was all about containers
Docker ignited the revolution with its containerized approach.
Before that, applications were deployed on dedicated and pre-configured hosting systems. Now, we define the execution context of our application in a descriptive file, running in a sandbox view of the operating system and packaged into an image that is ready to run.
Containers are the perfect answer to questions like :
“How to package an application?”
In the recent years, you hardly ever see a developper’s job description who does not mention Docker in the required skills. It is not a technology we can ignore. Developers have to have a container technology in their toolbox. Because with Docker and alike, a developper can provide a packaged self-deploying application on their own !
While the container approach is the best answer to application packaging… We still don’t have the answer to another question :
“How do we handle runtime?”
And this is where Kubernetes comes into the limelight.
Kubernetes definition
We usually see that Kubernetes is an orchestrator and manages containers. It can run application on a cluster with a fully managed container engine.
To my opinion, this explanation is too limited and next, I’ll explain to you why we should prefer the root definition from the Kubernetes website:
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.
Kubernetes core concepts
First, because Kubernetes was created for deployment, maintenance, and scaling, it answers nicely to these points. That’s why Kubernetes is:
- Lean: lightweight, simple, accessible
- Portable: public, private, hybrid, multi-cloud
- Extensible: modular, pluggable, hookable, modular
- Self-healing: self-placement, auto-restart, auto-replication
As it embraces the digital world, Kubernetes is fully (and should uniquely) be supported through an API. kubectl and yaml manifests are just sugar coating for making HTTP requests. And a basic curl can do the work :
curl http://localhost:8080/api/Or… with code 💪🏻:
import (
"fmt"
"k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes"
"k8s.io/client-go/tools/clientcmd"
)func main() {
// uses the current context in kubeconfig
// path-to-kubeconfig -- for example, /root/.kube/config
config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
// creates the clientset
clientset, _ := kubernetes.NewForConfig(config)
// access the API to list pods
pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
}
Like I said before: Kubernetes is not just an orchestrator, it’s much more.
Kubernetes as an Ops tool
At a naive stage, the Kubernetes API and its core are invisible. We just use kubectl and some tools like k9s or helm.
If we dig a little deeper, we can see that the Kubernetes world is working mainly and intensively on what is enabled by Kubernetes. At the opposite of what we can think, Kubernetes is not going to be bigger and will not include more “nice to have” features. In fact, they are always cleaning the system, putting non-core features outside of its system. Because they aim at maintaining things simple within core mechanisms.
The Kubernetes world moves fast by providing new tools and services using the Kubernetes core. Their goal is to embrace the key principle of DevOps :
Kubernetes as an enabler
The Kubernetes core is a totally stateless application centered on resources manipulation that keeps both scalability and lifecycle in mind :
- The Configuration and Resources are stored into a high availability key-value store
- The API server provides all the operations available on the cluster
- The Controller Manager is responsible for most of the collectors that regulates the state of a cluster and performs a task
- The Scheduler manages the workload
The API Server is the only component that is normally accessible. On my whole career, this is clearly one of the best API I have ever seen. The API fully capitalizes on the Kubernetes core to expose all operations and resources available on the cluster.
To do that and because the API is resource oriented, it exposes four methods: Read / Create / Update / Delete.
Kubernetes is “reactive”, that’s why we can “Watch” resources states and have data stream.
By definition, Kubernetes is expandable and everything is done to a thin integration :
- by creating new types of resources (CRD : Custom Resource Definition)
- by using lifecycle hooks (initializer, finalizers, etc.)
From my point of view, Kubernetes is far more than a just a tool or an orchestrator… It’s a DevOps framework.
Last words
To finish this humble introduction, if Kubernetes is a DevOps Framework, we have to dig these point questions:
- “Why do we need a DevOps framework?”
- … and “How to use Kubernetes to automate everything?”
If you are hasty, you should have a look to these links :
Else, I am writing another article to break this down !
