Merge branch 'main' into dev

anveshmuppeda · web-flow · commit 0278419d1fb3 · 2025-05-29T13:59:13.000-05:00
diff --git a/README.md b/README.md
@@ -197,6 +197,8 @@ Kubernetes, also known as K8s, is an open-source container orchestration platfor
 #### [4. A Hands-On Guide to AWS EKS Cluster with Managed Node Groups](./docs/eks-guides/004-eks-managed-node-group.md)
 #### [5. AWS Load Balancer Controller on EKS: A Comprehensive Guide](./docs/eks-guides/005-alb-controller.md)
 #### [6. Amazon EKS Auto Mode: A Hands-On Guide](./docs/eks-guides/006-eks-auto-mode.md)
+#### [7. Amazon EKS Kubecost: A Hands-On Guide](./docs/eks-guides/007-kubecost.md)
+#### [7. EKS Node Viewer: A Hands-On Guide](./docs/eks-guides/007-eks-node-viewer.md)
 
 ---
 
diff --git a/docs/012-troubleshoot/exit-code-0/exit-code-0.md b/docs/012-troubleshoot/exit-code-0/exit-code-0.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-0/exit-code-0.md
 sidebar_label: "Exit Code 0"
 sidebar_id: "exit-code-0"
-sidebar_position: 1
+sidebar_position: 2
 ---
 
 ## Exit Code 0: Successful Execution
diff --git a/docs/012-troubleshoot/exit-code-1/exit-code-1.md b/docs/012-troubleshoot/exit-code-1/exit-code-1.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-1/exit-code-1.md
 sidebar_label: "Exit Code 1"
 sidebar_id: "exit-code-1"
-sidebar_position: 1
+sidebar_position: 3
 ---
 
 ## Exit Code 1 in Kubernetes
diff --git a/docs/012-troubleshoot/exit-code-125/exit-code-125.md b/docs/012-troubleshoot/exit-code-125/exit-code-125.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-125/exit-code-125.md
 sidebar_label: "Exit Code 125"
 sidebar_id: "exit-code-125"
-sidebar_position: 1
+sidebar_position: 5
 ---
 
 ## Exit Code 125: Container Failed to Run Example in Kubernetes
diff --git a/docs/012-troubleshoot/exit-code-126/exit-code-126.md b/docs/012-troubleshoot/exit-code-126/exit-code-126.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-126/exit-code-126.md
 sidebar_label: "Exit Code 126"
 sidebar_id: "exit-code-126"
-sidebar_position: 1
+sidebar_position: 6
 ---
 
 ## Exit Code 126 in Kubernetes
diff --git a/docs/012-troubleshoot/exit-code-127/exit-code-127.md b/docs/012-troubleshoot/exit-code-127/exit-code-127.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-127/exit-code-127.md
 sidebar_label: "Exit Code 127"
 sidebar_id: "exit-code-127"
-sidebar_position: 1
+sidebar_position: 7
 ---
 
 ## Exit Code 127 in Kubernetes
diff --git a/docs/012-troubleshoot/exit-code-128/exit-code-128.md b/docs/012-troubleshoot/exit-code-128/exit-code-128.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-128/exit-code-128.md
 sidebar_label: "Exit Code 128"
 sidebar_id: "exit-code-128"
-sidebar_position: 1
+sidebar_position: 8
 ---
 
 ## Exit Code 128 in Kubernetes
diff --git a/docs/012-troubleshoot/exit-code-130/exit-code-130.md b/docs/012-troubleshoot/exit-code-130/exit-code-130.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-130/exit-code-130.md
 sidebar_label: "Exit Code 130"
 sidebar_id: "exit-code-130"
-sidebar_position: 1
+sidebar_position: 9
 ---
 
 ## Exit Code 130: Script Terminated by User (SIGINT)
diff --git a/docs/012-troubleshoot/exit-code-134/exit-code-134.md b/docs/012-troubleshoot/exit-code-134/exit-code-134.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-134/exit-code-134.md
 sidebar_label: "Exit Code 134"
 sidebar_id: "exit-code-134"
-sidebar_position: 1
+sidebar_position: 10
 ---
 
 ## Exit Code 134: Abnormal Termination (SIGABRT)
