At this point I am assuming you are already familiar with a container technology such as Docker and have an idea about what Kubernetes is. What we would be focusing on in this article is a high level overview of basic resource types you can see in a Kubernetes deployment environment. It is important to have a basic understanding of these resources and terminology in order to deep dive into Kubernetes. If you need to brush up on Docker basics before going through this article, you can start by reading: Getting Started with Docker. If you need an introduction to Kubernetes, you should read the previous article of this series: Introduction to Kubernetes.
Node
When you deploy Kubernetes, you create a cluster. A node or a worker node, is a physical or a virtual machine where containerized applications run. Application containers are run in the form of pods on these worker nodes, as well as other necessary workload management resources and components that are required to run pods.
A Kubernetes cluster could span across one or more nodes depending on the requirement, but should have at least one node.
We will discuss about worker nodes and it’s components in a a bit more detail in the next article.
Control Plane
Control Plane manages the worker nodes and workload resources in the Kubernetes cluster. In a production environment, the control plane also could span across multiple machines for fault tolerance.
There are several components that belong to the control plane, that we would discuss in a bit more detail in the next article. Basically, the duties of the control plane components are to make global decisions about the Kubernetes cluster, detecting and responding to cluster events and managing external access to the cluster.
Pod
Pod is the smallest component in Kubernetes. A pod is basically a layer of abstraction on top of a container. So if you want to deploy an application container, what you actually do in Kubernetes is deploying a pod, not a container.
Having this layer of abstraction enables Kubernetes to decouple container deployment from the container runtime. So you do not have to directly work with any container technology related components or commands such as Docker. It also makes it easier to replace the container runtime later when required.
A pod is meant to run only one application container inside of it! However, there might be occasions where you would run another helper container along with the main application container inside the same Pod. But the most common and advisable practice is to run only one container in one pod.
What if you wanted to scale the application to accommodate more user load? Then what you need to do is increase the number of pods. As mentioned above, we do not deploy more containers inside the same pod. Additional pods created would be identical to the first one and can be created on the same or a different worker node.
Like a container gets it’s own IP address in a regular container deployment such as Docker, in Kubernetes, each pod gets it’s own IP address, not the container. Pods can communicate amongst each other using these IP addresses.
Another important aspect of pods is that they are ephemeral, which means they have a short lifespan and could die easily. Once a pod dies, Kubernetes will detect it and create a new pod to replace it. How does Kubernetes detect this and then create pods in an appropriate manner? We will look into that later. For more information about Pods, read the article Introduction to Kubernetes Manifest: Pod.
ReplicaSet
Purpose of ReplicaSet is to maintain a specified number of stable replicas of any given application pod at any given time. In other words, it guarantees the specified number of identical pods for a certain application are available at all times.
However, we do not need to directly interact with ReplicaSets most of the time. Instead, we work with Deployments, which is a higher level resource type in Kubernetes.
Deployment
A Deployment provides declarative updates for pods and ReplicaSets. In simple words, we specify a desired state for our Deployment and Kubernetes Deployment controllers will maintain that desired state in a controlled rate. Deployment is a higher level concept that manages ReplicaSets and it allows us to provide declarative updates to pods.
Recommendation from Kubernetes documentation is to use Deployments instead of directly using ReplicaSets or pods for most common use cases. This means, you may never need to directly work with ReplicaSets when working with Kubernetes.
For more information about Deployments, read the article Deployments in Kubernetes.
Service
When discussing about pods, we discussed that each pod gets it’s own IP address. I also mentioned that they are ephemeral and pods get destroyed and new ones get recreated in their place. Obviously, communication between pods happen using their IP addresses and ports. But the thing is, we cannot rely on these IP addresses of pods for communication if they tend to change all the time.
When a pod dies and a new one is created, any other pods that communicate with it need to know that the previous IP address is no longer valid and should use the IP address of the new pod. How is this achieved? That’s where “Services” come in.
Services simply help connect applications deployed in a Kubernetes cluster with other applications. They also help connect these applications with users and external data sources. If we take an application that has a front end, back end and a database for an example, Kubernetes Services handle the connectivity between all these tiers.
Unlike pods, Services are not ephemeral and therefore, they get permanent IP addresses. In a Kubernetes application setup, we usually create a Service for each distinct pod within a Deployment to handle communications between different applications. Instead of communicating directly via pod IP addresses, communications go through Services.
It is also worth mentioning that a Service is not like a service that we see in an Operating System or a process. It is a virtual component that lives in the memory of Kubernetes cluster. Despite that, it gets it’s own IP address and port, just like an actual component with a network interface.
Ingress
Ingress manages external access to the Kubernetes cluster. It directs HTTP and HTTPS requests from outside the cluster to Services within the cluster. It does not expose other protocols or ports.
Traffic routing for various resources in the Kubernetes cluster is controlled by routing rules defined on the ingress resource.
ConfigMap
ConfigMaps are used to store non-confidential data as key-value pairs. They allow you to separate environment specific configurations from your container images, which makes the application much more portable.
For instance, if your application needs to connect to a database, typically you would include the database URL in a properties file. And the properties file would most likely read it from an environment variable. In such a case, you can include the database URL in a ConfigMap. Then pods can consume these key value pairs in ConfigMaps as environment variables, command line arguments or as configuration files in a volume.
It is also worth noting that you shouldn’t include confidential data such as passwords in ConfigMaps as they do not provide secrecy or encryption. Instead, you should use another resource type named ‘Secret‘ for that.
Secret
As the name suggests, Secrets contain sensitive or secret data such as passwords, tokens and keys. This means, you do not need to include this kind of sensitive data in application code or container images or in pod specifications.
Secrets can be created independently of the pods that use them. This means that Secrets will not be exposed when viewing, creating or editing pods. In addition to that, there are additional precautions we can take with Secrets to ensure further safety.
We will look into each of these resources in detail later in this Kubernetes series. In the next article, we will have a look at the main components in a Kubernetes cluster.
