Introduction to Kubernetes

The objective of Kubernetes is to abstract away the complexity of managing a fleet of containers, which represent packaged applications that include everything needed to run wherever they’re provisioned. By interacting with the Kubernetes REST API, you can describe the desired state of your application, and Kubernetes, aka k8s, will do whatever is necessary to make the infrastructure conform. It will deploy groups of containers, replicate them, redeploy if some of them fail, and so on.

Because it’s open source, it can run almost anywhere, and the major public cloud providers all provide easy ways to consume this technology. Private clouds based on OpenStack or Mesos can also run k8s, and bare metal servers can be leveraged as worker nodes for it. So if you describe your application with k8s building blocks, you’ll then be able to deploy it within VMs or bare metal servers, on public or private clouds.

Let’s take a look at the basics of how Kubernetes works so that you will have a solid foundation to dive deeper.

The Kubernetes architecture

The Kubernetes architecture is relatively simple. You never interact directly with the nodes that are hosting your application, but only with the control plane, which presents an API and is in charge of scheduling and replicating groups of containers named Pods. Kubectl is the command line interface you can use to interact with the API to share the desired application state or gather detailed information on the infrastructure’s current state.

Let’s look at the various pieces.


Each node that will host part of your distributed application does so by leveraging Docker or a similar container technology, such as Rocket from CoreOS. The nodes also run two additional piece of software: kube-proxy, which give access to your running app, and kubelet, which receives commands from the k8s control plane. Nodes can also run flannel, an etcd backed network fabric for containers.


The control plane itself runs the API server (kube-apiserver), the scheduler (kube-scheduler), the controller manager (kube-controller-manager) and etcd, a highly available key-value store for shared configuration and service discovery implementing the Raft consensus Algorithm.

Kubernetes Architecture

Now let’s look at some of the terminology you might run into.


Kubernetes has its own vocabulary which, once you get used to it, gives you some sense of how things are organized. These terms include:

  • Pods: Pods are a group of one or more containers, their shared storage, and options about how to run them. Each pod gets its own IP address.
  • Labels: Labels are key/value pairs that Kubernetes attaches to any objects, such as pods, Replication Controllers, Endpoints, and so on.
  • Annotations: Annotations are key/value pairs used to store arbitrary non-queryable metadata.
  • Services: Services are an abstraction that defines a logical set of Pods and a policy by which to access them over the network.
  • Replication Controller: Replication controllers ensure that a specific number of pod replicas are running at any one time.
  • Secrets: Secrets hold sensitive information such as passwords, TLS certificates, OAuth tokens, and ssh keys.
  • ConfigMap: ConfigMaps are mechanisms used to inject containers with configuration data while keeping containers agnostic of Kubernetes.

Why Kubernetes

In order to justify the added complexity that Kubernetes brings, there need to be some benefits. At its core, a cluster manager such as k8s exists to serve developers so they can serve themselves without having to involve the operation team.

Reliability is one of the major benefits of Kubernetes; Google has over 10 years of experience when it comes to infrastructure operations with Borg, their internal container orchestration solution, and they’ve built Kubernetes based on this experience. Kubernetes can be used to prevent failure from impacting the availability or performance of your application, that’s a great benefit.

Scalability is handled by Kubernetes on different levels. You can add cluster capacity by adding more workers nodes, which can even be automated in many public clouds with autoscaling functionality based on CPU and Memory triggers. The Kubernetes Scheduler includes affinity features to spread your workloads evenly across the infrastructure, maximizing availability. Finally, k8s can autoscale your application using the Pod autoscaler, which can be driven by custom triggers.

Sound interesting? If you live in Austin, Texas, you’re in luck; we’ll be presenting Kubernetes 101 at OpenStack Austin Texas on November 15, and at the Cloud Austin meetup on Nov 16, or you can dive right in and sign up for Mirantis’ Kubernetes and Docker Boot Camp.

Subscribe to Our Newsletter

Latest Tweets

Suggested Content

Mirantis Application Platform with Spinnaker
What's New in Kubernetes 1.10