diff --git a/docs/012-troubleshoot/exit-code-137/exit-code-137.md b/docs/012-troubleshoot/exit-code-137/exit-code-137.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-137/exit-code-137.md
 sidebar_label: "Exit Code 137"
 sidebar_id: "exit-code-137"
-sidebar_position: 1
+sidebar_position: 11
 ---
 
 ## Exit Code 137: Container Killed (SIGKILL)
diff --git a/docs/012-troubleshoot/exit-code-139/exit-code-139.md b/docs/012-troubleshoot/exit-code-139/exit-code-139.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-139/exit-code-139.md
 sidebar_label: "Exit Code 139"
 sidebar_id: "exit-code-139"
-sidebar_position: 1
+sidebar_position: 12
 ---
 
 ## Exit Code 139: Segmentation Fault (SIGSEGV)
diff --git a/docs/012-troubleshoot/exit-code-141/exit-code-141.md b/docs/012-troubleshoot/exit-code-141/exit-code-141.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-141/exit-code-141.md
 sidebar_label: "Exit Code 141"
 sidebar_id: "exit-code-141"
-sidebar_position: 1
+sidebar_position: 14
 ---
 
 ## Exit Code 141: Broken Pipe (SIGPIPE)
diff --git a/docs/012-troubleshoot/exit-code-143/exit-code-143.md b/docs/012-troubleshoot/exit-code-143/exit-code-143.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-143/exit-code-143.md
 sidebar_label: "Exit Code 143"
 sidebar_id: "exit-code-143"
-sidebar_position: 1
+sidebar_position: 15
 ---
 
 ## Exit Code 143: Graceful Termination (SIGTERM)
diff --git a/docs/012-troubleshoot/exit-code-2/exit-code-2.md b/docs/012-troubleshoot/exit-code-2/exit-code-2.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-2/exit-code-2.md
 sidebar_label: "Exit Code 2"
 sidebar_id: "exit-code-2"
-sidebar_position: 1
+sidebar_position: 4
 ---
 
 ## Exit Code 2: Misuse of Shell Built-ins
diff --git a/docs/012-troubleshoot/exit-code-255/exit-code-255.md b/docs/012-troubleshoot/exit-code-255/exit-code-255.md
@@ -2,7 +2,7 @@
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/012-troubleshoot/exit-code-255/exit-code-255.md
 sidebar_label: "Exit Code 255"
 sidebar_id: "exit-code-255"
-sidebar_position: 1
+sidebar_position: 16
 ---
 
 ## Exit Code 255: Exit Status Out Of Range
diff --git a/docs/012-troubleshoot/troubleshoot.md b/docs/012-troubleshoot/troubleshoot.md
diff --git a/docs/deployment-strategies/blue-green.md b/docs/deployment-strategies/blue-green.md
@@ -9,15 +9,15 @@ sidebar_position: 1
 
 #### *⇢ A Hands-On Example with Deployment and Service Manifests*
 
-![img](./img/blue-green-deployment.png.webp)
-
+![Blue-Green Deployment](./img/blue-green-deployment.png.webp)
 
 #### Introduction:
 In the fast-paced world of software development, deploying updates and new features while maintaining uptime and minimizing risks is crucial. Blue-Green Deployment is a strategy that helps achieve this by reducing downtime and risk during deployments. In this guide, we’ll explore what Blue-Green Deployment is, its benefits, how it works, and a practical example using Kubernetes.
 #### What is Blue-Green Deployment?
 Blue-Green Deployment is a technique used to release software updates with minimal downtime and risk. In this approach, two identical environments, typically referred to as “blue” and “green,” are set up: one represents the currently live production environment (blue), while the other is a clone where the new version is deployed (green). Once the new version in the green environment is tested and ready, traffic is switched from blue to green, making the green environment the new production environment.
 
-![img](./img/blue-green-deployment-flowchart.png.webp) 
+
+![Blue-Green Deployment Flowchart](./img/blue-green-deployment-flowchart.png.webp)
 
 ### Benefits of Blue-Green Deployment:
 **Zero Downtime:** By having two identical environments, you can switch traffic seamlessly from one environment to another without any downtime.  
