Kubernetes pods blog + some adjustments

content/about.md

@@ -38,6 +38,7 @@ I am passionate about learning new skills and staying updated with the latest tr
   {{< raw >}}
   <div style="padding: 10px; text-align: center;">
   <div data-iframe-width="200" data-iframe-height="270" data-share-badge-id="d6b00133-6cab-4217-9ea9-503911ea0fa6" data-share-badge-host="https://www.credly.com"></div><script type="text/javascript" async src="//cdn.credly.com/assets/utilities/embed.js"></script>
+  <div data-iframe-width="150" data-iframe-height="270" data-share-badge-id="66119e3b-16a9-4405-9495-695937f9757e" data-share-badge-host="https://www.credly.com"></div><script type="text/javascript" async src="//cdn.credly.com/assets/utilities/embed.js"></script>
   <div data-iframe-width="200" data-iframe-height="270" data-share-badge-id="32522a75-fd4e-4da7-93d9-cdaa5572f24a" data-share-badge-host="https://www.credly.com"></div><script type="text/javascript" async src="//cdn.credly.com/assets/utilities/embed.js"></script>
   <div data-iframe-width="200" data-iframe-height="270" data-share-badge-id="8114b252-9fa1-4f6d-b79a-82d2db5a1de5" data-share-badge-host="https://www.credly.com"></div><script type="text/javascript" async src="//cdn.credly.com/assets/utilities/embed.js"></script>
   <div data-iframe-width="200" data-iframe-height="270" data-share-badge-id="f86e1607-998e-43f3-9c1f-7c58638bb661" data-share-badge-host="https://www.credly.com"></div><script type="text/javascript" async src="//cdn.credly.com/assets/utilities/embed.js"></script>

content/posts/kubernetes-node/index.md

@@ -5,8 +5,8 @@ date: 2024-05-10T12:05:51+05:30
 slug: 
 draft: false
 author:
-  name: Niksihora
-  link:
+  name: Nikhil Sihora
+  link: https://www.linkedin.com/in/nik-sihora/
   email:
   avatar:
 description: 
@@ -34,71 +34,76 @@ message:
 repost:
   enable: true
   url:
-
-# See details front matter: https://fixit.lruihao.cn/documentation/content-management/introduction/#front-matter
 ---
 <!--more-->
+
+- Kubernetes is an open-source **container orchestration** tool developed by Google.
+- It helps us manage containerized applications in different deployment environments.
+
+## Container Orchestration
+
+- The automated deployment and management of containers is called **container orchestration**.
+- Containers act as perfect hosts for micro-services (running independently).
+- The rise of micro-services architecture led to applications using 1000s of containers that need to be smartly managed.
+- Container orchestration offers:
+    - **High Availability** (no downtime)
+    - **Horizontal Scalability**
+    - **Disaster Recovery**
+    - **And so much more..**
+
 # Kubernetes Node
-- A physical or virtual machine on which Kubernetes is installed
+- A physical or virtual machine on which Kubernetes is installed.
 - **Nodes are cluster scoped. They are not scoped within a namespace.**
 - When you install Kubernetes on a node, the following components are installed. Some of them are used in worker nodes and the rest are used in master nodes.
-    - API Server
+    - Kube API Server
     - `etcd` Service
     - Kubelet Service
-    - Container Runtime
-    - Controller
-    - Scheduler
+    - Container Runtime (Docker Engine, CRI-O, containerd)
+    - Kube Controller
+    - Kube Scheduler
 - A **cluster** is a collection of nodes grouped together
 
 ## Worker Nodes
-
 ![worker-node](/posts/kubernetes-node/worker-node.png)
 
-- These nodes do the actual work so they need to have more resources
-- Each worker node has multiple pods running on it
-- 3 processes must be installed on every worker node
-    - **Container Runtime** (eg. docker)
+- These nodes do the actual work so they need to have more resources.
+- Each worker node can have multiple pods running on it.
+- 3 processes must be installed on every worker node.
+    - **Container Runtime** (eg. Docker Engine, CRI-O, containerd)
     - **Kubelet**
         - process of Kubernetes
         - starts pods and runs containers inside them
         - allocates resources from the node to the container
     - **Kubeproxy**
         - process of Kubernetes
         - forwards the requests to pods intelligently
-        - Image
-            - Kubeproxy forwards requests to the DB pod running on the same node to minimize network overhead.
+        - Example: Kubeproxy forwards requests to the DB pod running on the same node to minimize network overhead.
+![kube-proxy](/posts/kubernetes-node/kube-proxy.png)
 
-                ![kube-proxy](/posts/kubernetes-node/kube-proxy.png)
-
-
 ## Master Nodes
-
 ![master-node](/posts/kubernetes-node/master-node.png)
 
 - Control the cluster state & manage worker nodes
-- Need less resources as they don't do the actual work
+- Need less resources as they typically only run core components of kubernetes
 - Multi-master setup is often used for fault tolerance
 - 4 processes run on every master node
-    - **API Server**
-        - User interacts with the cluster via the API server using a client (Kubernetes Dashboard, CLI, or Kubernetes API)
-        - Cluster gateway (acts as the entry point into the cluster)
-        - Can be used for authentication
-
+  - **Kube API Server**
+      - User interacts with the cluster via the Kube API server using a client (Kubernetes Dashboard, CLI, or Kubernetes API)
+      - Cluster gateway (acts as the entry point into the cluster)
+      - Can be used for authentication     
         ![kube-apiserver](/posts/kubernetes-node/kube-apiserver.png)
 
