Kubernetes Key Concepts

Introduction

This is the first post of series about Kubernetes that I want to write in this year.

Kubernetes (K8s) is an open source platform for automating container operations such as deployment, scheduling and scalability across a cluster of nodes.

Kubernetes supports container technologies such as Rocket or Docker as a low level component used internally to deploy containers.

There are many blog posts, tutorials and books explain about Kubernetes and key concepts. So, in my post, I will provide a brief explanation of the key concepts of Kubernetes.

Key concepts

Kubectl

kubectl is a command-line program for interacting with the Kubernetes API, to control the Kubernetes cluster manager.

Cluster

A cluster is a group of nodes, they can be physical servers or virtual machines that has Kubernetes platform installed.

Master

The cluster has a Kubernestes Master that control multiple Nodes.

The Kubernetes Master provides a unified view into the cluster and has a number of component such the Kubernetes API Server.

This Kubernetes API server provides a REST endpoint that can be used to interact with the cluster.

The Master also included the Replication Controllers used to create and replicate Pods.

Nodes

A Node is a physical or virtual machine that acts as a Kubernetes worker, used to be called Minion.

Each node runs the following key Kubernetes components.

  • Kubelet: is the primary node agent.
  • Kube-proxy: used by Services to proxy connections to Pods.
  • Docker or Rocket: the container technology that Kubernetes uses to create containers.

Pods

Pods are smallest deployable units in Kubernetes that can be created scheduled and managed.

Pods are scheduled to Nodes. Pod contains containers and volumes. Containers in a same Pod share the same network namespace and can communicate with each other using localhost.

For example: there is a pod contain a Ruby on Rails application, this application may include two container images: Ruby and Database (could be postgresql/mysql)
These two containers can communicate with each other using localhost.

Labels

Label is a key/value pair attached to Pods and convey user-defined attributes. Basically, label in Kubernetes and tags in AWS/AliCloud has the same meaning.

In addition, you can use Selectors to select Pods with particular Labels and apply Services or Replication Controllers to them.

Replication Controllers

Replication Controllers ensure the specified number of Pods replicas are running at any one time.

  • If you create a Replication Controller for a Pod and specified 3 replicates, then it will create 3 pods and will continuously monitor them.
  • If one Pod died then the Replication Controller will replace it to maintain a total count is 3.
  • If the Pod has died comes back then you have 4 Pods, so the Replication Controller will terminate one so the total count is 3.

When creating a Replication Controller, you need to specify two things:

  • Pod Template: the template that will be used to create the Pod replicas.
  • Labels: the labels for the Pods that this Replication Controller should monitor.

Services

How can I access application containers? The answer is Service.

Service is an abstraction that define a set of Pods and a policy to access them. Service find group of Pods by using Labels.

As I mentioned above, each Node run the following key Kubernetes components, there is a key component called Kube-proxy.
Kube-proxy will be used by Services to proxy connections to Pods. You guys can read the example below to understand.

For example:

I have two application Pods and I defined a Service named Service A with label selector (tier=application, app=myapp).

Service Service A will facilitate two key things:

  • A cluster-local DNS entry will be created for the Service and you will got a stable IP address that you can use.
  • From an IP address for the Service A, which one of two application Pods will it access? The Service will provide a transparent load balancing between two application Pods
    and forward request to any one of them. This is done by using a proxy (kube-proxy) that run on each Node.

Conclusion

  • In the next posts, I’ll going to detail concepts and will provide a real application managed by Kubernetes.