@@ -31,7 +31,8 @@ Blue-Green Deployment is a technique used to release software updates with minim
 **4. Switch Traffic:** Once testing is successful, reroute traffic from the blue environment to the green environment using load balancers or DNS changes.  
 **5. Monitoring:** Monitor the green environment closely to detect any issues that may arise after the switch.  
 **6. Rollback (if necessary):** If any issues occur post-deployment, quickly rollback by switching traffic back to the blue environment.  
-![img](./img/blue-green-deployment-animated-flowchart.png.gif) 
+
+![Blue-Green Deployment Animated Flowchart](./img/blue-green-deployment-animated-flowchart.png.gif)
 
 ### Real-Time Example:
 Let’s demonstrate Blue-Green Deployment with a practical example using Kubernetes. Consider a simple web application which display the pod name(so that it easy to test the traffic from where it is getting the response) with version 1.0. We’ll update it to version 2.0 using Blue-Green Deployment.
@@ -156,7 +157,9 @@ replicaset.apps/green-deploy-6c976bd585   3         3         3       15m
 ```
 Let’s try to access the application to verify the traffic and functionality.
 #### Testing-blue-application  
-![img](./img/testing-blue-applications.webp) 
+
+![blue-application](./img/testing-blue-applications.webp)
+
 
 Or we can use the below curl command to test the traffic:  
 ```yaml
