Head to the basics of Kubernetes now
What are Nodes and how does a Kubernetes cluster look like?
Basics
A kubernetes cluster consists of multiple items. A pod is the smallest unit of a Kubernetes cluster and can contain multiple containers.
Kubernetes also has nodes. A node contain multiple pods, and has its own resources.
The above diagram from taken from this post.
A cluster is a collection of nodes.
Kubernetes has two types of Nodes :
Master Node : The master node is responsible for cluster management and providing API to configure and manage resources within the Kubernetes cluster.
When a new pod is created, it is assigned a default scheduler if one is not specified. The scheduler then evaluates the pod's scheduling requirements, such as the required CPU and memory resources, and attempts to find a suitable node to run the pod. If a node is found that meets the pod's requirements, the scheduler assigns the pod to that node.
Worker Node :
Kubelet is a node-level agent that works on each worker node and communicates with the master node to make sure that the containers running on the node are healthy and aligned with the desired state of the system.
A kubelet has some major responsibilities :
Responsible for maintaining containers running on the node. It works in conjunction with the container runtime (such as Docker) to ensure that containers are properly started, stopped or restarted as needed. Also monitors the health of the containers and takes appropriate action if a container fails or becomes unresponsive.
Kubelet also registers the node with the Kubernetes API server when it starts up. This includes providing information about the resource requirements(such as memory and CPU) and other information like node’s IP address.
Kubelet also pulls container images from the configured container image registry (such as Docker Hub or a private registry).
Service :
Each pod in a cluster is assigned an IP address (that is how they communicate with each other). But, Pods die and are re-created all the time. A service in Kubernetes acts as a stable endpoint for accessing a set of pods, even as those pods are created or destroyed. Services can be created for different purposes, such as load balancing, service discovery and routing.
When a service is created, it gets assigned a unique IP address, and clients can access the service using this IP address.
Without Service
With Service
ReplicaSet :
A Kubernetes object that ensures that a specific number of replicas of a pod are running at any given time. Replicaset allows you to define the desired number of pod replicas and Kubernetes will automatically ensure that the actual number of running pods match the desired number, by creating or deleting pods as necessary.
Ingress :
Imagine you were the Batman. And you maintained a website where you can order a batcave, track the joker.
The different URL’s your service used would be :
http://batcave.com/track-joker
http://batcave.com/monitor-batcave
http://batcave.com/order-new-batsuit
Without Ingress
Without having a URL based division of requests, we would need to have separate load balancer for each of the service. Maintaining a separate load balancer for each service is a difficult task. Also, there is no URL based routing present. Imagine what would happen if the number of routing paths increases.
HELP ALFRED!!!!!!
This is where Ingress comes into picture.
With Ingress
An ingress in Kubernetes is a resource that manages the routing of external HTTP(S) traffic to Kubernetes services. It routes traffic based on the request’s path or hostname.
ConfigMaps and Secrets :
Imagine a Pod that contains application logic. This pod now needs to connect to a database and fetch some records. Ideally, the database url is stored at service end, but if we change the name/url for the database, we will have to rebuild the entire app. Worse, think about passwords and usernames to the application. They change so frequently and storing them at the service end is a disaster. How about creating separate files to store these configurations. Well, here comes ConfigMaps and Secrets.
ConfigMaps are files used to store the external configuration for your application, for example, the database name here.
Similarly, to store usernames/passwords, Kubernetes provides another component called Secrets.
Secrets are by default stored unencrypted in the API server’s underlying data store(etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. It is the developer's responsibility to enable encryption.
Namespaces :
Namespaces are a way to separate and organize objects in a K8s cluster.
Namespaces are created at cluster level, not at pod or worker node level. A namespace created in Kubernetes can be accessed by any node in the cluster. All resources created within that namespace will be associated with that namespace and will be isolated from resources in other namespaces. Think of namespaces as a way to divide a Kubernetes cluster into multiple virtual clusters.
By default, K8s provides 4 names, out of which ‘default’ namespace is the one where resources that we create are stored, unless a custom namespace is created.
Think of namespaces as directories where files are stored. You would want to store files related to a topic A at a separate place than files related to topic B.
Creating separate namespaces for separate topics allows separation of concern, and faster development.
Another advantage of using namespaces is that it helps deal with conflicts. Consider a K8s cluster that has two applications with the same name. Without namespace, a team updating the file might override the configuration of the previous deployment by another team if both the applications are within a single namespace. Having them in separate namespaces provides logical separation of concern and prevents conflicts.
Worker nodes run pods, and pods are deployed in a namespace. Each worker node can run multiple pods, and each pod is associated with a particular namespace. This allows for logical separation between different applications or projects running in the same Kubernetes cluster, while still allowing them to share the same physical resources provided by the worker nodes.
More posts in this series :
Post 1 : Inside Kubernetes : Explaining Kubernetes to a 10 year old
Thanks for the heads up!