Kubernetes Fundamentals: Common Terms

Container Orchestration with Kubernetes

Simply put, Kubernetes is a Container Orchestration tool. This means that, with Kubernetes you don’t worry about the container — where they are created, keeping them alive, how to talk to them and so on. You think only in terms of services needed for your application. This makes application design, deployment & scaling much easier.

Also with Kubernetes, the distinction between the Kubernetes cluster setup team & Kubernetes configuration (the team that uses the Kubernetes cluster)becomes distinctly separate. No overlapping or grey areas. The expertise needed to setup a cluster is different from the expertise needed to use it.

Getting started with using Kubernetes is pretty easy provided you have a few fundamental terms clear. These terms can seem a little confusing at first because there are not many tools with similar concepts.

So, lets start understanding the common fundamental terms in simple language.

Cluster

• Its simply a collection of machines (also called nodes)
• Every cluster will have some nodes that will work as master and some that work as worker nodes
• Kubernetes recommends 3 masters per cluster
• The short form for Kubernetes is K8S (8 alphabets between K and S hence, K8S)

Pod

• Smallest unit that can be managed in Kubernetes
• One pod can have 1 or more containers in it
• 1 pod should have only one purpose
• Containers in a pod will be created on the same node on which the pod exists. This means that, if a Pod has 3 containers and the Pod is created on node1 then, all 3 containers of that Pod will be on node1 too
• Containers in a pod will share resources of the node (since, they are always created on the same node)
• Every Pod is assigned a Virtual IP within the cluster
• By default, the ports exposed by the containers in the Pod are the ports exposed by the Pod
• Pods are mortal. Never depend on the life of a Pod.

Deployment

• Used by kubernetes to manage pods — scaling pods, restarting and so on

Replication Controller/Replica Set

• Used by deployments to maintain the required number (that is, replicas) of a pod.
• Its job is to ensure that the required replicas of a pods are always running (remember, in k8s you never talk in terms of containers — only in terms of pods)
• Every time you create a deployment, a replica set is created for it
• Originally, in Kubernetes there was only Replication Controller. Now, its being replaced by Replica Sets.
• Replica Set and Replication Controller do almost the same thing — ensure that the specified replicas of a pod are running.
• The main difference between Replication Controller & Replica Set is that Replica Set supports “set based selectors” too [e.g. environment in (prod, test)] , while Replication Controller supports only “equality based selectors” [e.g. environment = prod]
• Kubernetes uses deployments to manage pods; deployments use replica sets to maintain the number of replicas of a pod

Labels and Selectors

• Labels are key-value pairs used to tag objects
• Objects are the items that you create in a Kubernetes cluster (pods, deployments, replica sets, services, volumes etc)
• Selectors are used to collect objects based on tags

Service

• Allows clients to connect to Pods (remember, you don’t talk in terms of containers)
• It behaves like an abstraction over Pods
• Every service in Kubernetes is assigned a Virtual IP inside the cluster. This Virtual IP can be used only from inside the cluster
• Pods are mortal — services ensure that clients are can connect to pods reliably always.
• Services use collectors to decide which Pods to route traffic to — collecting Pods with matching labels.

Main Service Types

Cluster IP

• Only has a Virtual IP (also called Cluster IP)
• This service can be used within a cluster only
• Acts like a traffic router to your Pods inside the cluster
• Each port exposed by a pod will need a service if you want a client to talk to it via that port.
• By default, the service port is the same as the port exposed by the Pod.
• Different methods to access this service:
• From any node inside the cluster: <cluster IP>:<service port>
• From the node where a replica of the Pod is running: <pod IP>:<pod port>

Node Port

• For this service, a physical port on the node is mapped to the service port and the service connects to the Pod via the pod port
• Remember, this will also have a Virtual IP (i.e. cluster IP)
• Different methods to access this service:
• From outside the cluster, if any node in the cluster has a public IP: <node public IP>:<node port>
• From any node inside the cluster: <cluster IP>:<service port>
• From the node where a replica of the Pod is running: <pod IP>:<pod port>

Load Balancer

• Giving public access to a node in your cluster is not a recommended method
• When you want to give public access to a service, create a load balancer service (not getting into ingress at this stage)
• For each service that you want to give public access, you need to create a load balancer service
• This type of service will generally work only in a cloud environment
• Remember, this will also have a Virtual IP (i.e. cluster IP)
• This service will have a node port too
• Different methods to access this service:
• From outside the cluster:<load balancer dns>:<service port>
• From outside the cluster, if any node in the cluster has a public IP: <node public IP>:<node port>
• From any node inside the cluster: <cluster IP>:<service port>
• From the node where a replica of the Pod is running: <pod IP>:<pod port>

Of course, in no way is this a complete list of terms in Kubernetes but, this should give you a head start in using the tool.