@@ -199,7 +202,8 @@ These changes will upgrade the green environment to the newer version (**v2.0.0*
 With the newer version successfully deployed in the green environment and traffic routed from the blue environment, it’s time to test and monitor the new version.   
 Access the service endpoint to observe the behavior of the green deployment. In our scenario, the service endpoint prints the pod name of the environment, so it should now display the pod name of the green deployment.
 #### Testing-green-application
-![img](./img/testing-green-application.png.webp)  
+
+![green-application](./img/testing-green-application.png.webp)
 
 Or using curl command:
 
@@ -229,8 +233,8 @@ kubectl apply -f svc-manifest.yaml
 Once the service is routed to older version(v1.0.0 from Blue environment) then verify the traffic status:
 
 #### Rollout-older-version
-![img](./img/rollout-older-version.png.webp) 
 
+![Rollout-older-version](./img/rollout-older-version.png.webp)
 
 
 curl command output:
diff --git a/docs/deployment-strategies/canary.md b/docs/deployment-strategies/canary.md
@@ -12,7 +12,7 @@ sidebar_position: 2
 Canary deployment is a technique used to reduce the risk of introducing a new version of software into production by gradually rolling out the change to a small subset of users before making it available to the wider audience.
 In Kubernetes, canary deployments are achieved by running multiple versions of an application simultaneously and routing a portion of the traffic to the newer version while monitoring its performance. In this article, we’ll explore what canary deployment is, why it’s important, and how to implement it in Kubernetes using a practical example.
 
-![img](./img/canary-deployment.png.webp)
+![Canary Deployment](./img/canary-deployment.png.webp)
 
 
 ### Why Canary Deployment?
@@ -183,18 +183,15 @@ base-app-5dbddc57c5-n8l5q
 The output from the previous command shows that the curl command hits the older version (base application) 7 times and the newer version (canary application) 3 times.   
 
 **Old-version**
-![img](./img/old-version.png.webp) 
 
-**New-version**
-![img](./img/new-version.png.webp) 
+![Old-version](./img/old-version.png.webp)
 
+**New-version**
+![New-version](./img/new-version.png.webp)
 
 ***That’s it, we have successfully implemented Canary Deployment***
 ### Animated FlowChart
-![img](./img/canary-deployment-animated-flowchart.png.gif) 
-
-
-
+![Animated FlowChart](./img/canary-deployment-animated-flowchart.png.gif)
 
 
 
diff --git a/docs/deployment-strategies/rolling-and-recreate-update.md b/docs/deployment-strategies/rolling-and-recreate-update.md
@@ -9,7 +9,8 @@ sidebar_position: 3
 
 #### *✨ Choose the Right Strategy for Seamless Deployments*
 
-![img](./img/rolling-and-recreate-strategies.png.webp)
+
+![Rolling Update and Recreate Deployment Strategies](./img/rolling-and-recreate-strategies.png.webp)
 
 When deploying applications in Kubernetes, choosing the right deployment strategy is crucial for ensuring minimal downtime and smooth updates. Two common strategies are Rolling Updates and Recreate. In this blog post, we’ll explore these strategies, their differences, and how to configure them effectively.
 
@@ -24,10 +25,11 @@ Rolling update is the default deployment strategy in Kubernetes. It ensures that
 **2. Gradual Rollout:** It ensures that a specified number of new pods are available and healthy before terminating old ones.   
 **3. Controlled Progress:** The rollout is managed by controlling parameters like maxUnavailable and maxSurge. 
 ### Flow-chart  
-![img](./img/deployment-strategies.png.webp) 
+
+![Deployment Strategies](./img/deployment-strategies.png.webp)
 
 ### Animated Flowchart  
-![img](./img/deployment-strategies-animated-flowchart.png.gif) 
+![Deployment Strategies Animated Flowchart](./img/deployment-strategies-animated-flowchart.png.gif)
 
 #### Parameters:
 **maxUnavailable:** Specifies the maximum number or percentage of pods that can be unavailable during the update. Default is 25%. This means that during the update, at least 75% of the desired number of pods must be available.   
diff --git a/docs/eks-guides/006-eks-auto-mode.md b/docs/eks-guides/006-eks-auto-mode.md
@@ -1,7 +1,7 @@
 ---
 // filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/eks/006-eks-auto-mode.md
 sidebar_label: "EKS Auto Mode"
-sidebar_position: 5
+sidebar_position: 6
 ---  
 # Amazon EKS Auto Mode: A Hands-On Guide
 #### *Automate compute, networking, and storage in your Kubernetes clusters with step-by-step instructions.*
diff --git a/docs/eks-guides/007-kubecost.md b/docs/eks-guides/007-kubecost.md
@@ -0,0 +1,138 @@
+---
+// filepath: /Users/anveshmuppeda/Desktop/anvesh/tech/git/kubernetes/docs/eks/007-kubecost.md
+sidebar_label: "Kubecost"
+sidebar_position: 7
+---  
+
+# Amazon EKS Kubecost: A Hands-On Guide
+#### *Monitor and optimize your Kubernetes costs with step-by-step instructions.*
+
+Here’s a concise guide covering what Kubecost is, why you’d use it, and exactly how to install, access, and uninstall it on Amazon EKS (without mentioning specific version numbers).
+
+![Kubecost](./img/kubecost.gif)
+
+### **Summary**  
+[Kubecost](https://github.com/kubecost) is an open‑core tool that provides real‑time visibility into your Kubernetes spending—breaking down costs by cluster, namespace, pod, node, and label—to help teams allocate, optimize, and continuously reduce cloud costs. You can deploy it on Amazon EKS either as an AWS‑managed add‑on or via Helm, then port‑forward or expose its dashboard to visualize and manage your spend. When you’re done, you can remove it cleanly with a single CLI command or Helm uninstall sequence.
+
+## What is Kubecost and Why Use It
+
+Kubecost provides real‑time cost visibility and insights for teams running Kubernetes, helping you continuously reduce your cloud spend by surfacing where costs occur and suggesting optimizations.
+It breaks down your bill by cluster, namespace, pod, node, persistent volume, and custom labels—enabling charge‑back, show‑back, and right‑sizing across teams or projects.
+
+## Installing Kubecost
+
+### 1. As an Amazon EKS Add‑on
+
+**Prerequisites**
+
+* Subscribe to “[Kubecost – Amazon EKS cost monitoring](https://aws.amazon.com/marketplace/seller-profile?id=983de668-2731-4c99-a7e2-74f27d796173)” in the AWS Marketplace.
+* Have `kubectl`, the AWS CLI, and access to your EKS cluster. 
+
+**Install using AWS CLI**
+
+```bash
+aws eks create-addon \
+  --addon-name kubecost_kubecost \
+  --cluster-name YOUR_CLUSTER_NAME \
+  --region YOUR_REGION
+```
+![Kubecost EKS Add-on](./img/kubecost-addon.png)
+
+**Install using CFT**
+
+Use the [AWS CloudFormation template - Kubecost](./cloudformation/eks-kubecost.yaml) to deploy the 
+IBM Kubecost - Amazon EKS cost monitoring add‑on. 
+
+
+This deploys the AWS‑optimized Kubecost bundle, complete with built‑in Prometheus and kube‑state‑metrics.
+
+### 2. With Helm
+
+**Prerequisites**
+
+* Install `kubectl`, Helm 3+, and access to your EKS cluster (plus the Amazon EBS CSI driver). 
+
+**Install**
+
+1. Add the Kubecost Helm repo
+
+   ```bash
+   helm repo add kubecost https://kubecost.github.io/cost-analyzer/
+   helm repo update
+   ```
+2. Install the Kubecost Helm chart
+
+   ```bash
+   helm install kubecost kubecost/cost-analyzer -n kubecost --create-namespace \
+    --set kubecostToken="aGVsbUBrdWJlY29zdC5jb20=xm343yadf98"
+   ```
+   kubecostToken, it is generated at http://kubecost.com/install, used for alerts tracking and free trials. 
+   Or you can use the following command to install the latest version of Kubecost:
+
+    ```bash
+    helm upgrade -i kubecost \
+        oci://public.ecr.aws/kubecost/cost-analyzer \
+        --namespace kubecost --create-namespace \
+        -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml
+    ```
+
+This drops in Kubecost along with its required dependencies; you can further customize via additional Helm values.
+
+## Using Kubecost
+
+1. **Verify pods are running**
+
+   ```bash
+   > kubectl get pods -n kubecost
+    NAME                                         READY   STATUS    RESTARTS   AGE
+    kubecost-cost-analyzer-ff44d778f-lsgrh       4/4     Running   0          5m16s
+    kubecost-forecasting-56475fdf55-jwb26        1/1     Running   0          5m16s
+    kubecost-prometheus-server-bb875b789-zd6d9   1/1     Running   0          5m16s
+   ```
+2. **Expose the dashboard**
+
+   ```bash
+   > kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090
+    Forwarding from 127.0.0.1:9090 -> 9090
+    Forwarding from [::1]:9090 -> 9090
+    Handling connection for 9090
+    Handling connection for 9090 
+   ```
+3. **Browse the UI**
+   Open [http://localhost:9090](http://localhost:9090) in your browser to view cost allocations, asset spend, and efficiency insights .
+
+## Uninstalling Kubecost
+
+### Remove the EKS Add‑On
+
+```bash
+aws eks delete-addon \
+  --addon-name kubecost_kubecost \
+  --cluster-name YOUR_CLUSTER_NAME \
+  --region YOUR_REGION
+``` 
+
+### Remove the CloudFormation Stack
+
+```bash
+aws cloudformation delete-stack \
+  --stack-name YOUR_STACK_NAME
+```
+This removes the Kubecost add‑on and all associated resources.
+
+### Uninstall the Helm Release  
+```bash
+helm uninstall kubecost --namespace kubecost
+kubectl delete namespace kubecost
+```
+
+---
+
+With this guide, you can quickly set up Kubecost for cost visibility in your EKS clusters, explore your spending through a live dashboard, and remove it cleanly when it’s no longer needed.  
+
+---
+## Additional Resources
+* [Kubecost Documentation](https://docs.kubecost.com/)
+* [Kubecost GitHub](https://github.com/kubecost)
+* [Kubecost on AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=983de668-2731-4c99-a7e2-74f27d796173)
+* [Kubecost on AWS Blog](https://docs.aws.amazon.com/eks/latest/userguide/cost-monitoring-kubecost.html)
diff --git a/docs/eks-guides/008-eks-node-viewer.md b/docs/eks-guides/008-eks-node-viewer.md
diff --git a/docs/eks-guides/cloudformation/eks-kubecost.yaml b/docs/eks-guides/cloudformation/eks-kubecost.yaml
diff --git a/docs/eks-guides/img/eks-node-viewer.gif b/docs/eks-guides/img/eks-node-viewer.gif
diff --git a/docs/eks-guides/img/kubecost-addon.png b/docs/eks-guides/img/kubecost-addon.png
diff --git a/docs/eks-guides/img/kubecost.gif b/docs/eks-guides/img/kubecost.gif
diff --git a/k8swebsite.config.ts b/k8swebsite.config.ts
diff --git a/src/pages/index.tsx b/src/pages/index.tsx
