Kubernets Simplified 🥋

Towards the Kubernets Learning Journey, you'll miss so much info would be crucial to know.

Having a rudimentary grasp of Docker and containers, I will illustrate the noteworthy characteristics of Kubernetes. This is from the perspective of the typical consumer.

Kubelet : is a procedure which operates on every node of the cluster. It interacts with the master server, obtains a listing of containers to implement, and administers, controls and notifies the master server of the state of those containers.

Pods: The foundation element for managing and scheduling within Kubernetes. A Pod comprises of a grouping of containers which are run all together on a single node. The containers in such a Pod are connected with one another through a shared IP address and software for communications, yet are kept distinct from one another.

Containerization: A Docker container provides an isolated process space and the ability to expose ports, specify environment variables, and set a run command. These containers can link to storage from the host, a cloud volume, or any other storage origin. Additionally, CPU and memory limits can be imposed on the container to ensure it does not take up excessive resources from the node it is running on. Regarding health checks, kubelet will automatically perform them to determine if the container is operational and ready. Should a container fail its LivenessProbe, it will be restarted by kubelet. Conversely, in the event of a ReadinessProbe failure, Kuberenetes will remove the container from the Service it is part of.

Deployment : is a tool for managing an array of matching pods. All pods within the Deployment execute the same code, albeit implemented on separate nodes. The Deployment is designated with a predefined amount of replicas to keep up, implying that in the event of a pod or node malfunction, Kubernetes will automatically allocate and make arrangements for a substitute pod. Whenever a Deployment is modified, Kubernetes utilizes a RollingUpdateStrategy to gradually deploy the new version while simultaneously excising ancient pods.

Service : is an abstraction that allows a client to communicate with any one of a set of identical pods (usually within a Deployment). On creating a Service, Kubernetes assigns a cluster internal DNS name and IP address to it. This way, a client can use a single DNS name or IP address to connect to any healthy pod without knowing which node the pod is running on. Services can be of three types- ClusterIP, NodePort and LoadBalancer. A ClusterIP operates as a virtual IP address which is only accessible internally in the Kubernetes cluster. It comes with a DNS name that can be utilized by clients inside the cluster as a hostname to access the service. NodePort Service, in addition to having a ClusterIP, exposes the same port externally on all nodes in the cluster and forwards traffic to the ClusterIP. This form of Service is utilized to make Kubernetes services accessible to clients outside the cluster, who can avail it through any node on the NodePort. Finally, a LoadBalancer service offers an actual LoadBalancer in cloud providers (for instance in AWS ELB, GCP LB, or Azure LB) which can proxy requests to a NodePort service.

Namespaces: are logical divisions of applications or environments. Objects such as Deployments, Pods and Services function within a particular namespace. Clients are able to create their own namespaces too. The cluster will contain a pre-built “default” namespace as well as a “kube-system” namespace, designed for cluster management items, such as the Kubernetes scheduler and kube-dns pods.

ReplicationController: A not-so-frequently utilized abstraction concerning a cluster of like pods. It is similar to a Deployment, yet it lacks certain characteristics, notably those of RollingUpdate and rollback.

A StatefulSet : is akin to a Deployment, though more modern. As opposed to the latter, a StatefulSet assigns each one of its replicas a singular identity, as a result enabling them to be tailored and managed individually. These sets of pods are highly effective when they necessitate a dependable, long-term storage to remain intact, regardless of pod scale-ups or restarts, as it is the case with Cassandra, Mongo, or Kafka. The differences between Deployment pods and StatefulSet ones are easily distinguishable, with the latter having particular qualities such as a special numeric identifier and a fixed scaling up and scaling down pattern. Consequently, whilst a Deployment will randomly manufacture pods, a StatefulSet will always generate them in the arranged order: pod-1, pod-2, pod-3 and inversely discard them when downsizing.

Ingress : is an object that dictates regulations for handling HTTP communications that enter a Kubernetes cluster. Such an Ingress is typically employed for a variety of purposes, including sharing ports 80 and 443 among numerous services, directing HTTP host or path-based traffic to diverse services, and terminating SSL. An IngressController, which is a pod, manages and deploys these rules to pods that deal with the traffic. The Ingress is commonly implemented by different IngressControllers, the most prevalent one being the nginx IngressController.

ConfigMap : is a form of key-value storage that is utilized to store configuration data. A container can source any key-value pair from a ConfigMap found in the same namespace. An entry from a ConfigMap can also be accessed by a container as an environment variable or as an entire volume mount. Any modifications to a ConfigMap are automatically reflected in pods that use a volume mount.

Secret: Very similar to a ConfigMap, but will support encryption in the future.

However,There are numerous other essential concept areas that require examination, such as those related to particular cloud services, networking, safeguards, data warehousing, coordination, API consumers, system administrators, and the inner workings of Kubernetes.