Today, we will learn about Kubernetes fundamentals.
After reading the post, you will have a basic understanding of Kubernetes. Which includes:
- First, you will get to know what Kubernetes is, and the benefits of using Kubernetes in application development.
- Second, you will understand the architecture of a Kubernetes Cluster and its components.
- And finally, you will have a basic understanding of several important concepts in Kubernetes
What is Kubernetes?
Kubernetes (also known as k8s) is a platform for automating deployment, scaling, and management of containerized applications. The applications can vary in sizes: from hundreds to thousands of nodes. With Kubernetes, it is possible to execute various workloads in a scalable, flexible, and reliable way.
Kubernetes’s primary responsibility is container orchestration. That means ensuring that all the containers that execute various workloads are scheduled to run on physical or virtual machines. Also, Kubernetes must keep an eye on all running containers and replace dead, unresponsive, or otherwise unhealthy containers.
Google initially developed Kubernetes in 2014, then joining the Cloud Native Computing Foundation (CNCF) in 2016. In 2018, Kubernetes Project reached ninth place in commits at Github.
You can deploy Kubernetes on a bare-metal cluster or a virtual machine cluster, our managed Kubernetes Service from major cloud provider likes:
Kubernetes was designed to give developers these benefits:
A Cluster is a collection of nodes that provide compute, memory, storage, and networking resources. An entire system may consist of multiple clusters.
A Node is a single physical or virtual machine. In some old documents, they were called minion.
There are two types of nodes in Kubernetes Cluster and each runs several components that we will discuss shortly.
Master (Control Plane)
Master can run on one node, but in a large cluster’s high availability setup, they may be run redundantly across multiple nodes.
Responsible for handling workload in the cluster. The worker node will include the following three main components:
Next, I’ll briefly introduce some important Kubernetes concepts. The goal is to get familiar with these terms and concepts. I will discuss them in detail in another dedicated article.
In Kubernetes, A Pod is an atomic unit of scheduling, deployment, and runtime isolation of one or multiple closely related containers.
Containers in the same Pod are always scheduled on the same node, and they share the same resources, such as filesystem, networking (IP and port space). Through a Pod can be rescheduled to a different node if the existing node is no longer healthy.
Your application lives in a Pod, but you don’t access Pod directly–that is where Service enters the scene.
In the most common scenario, Services represent a named entry-point for accessing your application. They are used to discover and load-balancing a Pods group by labels and enabling consumers to access them using the Service’s name. It allows scaling without affecting Service consumers.
You may also have ser that provide access to external resources outside of your Kubernetes Cluster.
Labels provide identifying metadata for objects. It enables users to organize and group various related objects in the Kubernetes cluster. Each object may have multiple labels, and each label may be applied to different objects—it’s an NxN relationship.
Label Selectors are used to filtering Kubernetes objects based on a set of labels.
Annotations primitive are similar to Labels. But they are intended for specifying nonsearchable metadata and for machine usage rather than human. They are not for querying and matching objects.
For example, We can use annotations for build IDs, release IDs, timestamps, Git branch names, etc.
ReplicaSet ensures to always run the correct type and number of Pods in the cluster. For example, if you want to run 4 Nginx servers without ReplicaSets, you will have to write 4 Pod Manifest files, that’s is troublesome.
In previous versions of Kubernetes, ReplicaSets was also known as ReplicaController.
ReplicaSets is designed for stateless applications (e.g., Nginx).
StatefulSets are similar to ReplicaSets but with some unique properties:
ConfigMap provides general-purpose key-value pairs of configuration data for workloads.
Once a ConfigMap is created and holding data, we can use the keys of a ConfigMap in two ways:
Secrets are similar to ConfigMap(the difference is Secrets use Base64 for data encoding) but focused on providing sensitive information for workloads.
For example, you can use Secrets to store MySQL DB Password, API Token, etc.,
Secrets enable container images to be created without bundling sensitive data. Secrets are exposed to Pods via declaring explicitly in Pod Manifest and Kubernetes API.
★ ConfigMap and Secrets are a great way to provide dynamic configuration for your application based on the context. Separating configuration from the application code will make your application more reliable and reusable.
Kubernetes uses namespaces to organize objects in the cluster. When you create a new Kubernetes Cluster, you will have a Namespace called “default” initially.
Your application has two environments: Development and Production. Then respectively, you can create two namespaces to isolate the resources of these two environments.
There is a point to note here:
By default, Pods in one namespace can access Pods and Services in another. So when you use a Namespace, you will need to set up a Network Policy to limit Kubernetes Cluster resources access between Namespaces.
In this article, we first described what Kubernetes is and its benefits. Following that, we studied the Kubernetes architecture with master and worker node components. Finally, we discussed some of Kubernetes’s primary concepts to help you before starting your journey into Kubernetes.
We will try to deploy a Kubernetes Cluster on public cloud provider GCP, AWS, and Azure in the next articles.