Introduction to Basic Concepts of Kubernetes

Containers and Pods

In this tutorial, we are going to discuss about basic concepts of Kubernetes. Let’s start from containers and pods. Pods are the smallest and most basic building block of the Kubernetes model. A pod consists of one or more containers, storage resources, and a unique IP address in the Kubernetes cluster network. In order to run containers, Kubernetes shedules pods to run on servers in the cluster. When a pod is sheduled, the server will run the containers that are part of that pods.

In order to run and manage containers with Kubernetes, you will need to use pods. In this lesson, we discuss the basics of what pods are and how they are related to containers within the world of Kubernetes. We will create a simple pod and then we will look at some ways to explore and interact with pods in your Kubernetes cluster.

Here are the commands used in this tutorial:

Create a simple pod running an nginx container:


cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
EOF

Get a list of pods and verify that your new nginx pod is in the Running state:


kubectl get pods

Get more information about your nginx pod:


kubectl describe pod nginx

Delete the pod:


kubectl delete pod nginx

Clustering and Nodes

Kubernetes implements a clustered architecture. In a typical production environtment, you will have multiple servers that are able to run your workloads (containers). These are which actually run the containers are called nodes. A Kubernetes cluster has one or more control servers which manage and control the cluster and host the Kubernetes API. These control servers are usually separate from worker nodes, which run applications within the cluster.

Nodes are an essential part of the Kubernetes cluster. They are the machines where your cluster’s container workloads are executed. In this lesson, we will discuss what nodes are in Kubernetes, and we will explore some ways in which you can find information about nodes in your cluster.

Here are the commands used in this tutorial:

Get a list of nodes:


kubectl get nodes

Get more information about a specific node:


kubectl describe node $node_name

Networking in Kubernetes

When using Kubernetes, it is importanat to understand how Kubernetes implements networking between pods (and services) in the cluster. The Kubernetes networking model involves creating a virtual network across the whole cluster. This means that every pod on the cluster has a unique IP address, and can communicate with any other pods in the cluster, even if that other pod is running on a different node. Kubernetes supports a variety of networking plugins that implement this model in various ways. We are using Flannel in this practical tutorial.

Networking is an important part of understanding the basics of Kubernetes. This lesson provides a high-level overview of what a Kubernetes virtual cluster network looks like. We will also demonstrate how the network functions by contacting one pod from another pod over the virtual network.

Create a deployment with two nginx pods:


cat << EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
EOF

Create a busybox pod to use for testing:


cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: radial/busyboxplus:curl
    args:
    - sleep
    - "1000"
EOF

Get the IP addresses of your pods:


kubectl get pods -o wide

Get the IP address of one of the nginx pods, then contact that nginx pod from the busybox pod using the nginx pod’s IP address:


kubectl exec busybox -- curl $nginx_pod_ip

Kubernetes Architecture and Components

Kubernetes includes multiple components that work together to provide the functionality of a Kubernetes cluster. The control plane components manage and control the cluster:

etcd: Provides distributed, synchronized data storage for the cluster state.
kube-apiserver: Serves the Kubernetes API, the primary interface for the cluster.
kube-controller-manager: Bundles several components into one package.
kube-scheduler: Schedules pods to run on individual nodes.

In addition to the control plane, each node also has:

kubelet: Agent that executes containers on each node.
kube-proxy: Handles network communication between nodes by adding firewall routing rules.

With kubeadm, many of these components are run as pods within the cluster itself.

A Kubernetes cluster is made up of multiple individual components running on the various machines that are part of the cluster. In this lesson, we will briefly discuss the major Kubernetes software components and what each of them do. We will also look into how these components are actually running in our cluster currently.

Here are the commands used in this lesson:

Get a list of system pods running in the cluster:


kubectl get pods -n kube-system

Check the status of the kubelet service:


sudo systemctl status kubelet

Conclusion

That’s all you need to know about basic concepts of Kubernetes on Linux server. There are more tutorials that will go into deeper explanation of using Kubernetes thoroughly, but this is a simple article to just get familiar with Kubernetes concepts on linux based server.

Asif Khan

Asif Khan

DevOps, Linux, and Cloud engineer with 10+ years building infrastructure that stays up, and automation so I do not have to fix it at 2am. My focus is automation, security, and systems built to survive failure, using Infrastructure as Code, CI/CD, containers, monitoring, and cloud platforms instead of manual fixes. This blog is where I write down what worked, and just as often what didn't the first time around. Real tutorials you can run yourself, troubleshooting notes pulled from actual outages, and the kind of detail you only get once you've hit the problem firsthand. If you're trying to get Linux, DevOps, and cloud infrastructure to behave, that's what you'll find here: reproducible solutions you can understand, test, and apply in your own environment.