Replicaset and Deployment

content/posts/deployment/index.md

@@ -0,0 +1,83 @@
+---
+weight: 1
+title: Kubernetes Deployment
+date: 2024-10-18T20:38:04+05:30
+type: posts
+author:
+  name: Nikhil Sihora
+  link: https://www.linkedin.com/in/nik-sihora/
+description:
+resources:
+  - name: 
+    src: kubernetes.png
+tags:
+  - kubernetes
+categories:
+  - kubernetes
+lightgallery: true
+reward: false
+toc:
+  auto: false
+---
+
+![kubernetes-deployment](kubernetes-deployment.png)
+- **Provides the capability to upgrade the instances seamlessly using rolling updates, rollback to previous versions seamlessly, undo, pause and resume changes as required.**
+- Abstraction over [ReplicaSet](/posts/replicaset/index.md).
+- **Blueprint for stateless pods** (application layer).
+- When a deployment is created, it automatically creates a [ReplicaSet](/posts/replicaset/index.md) which in turn creates pods. If we run `k get all` we can see the resources created by deployment.
+
+# Config YAML file
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: httpd-frontend
+  labels:
+    name: frontend
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      name: frontend
+  template:
+    metadata:
+      labels:
+        name: frontend
+    spec:
+      containers:
+      - name: httpd
+        image: httpd:2.4-alpine
+```
+
+{{< admonition type=tip title="" open=true >}}
+⛔ Update the `kind` from `Replicaset` to `Deployment` in a `Replicaset` config file.
+{{< /admonition >}}
+
+# Deployment Strategy
+
+![kubernetes-deployment-stratergy](kubernetes-deployment-stratergy.png)
+
+There are two deployment strategies:
+
+- **Recreate**: Bring down all the running containers and then bring up the newer version (application downtime)
+- **Rolling Update** (default): Bring down a container and then bring up a new container one at a time (no application downtime)
+
+# Rollout and Versioning
+
+- When you first create a deployment, it triggers a rollout which creates the first revision of the deployment. Every subsequent update to the deployment triggers a rollout which creates a new revision of the deployment. This keeps a track of the deployment and helps us rollback to a previous version of the deployment if required.
+- **When we upgrade the version of a deployment, a new replica set is created** under the hood where the new pods are spawned while bringing down pods from the old replica set one at a time, following a rolling update strategy. We can see the new and old replica sets by running `k get replicasets`
+
+    ![kubernetes-deployment-rollout](kubernetes-deployment-rollout.png)
+
+- `k rollout status deployment <deployment-name>` - view the status of rollout for a deployment
+- `k rollout history deployment <deployment-name>` - view the history of rollouts for a deployment
+- `k rollout history deployment <deployment-name> --revision=1` - view the status of rollouts for a deployment revision
+
+# Rollback
+
+- When we rollback to the previous version of a deployment, the pods in the current replica set are brought down one at a time while spawning pods in the previous replica set.
+- Rollback a deployment - `k rollout undo deployment <deployment-name>`
+- Rollback a deployment to a specific revision - `k rollout undo deployment <deployment-name> --to-revision=1`
+
+    ![kubernetes-deployment-rollback](kubernetes-deployment-rollback.png)

content/posts/kubernetes-node/index.md

@@ -1,41 +1,24 @@
 ---
+weight: 1
 title: Kubernetes Node
-subtitle:
 date: 2024-05-10T12:05:51+05:30
-slug: 
-draft: false
+type: posts
 author:
   name: Nikhil Sihora
   link: https://www.linkedin.com/in/nik-sihora/
-  email:
-  avatar:
-description: 
-keywords:
-license:
-comment: false
-weight: 0
+description:
+resources:
+  - name: 
+    src: kubernetes.png
 tags:
   - kubernetes
 categories:
   - kubernetes
-hiddenFromHomePage: false
-hiddenFromSearch: false
-hiddenFromRss: false
-hiddenFromRelated: false
-summary:
-resources:
-  - name: featured-image
-    src: kubernetes.png
-toc: true
-math: false
-lightgallery: false
-password:
-message:
-repost:
-  enable: true
-  url:
+lightgallery: true
+reward: false
+toc:
+  auto: false
 ---
-<!--more-->
 
 - Kubernetes is an open-source **container orchestration** tool developed by Google.
 - It helps us manage containerized applications in different deployment environments.

content/posts/kubernetes-pod/index.md

@@ -8,7 +8,7 @@ author:
   link: https://www.linkedin.com/in/nik-sihora/
 description:
 resources:
-  - name: featured-image
+  - name: 
     src: kubernetes.png
 tags:
   - kubernetes
@@ -20,7 +20,6 @@ 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.

content/posts/replicaset/index.md

@@ -0,0 +1,64 @@
+---
+weight: 1
+title: Kubernetes Replicaset
+date: 2024-10-18T20:38:04+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
+---
+![kubernetes-replicaset](/posts/deployment/kubernetes-deployment.png)
+- ReplicaSet monitors and maintains the number of replicas of a given pod. It will automatically spawn a new pod if the pod goes down.
+- It is needed even if we only have a single pod, because if that pod dies, replica set will spawn a new pod.
+- It spans the entire cluster to spawn pods on any node.
+
+{{< admonition type=tip title="" open=true >}}
+⛔ Newer and better way to manage replicated pods in Kubernetes than Replication Controllers
+{{< /admonition >}}
+
+# Simple Config for a Replicaset
+
+```yml
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+  name: httpd-frontend
+  labels:
+    name: frontend
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      name: frontend
+  template:
+    metadata:
+      labels:
+        name: frontend
+    spec:
+      containers:
+      - name: httpd
+        image: httpd:2.4-alpine
+```
+
+- `template` → `metadata` and `spec` from the config file for the pod (required to spawn new pods if any of them goes down)
+- `replicas` → how many replicas to maintain
+- It has an additional required field `selector` which allows the replica set to select pods that match specific labels. This way **the replicaset can manage pods that were not created by it.**
+
+## Scaling the number of replicas
+
+- **Recommended**: edit the config file and re-apply - `k apply -f config.yaml`
+    - Scaling changes can be easily tracked using Git
+- **Not recommended**: using `kubectl` - `k scale replicaset my-replicaset --replicas=2`
+    - This will not update the config file, so changes are hard to track