-    - **Scheduler**
-        - Decides the node where the new pod should be scheduled and sends a request to the Kubelet to start a pod.
-
+  - **Kube Scheduler**
+      - Decides the node where the new pod should be scheduled and sends a request to the Kubelet to start a pod.
         ![kube-scheduler](/posts/kubernetes-node/kube-scheduler.png)
 
-    - **Controller**
-        - Detects state changes like crashing of pods
-        - If a pod dies, it requests scheduler to schedule starting up of a new pod
-
+  - **Kube Controller**
+      - Detects state changes like crashing of pods
+      - If a pod dies, it requests scheduler to schedule starting up of a new pod
         ![kube-controller](/posts/kubernetes-node/kube-controller.png)
 
-    - **etcd**
-        - Key-value store of the cluster state (also known as cluster brain)
-        - Cluster changes get stored in the etcd
-        - In multi-master configuration, etcd is a distributed key-value store
-        - Application data is not stored in the etcd
+  - **etcd**
+    - Key-value store of the cluster state (also known as cluster brain)
+    - Cluster changes get stored in the etcd
+    - In multi-master configuration, etcd is a distributed key-value store
+    - Application data is not stored in the etcd

content/posts/kubernetes-pod/index.md

@@ -0,0 +1,104 @@
+---
+weight: 1
+title: Kubernetes Pod
+date: 2024-06-14T16:27:15+05:30
+type: posts
+author:
+  name: Nikhil Sihora
+  link: https://www.linkedin.com/in/nik-sihora/
+description:
+resources:
+  - name: featured-image
+    src: kubernetes.png
+tags:
+  - kubernetes
+categories:
+  - kubernetes
+lightgallery: true
+reward: false
+toc:
+  auto: false
+---
+
+<!--more-->
+- Kubernetes doesn’t run containers directly on the nodes. Every container is encapsulated by a pod.
+- Smallest unit of computing Kubernetes.
+- A pod is a single instance of an application. If another instance of the application needs to be deployed, another pod is deployed with the containerized application running inside pod.
+- Pods are epheremeral resources, meaning that Pods can be terminated at any point and then restarted on another node within our Kubernetes cluster.
+- Creates a running environment over the container so that we only interact with the Kubernetes layer. This allows us to replace the container technology like Docker.
+- **Each pod gets an internal IP address** for communicating with each other (virtual network created by K8).
+- If a pod is restarted (maybe after the application running on it crashed), its IP address may change.
+
+![kubernetes-pod](/posts/kubernetes-pod/kubernetes-pod.png)
+
+{{< admonition type=tip title="" open=true >}}
+
+⛔ Sometimes we need to have a helper container for the application container. In that case, we can run both containers inside the same pod. This way both containers share the same storage and network and can reference each other as `localhost`.
+
+Without using Pods, making a setup like this would be difficult as we need to manage attaching the helper containers to the application containers and kill them if the application container goes down.
+
+Although, most use cases of pods revolve around single containers, it provides flexibility to add a helper container in the future as the application evolves.
+![kubernetes-pod-multi-container](/posts/kubernetes-pod/kubernetes-pod-multi-container.png)
+
+{{< /admonition >}}
+
+# Simple Config for a Pod
+
+```yml
+apiVersion: v1
+kind: Pod
+metadata:
+  labels:
+    name: webserver
+spec:
+  containers:
+	  - name: httpd
+	    image: httpd:latest
+```
+
+- `apiVersion` Which version of the Kubernetes API we're using to create this object. You can read more about API versioning in Kubernetes [here](https://kubernetes.io/docs/reference/using-api/#api-versioning).
+
+- `kind` This defines what kind of Kubernetes object we want to create.
+
+- `metadata` This is data that helps us uniquely identify the object that we want to create. Here we can provide a name for our app, as well as apply labels to our object.
+
+- `spec` This defines the state that we want or our object. The format that we use for spec. For our Pod file, we have provided information about the containers that we want to host on our Pod.
+
+To see what else we can define in our Pod YAML file, this [documentation from Kubernetes](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) will help you.
+
+- With kubectl, we can create a Pod using our YAML definition using below command:
+
+```bash
+kubectl apply -f pod_defination.yaml
+```
+
+We can list all of our Pods using below command:
+
+```bash
+kubectl get pods
+```
+
+#### Restart Policy
+
+The default behavior of K8s is to restart a pod if it terminates. This is desirable for long running containers like web applications or databases. But, this is not desirable for short-lived containers such as a container to process an image or run analytics.
+
+`restartPolicy` allows us to specify when K8s should restart the pod.
+
+- `Always` - restart the pod if it goes down (default)
+- `Never` - never restart the pod
+- `OnFailure` - restart the pod only if the container inside failed (returned non zero exit code after execution)
+
+# Config of `restartPolicy` usage
+
+```yml
+apiVersion: v1
+kind: Pod
+metadata:
+  labels:
+    name: process
+spec:
+  containers:
+	  - name: analytics
+	    image: analytics
+	restartPolicy: Never
+```