Getting started with Kubernetes

  1. Node: A node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster.
  2. Pod: It is the smallest unit of a Kubernetes cluster. It is an abstraction over a container. We need this abstraction so that the container run time which is used does not affect the way you interact with your container. So, now you are free to use Docker or Podman or any other container runtime you want. Usually, we have one container inside a pod (or maybe some sidecar service containers also). Each pod gets its own IP address (internal and not public) and this is how pods communicate with each other.
  3. Service: A pod can crash anytime and when it is brought up again it won’t have the same IP address. This can disrupt the communication between pods. We use services as a solution. A service provides a pod with a permanent IP address. So, the communication will happen between services, and now if a pod dies its corresponding service will take care of it. A service can be internal which can be contacted internally (like for a database) or can be external which be reached by external clients(like for UI). Also, multiple pods doing the same job can hide behind a single service which will balance the load between them automatically.
  4. Ingress: It is an external service that acts as an external endpoint to the application.
  5. ConfigMap: It contains the external configuration required by various components of the application. So, if a component X wants to connect to another component Y, you just put a mapping of Y and its name in the configMap and give it to X for reference. Yes, you can give that mapping directly within X but then if the name changes then you’ll have to rebuild your components but if you use configMap, just change the name there.
  6. Secrets: Now in some cases, the configuration can contain confidential details like a pair of username and password (Usually if you are trying to connect to a database). Such information can not be and should not be kept as plain text. So, we use secrets to store such data in a base64 encoded format.
  7. Volume: Containers do not have persistent data storage. So, if we want to store some data we use this resource called Volume which when created goes and reserves a part of the hard drive or remote storage.
  8. Persistent Volume Claim(PVC): Once you have a volume resource created you would want your application to be able to go and ask the volume manager for a volume. That’s what PVC does. It tells about the configuration of volume needs of your application and then you can claim it if such a volume is available.
  9. Deployment: It is a blueprint of the application and contains details like which image is to be used, how many containers are there, how many replicas are to be created, etc. So, we don’t directly deal with pods but we do with deployment.
  10. StatefulSet: It is a deployment for the stateful components of your application such as a database. Since a single database can be tapped in by several pods, there is a need to synchronize reads and writes in such cases and statefilSet does that job for us.
  1. A container runtime: For the management of containers on each node. Can be Podman or Docker or any other that suits your needs.
  2. Kubelet: It is a Kubernetes process that schedules all the pods in that node. It acts as an interface between the machine and container runtime. It is responsible for starting containers by assigning desired resources, which are there on the node, to the container inside a pod using the given configuration.
  3. Kube-proxy: It contains the forwarding logic. Consider an example where you have several nodes running and each node contains your application and database pods. As discussed earlier multiple pods doing the same job can hide behind a single service which will balance the load between them automatically like shown below:
Two DB pods are managed by one service here.
  1. API Server: This is what listens to a client when a request comes. It gets the initial request and asks slave nodes to act upon it. Also, this is where all the authentication process happens before something can be forwarded to the main application. So, this the only entry point to your cluster.
  2. Scheduler: Once the client’s request is validated it is passed to the scheduler to act upon. Say you want to start a new pod, the scheduler will go and check the status of each node and see where that pod can go. These decisions are based on the demand for resources by your request. So, the scheduler makes the decision and passes on the order to start a new pod to the Kubelet of the chosen node.
  3. Controller Manager: It keeps an eye on each node and sees if something has gone wrong with any of the pods. If some pod has crashed it will try to bring up a new pod as soon as possible by requesting the scheduler to create a new pod with the same configuration.
  4. etcd: It stores the cluster state at various stages which helps the above three components to make better decisions based on the data provided by etcd. So, every change will automatically get registered on etcd. It only stores the cluster data and not the application data.
Image credit: aquasec




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Removing Duplicate Images through Python

Closures & The Great Escape

How To Use the Router as a Repeater?

Five Accurate Character Assassinations Software Engineers Can Confirm.

progamming language

How I made an App to Read to me the Top Posts from Reddit with AWS

CherrySwap, Jswap and KSwap Now Launch pToken Staking Pool!


Facing a giant — a throwback to a college project

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


More from Medium

What does Kubernetes actually do and why use it?

Kubernetes HPA

Kubernetes Architecture Terminology in a 3 min read. Professional Friendly.