DEV Community: Ibrahim Cisse

Enabling HTTP-based Autoscaling in GKE with KEDA HTTP Add-on

Ibrahim Cisse — Mon, 10 Feb 2025 08:17:05 +0000

In this article, I will walk through the journey of setting up KEDA (Kubernetes Event-Driven Autoscaler) with the HTTP Add-on in Google Kubernetes Engine (GKE). The goal was to scale a Python-based Rock-Paper-Scissors application based on incoming HTTP traffic. Along the way, I faced several challenges with cluster resource limits, scaling issues, and the limitations of the HTTP Add-on in KEDA, which I tackled through various strategies. This article details the steps, challenges, solutions, and configurations used during the process.

Steps Taken:

1. Creating the GKE Cluster with Two Nodes

The first step was to create a Kubernetes cluster in GKE. This cluster would host the Rock-Paper-Scissors application and later be configured for autoscaling using KEDA.

gcloud container clusters create my-cluster \
    --zone us-central1-a \
    --num-nodes 2

This created a GKE cluster with 2 nodes, providing enough resources for the application. After the cluster was created, I connected to the cluster using kubectl.

2. Installing KEDA with Server-Side Apply

I installed KEDA in the cluster using server-side apply due to an issue with the CRD YAML being too large, which was putting unnecessary load on the etcd component.

kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-operator.yaml

Using server-side apply ensures that the cluster resources are managed in an efficient and non-blocking way. The KEDA operator was successfully installed, and I proceeded to install the necessary ScaledObject for my application.

3. Installing and Confirming ScaledObject

Once KEDA was installed, the next step was to deploy a ScaledObject. A ScaledObject defines the scaling rules for the application based on event sources. Here’s the initial YAML configuration for ScaledObject:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rock-paper-scissors-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    kind: Deployment
    name: rock-paper-scissors
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
    - type: http-add-on
      metadata:
        endpoint: "/"

I confirmed that the ScaledObject was running correctly using kubectl get scaledobjects.

4. Sending HTTP Load and Scaling Issues

Next, I tried sending HTTP load to the application using curl, but the autoscaling did not trigger as expected. The HPA (Horizontal Pod Autoscaler) was not scaling the application, and the CRDs for scaling were stuck in a Pending state.

This led me to investigate the node status to check the cluster’s resource utilization.

5. Resource Constraints and Node Scaling

I ran kubectl top nodes and discovered that the cluster was at 90% CPU utilization. Given that I had already exceeded my free tier and billing wasn’t working (due to using a prepaid card), I wasn’t able to scale the nodes. Since I couldn’t scale up the cluster, I opted for a different strategy.

6. Making the Application Lightweight

In order to reduce CPU consumption, I modified the Python application to be more lightweight. This involved introducing a small delay in the response time to simulate a more realistic load. Here’s the modified app.py with a delay:

from flask import Flask
import time

app = Flask(__name__)

@app.route('/')
def index():
    time.sleep(0.2)  # 200 ms delay
    return "Welcome to Rock-Paper-Scissors!"

This change significantly reduced the CPU usage and allowed the cluster to function under the free-tier constraints.

7. Incorrect ScaledObject Configuration (Using HTTPScaledObject)

After making the app lighter, I realized that the ScaledObject I had initially used was not the correct resource for HTTP-based scaling. Instead, I needed to use the HTTPScaledObject.

8. KEDA Slack Community: HTTPScaledObject Recommendation

I reached out to the KEDA community via Slack for clarification on the issue. One of the maintainers suggested that I should use HTTPScaledObject instead of the regular ScaledObject for HTTP-based scaling. This recommendation led me to revise the YAML configuration.

9. HTTPScaledObject Configuration

After understanding that HTTPScaledObject was needed, I updated my YAML to reflect the correct resource type. Below is the updated HTTPScaledObject.yaml:

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: rock-paper-scissors-http
  namespace: default
spec:
  hosts:
    - rock-paper-scissors.local
  scaleTargetRef:
    kind: Deployment
    apiVersion: apps/v1
    name: rock-paper-scissors
    service: rock-paper-scissors-service
    port: 80
  replicas:
    min: 1
    max: 10

Below is the image of the HTTP-add-on scaler other crds running:

10. Running Load Tests and Confirming Scaling

After configuring the HTTPScaledObject, I used hey to simulate 1000 requests to the service:

hey -n 1000 -c 50 http://rock-paper-scissors.local

This successfully triggered the Horizontal Pod Autoscaler (HPA) to scale up the pods, but KEDA’s HTTP Add-on did not scale the application working through ingress. The issue persisted despite proper configuration.

11. Reaching Out to KEDA Maintainer

I reached out again to the KEDA Slack channel, asking for help with the HTTP Add-on not scaling. The response from the KEDA maintainer made it clear that the HTTP Add-on was still in an unstable state, leading to the conclusion that the add-on might be shaky.

12. Hypothesis on Light Application Load

My hypothesis was that the app was too lightweight, causing it to process requests too quickly and not generate enough load for KEDA’s HTTP Add-on to scale. To test this, I increased the request rate to 1500 requests per second. However, even with this change, the scaling did not trigger.

How KEDA HTTP Add-on for Autoscaling HTTP request on Kubernetes works

Ibrahim Cisse — Wed, 05 Feb 2025 11:47:16 +0000

When it comes to autoscaling in Kubernetes, there are several methods available, but one that stands out for handling HTTP-based workloads is the KEDA HTTP Add-on. Unlike other event sources, such as queues or message brokers, HTTP-based autoscaling comes with unique challenges. In this article, we’ll dive deep into the KEDA HTTP Add-on, its architecture, and how it differs from traditional autoscaling methods.

What Makes KEDA HTTP Add-on Different?

The KEDA HTTP Add-on is not as conventional as other event sources in Kubernetes. Here’s why:

Unpredictable Traffic: Unlike Kafka or other event-based sources, where we can easily monitor the length of a queue or message rate, HTTP requests are unpredictable. We cannot simply call an API to determine how much traffic will be coming. In other words, the scaling criteria aren’t always clear in advance.

Synchronous Nature: HTTP traffic is synchronous by nature — this means requests need to be handled in real-time. As a result, scaling to zero (where no pods are running) is more complex. To address this, an intermediate routing layer is required to temporarily hold incoming HTTP requests until new pods are scaled up and ready to serve those requests.

The core Kubernetes autoscalers, such as the Horizontal Pod Autoscaler (HPA), rely on easily trackable metrics like CPU, memory, or custom metrics. However, for HTTP-based autoscaling, the KEDA HTTP Add-on introduces a different approach to meet the needs of scale-to-zero HTTP applications.

Architecture of KEDA HTTP-Add-on.

The Key Components of KEDA HTTP Add-on Architecture

The KEDA HTTP Add-on architecture involves several components that work together to ensure your HTTP service can scale efficiently. Here’s a breakdown of the key components:

Interceptor:

The Interceptor is the first line of defense when handling incoming HTTP requests. It accepts the requests and places them into a pending request queue while checking if the backend service is scaled up to handle the load.

Scaling to Zero

If the service is scaled down to zero replicas, the Interceptor will hold the incoming HTTP requests until new instances of the backend service are ready.

Once the backend service scales up, the Interceptor forwards the requests to the appropriate service.
External Scaler:

The External Scaler is a component that constantly pings the Interceptor to retrieve metrics about the number of pending HTTP requests.
This data is then sent to KEDA, which processes the information and triggers the autoscaling actions. Essentially, the External Scaler acts as the push mechanism that informs KEDA about the scaling requirements based on the HTTP traffic.

Operator:

The HTTP Operator is responsible for managing HTTPScaledObject CRDs (Custom Resource Definitions). It listens for the creation of these CRDs and takes action by configuring the necessary resources (such as the Interceptor and External Scaler) to allow autoscaling based on HTTP request traffic.

The Operator makes the whole autoscaling process easier for the user by automating the setup and configuration of the necessary components.
The Flow of HTTP Requests in KEDA HTTP Add-on

Here’s a simplified flow of how the components interact with each other:

Load Balancer:

The Load Balancer makes the application available to the outside world by routing incoming HTTP requests to the appropriate service.
Request Handling:

The Load Balancer sends the incoming requests to the Kubernetes service that hosts the HTTP service. From here, the request is passed through the Interceptor.

Interceptor:

The Interceptor temporarily holds the requests in case there are no backend pods running to handle them. It also sends metrics about pending HTTP requests to the External Scaler.

Scaling Decision:

The External Scaler pings the Interceptor for pending HTTP queue metrics, sends the data to KEDA, which then evaluates whether to scale the backend service up or down.

Scaling Action:

If the traffic is high, KEDA triggers the creation of new pods for the service to handle the load, and once scaled up, the Interceptor forwards the requests to the new pods.

If the traffic reduces, KEDA scales the service down accordingly, even scaling it to zero if necessary.

Key Benefits of the KEDA HTTP Add-on

Scale-to-Zero Support: One of the biggest benefits of using the KEDA HTTP Add-on is the ability to scale applications to zero. This means that during periods of low or no traffic, you can save resources by having no running pods while still being able to handle new traffic as soon as it arrives.

Autoscaling Based on HTTP Requests: With the KEDA HTTP Add-on, scaling decisions are based on HTTP request traffic, ensuring that your backend service is dynamically scaled to meet real-time demand without any manual intervention.

Efficient Traffic Handling: The Interceptor ensures that no HTTP requests are lost during the scaling process, providing a smooth experience for users without request drops.

Challenges and Limitations

While the KEDA HTTP Add-on is a powerful tool, there are a few challenges you might encounter:

Complex Setup: Setting up the entire KEDA HTTP Add-on system can be more complex than standard Kubernetes autoscaling. It requires configuring multiple components like the Interceptor, External Scaler, and HTTPScaledObject, which might be tricky, especially for beginners.

Scalability at Scale: While the system can scale effectively, you may encounter delays when handling very high traffic spikes, especially when scaling from zero. Proper tuning of scaling parameters and careful management of the request queue is crucial.

Compatibility: The KEDA HTTP Add-on works best when combined with KEDA’s existing autoscaling functionality, but when used alongside other scaling mechanisms (e.g., HPA), it may require extra configuration to avoid conflicts.

Conclusion

The KEDA HTTP Add-on provides a smart solution for scaling HTTP-based applications in Kubernetes, addressing challenges like unpredictable traffic and scale-to-zero requirements. By introducing components like the Interceptor, External Scaler, and Operator, KEDA makes it easier to autoscale services dynamically based on HTTP traffic, ensuring that your application is always responsive to user demand.

By leveraging KEDA’s unique autoscaling capabilities, you can efficiently manage your Kubernetes workloads, reduce resource wastage during idle periods, and scale your services seamlessly without manual intervention.

Resolving CRD Size Limit Issues with KEDA on Kubernetes

Ibrahim Cisse — Sat, 01 Feb 2025 11:04:29 +0000

While deploying KEDA (Kubernetes-based Event Driven Autoscaler) on our Kubernetes cluster, we encountered an unexpected hurdle related to Custom Resource Definitions (CRDs) being too large. This post details the problem, the strategies we attempted to resolve it, and the ultimate solution that worked. We hope this helps others facing similar challenges.

The Problem

Upon attempting to deploy KEDA using the following command:

kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml

I received the error:

Error from server (Request Entity Too Large): error when creating "https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml": etcdserver: request is too large

This indicated that the CRD definitions in the YAML file were too large for etcd to process, a known issue when handling extensive Kubernetes configurations.

Strategies I Tried

Splitting the YAML File

I attempted to split the keda-2.12.1.yaml into smaller chunks, applying each separately. Unfortunately, this led to dependency issues where certain resources required others to be present beforehand, causing the deployment to fail.

Editing the YAML File

I opened the massive YAML file (over 7,000 lines) and tried to reduce its size by:

Removing redundant annotations.

Stripping down verbose descriptions in the CRDs.
Simplifying resource definitions wherever possible.

While this approach reduced the file size, it didn't sufficiently address the size limitation for etcd, and applying the modified file still resulted in the same error.

Increasing etcd Size Limit

I considered adjusting the etcd size limit by modifying the --max-request-bytes parameter. However, this approach involved significant changes to the control plane, which wasn't feasible in GKE

Seeking Help from the Community

After exhausting the above strategies, we turned to the GitHub repository for KEDA, specifically issue #6447 related to the v2.16.1 release.

The GitHub Issue:

[KEDA v2.16.1 Release - Issue #6447 (https://github.com/kedacore/keda/discussions/6447)

In this thread, the KEDA maintainer, @JorTurFer, announced the new release and included fixes for CRD handling. While our issue wasn't directly addressed, sharing our experience in the comments helped us connect with others facing similar problems.

Comment on GitHub:

I detailed our attempts and frustrations, specifically mentioning the CRD size limitation and the strategies we tried. The community feedback was invaluable, leading us to the solution below.

The Solution

Server-side apply turned out to be the fix we needed. Instead of the traditional kubectl apply, we used:

kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1-core.yaml

This approach leverages Kubernetes' server-side apply feature, which handles larger resource definitions more efficiently and bypasses some of the etcd limitations.

Why Server-side Apply Works:

Efficient Resource Handling: Server-side apply processes resources on the server, reducing the data load on etcd.

Conflict Resolution: It provides better conflict management for CRDs and other complex resources.

After applying the above command, KEDA was successfully deployed without errors. We were then able to proceed with creating and managing our ScaledObjects.

Conclusion

Facing CRD size limitations when deploying KEDA was a challenging experience, but it provided valuable insights into Kubernetes resource management. By experimenting with various strategies, seeking help from the community, and leveraging Kubernetes' server-side apply feature, we overcame the issue.

If you're dealing with similar CRD size issues, we highly recommend trying the server-side apply approach. Also, don't hesitate to engage with the open-source community—the support and shared experiences can be incredibly helpful.

Unlocking Kubernetes Troubleshooting with Komodor: A Journey of Exploration

Ibrahim Cisse — Tue, 28 Jan 2025 12:03:24 +0000

As an avid learner of Kubernetes, I’ve always been fascinated by the sheer power and complexity of container orchestration. Kubernetes is an incredible tool, but let’s be honest—navigating its intricacies can feel overwhelming, especially when troubleshooting issues. This is where Komodor, a cutting-edge Kubernetes troubleshooting tool, enters the picture, making life easier for DevOps engineers, platform teams, and curious learners like me.

In this article, I’ll share my exploration of Komodor, its role in streamlining Kubernetes troubleshooting, and why it’s an essential tool for understanding Kubernetes in real-world scenarios. If you’re on a journey to master Kubernetes, this is a tool worth adding to your radar.

What is Komodor?

At its core, Komodor is a Kubernetes-native troubleshooting platform designed to simplify the debugging process. By providing a unified view of changes, deployments, and incidents across your cluster, Komodor helps you understand what happened, why it happened, and how to fix it—all in one place.

Whether you're dealing with misconfigurations, failed deployments, or pod crashes, Komodor provides clear insights into the root cause, enabling you to resolve issues faster and with greater confidence.

Why Troubleshooting Kubernetes is Challenging

Kubernetes is a powerful system, but its distributed nature adds complexity when things go wrong. Issues often span across multiple components like:

Misconfigured Deployments or ReplicaSets
Pod crashes due to resource limits
Networking issues within services or Ingress
Errors stemming from ConfigMaps, Secrets, or environment variables

These challenges demand not just technical know-how but also the ability to correlate logs, changes, and events across a cluster—something that can be time-consuming and frustrating without the right tools.

How Komodor Simplifies Kubernetes Troubleshooting

Komodor stands out because it focuses on reducing this complexity. Here’s what I discovered during my exploration:

1. A Centralized Dashboard for Cluster Insights

Komodor’s dashboard provides a bird’s-eye view of your cluster, displaying relevant data about pods, nodes, deployments, and more. It integrates seamlessly with your Kubernetes cluster and pulls real-time information, saving you the trouble of hunting for clues across multiple tools.

2. Tracking Changes and Deployments

One of Komodor’s standout features is its ability to trace changes. Every configuration update or deployment is logged, providing a timeline of events. This historical context is invaluable for pinpointing when and why something went wrong.

For example, if a deployment crashes after an update, Komodor shows you exactly what changed in the YAML, making it easier to roll back or fix the issue.

3. Context-Aware Alerts

Unlike generic alerts that bombard you with irrelevant information, Komodor provides context-aware alerts. These notifications highlight the root cause of the problem and suggest potential fixes, helping you focus on solving the issue instead of deciphering logs.

4. Integration with Popular Tools

Komodor integrates with tools like Helm, Istio, KEDA, and ArgoCD, making it an excellent addition to any Kubernetes environment. For learners like me, this also offers a chance to explore these integrations and understand how they contribute to a robust Kubernetes ecosystem.

Komodor in Action: Real-Life Applications

Imagine this scenario: You’re deploying a new microservice to your Kubernetes cluster. Everything seems fine, but suddenly, you notice that the deployment isn’t scaling properly. Is it a resource constraint? A misconfigured Horizontal Pod Autoscaler (HPA)? Or an issue with KEDA’s scaling triggers?

Using Komodor, you can:

Instantly see the deployment’s history and identify recent changes.
Correlate logs and events to spot misconfigurations.
Use its intuitive interface to narrow down the root cause and fix the issue efficiently.

In production environments, where downtime is costly, tools like Komodor become game-changers by enabling faster recovery and ensuring smoother operations.

Why Komodor Resonates with Me as a Learner

For someone like me, still exploring the vast landscape of Kubernetes, Komodor is more than just a tool—it’s a teacher. It helps me:

Understand how different components in Kubernetes interact.
Learn the best practices for managing and debugging clusters.
Gain hands-on experience with real-world troubleshooting scenarios.

Each issue I troubleshoot using Komodor feels like a step forward in my Kubernetes journey. The tool empowers me to connect theory with practice, deepening my understanding of this powerful technology.

Final Thoughts

Kubernetes is a dynamic, ever-evolving platform, and the path to mastering it is filled with both challenges and opportunities. Tools like Komodor not only make troubleshooting more manageable but also accelerate the learning process for enthusiasts like me.

If you’re navigating the complexities of Kubernetes or just curious about its real-world applications, I encourage you to explore Komodor. It’s not just a tool for solving problems—it’s a resource for growing your expertise and confidence in Kubernetes.

Let’s embrace the challenges, learn from the experience, and build better, more resilient systems together. What’s your favorite Kubernetes troubleshooting tool? Let me know in the comments—I’d love to learn from you too!

Hashtags: #Kubernetes #Komodor #DevOps #Troubleshooting #CloudNative

Secure Kubernetes Persistent Storage with RBAC and Pod Security Standard (PSA)

Ibrahim Cisse — Tue, 28 Jan 2025 11:34:31 +0000

Securing Stateful Apps in Kubernetes: MySQL with Persistent Volumes & RBAC

Learn how to deploy stateful applications securely in Kubernetes while enforcing storage security and Pod hardening. We'll deploy MySQL with Persistent Volumes (PVs) while implementing RBAC, Pod Security Admission (PSA), and Secret management.

🔐 Why This Matters

Stateful applications like databases require special attention in Kubernetes:

Data persistence: Storage must survive Pod restarts
Security: Sensitive credentials and storage access need protection
Compliance: Pods should follow security best practices by default

🛠️ Key Security Practices

RBAC: Limit access to storage resources
Pod Security Admission: Enforce security contexts
Secrets Management: Encrypt sensitive credentials
Persistent Storage: Use PVs/PVCs for data persistence

🚀 Deployment Walkthrough

Prerequisites

Minikube (with Docker driver)
kubectl

minikube start --driver=docker

**1. Create Dedicated Namespace**

bash
kubectl create namespace secure-storage

2. RBAC Configuration

Role Definition (rbac-role.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: secure-storage
  name: storage-manager-role
rules:
- apiGroups: [""]
  resources: ["pods", "persistentvolumeclaims"]
  verbs: ["get", "list", "create", "delete"]

Role Binding (rbac-binding.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: storage-manager-binding
  namespace: secure-storage
subjects:
- kind: ServiceAccount
  name: default
  namespace: secure-storage
roleRef:
  kind: Role
  name: storage-manager-role
  apiGroup: rbac.authorization.k8s.io

Apply RBAC rules:

kubectl apply -f rbac-role.yaml
kubectl apply -f rbac-binding.yaml

3. Persistent Storage Setup

Persistent Volume (pv.yaml):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: secure-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Persistent Volume Claim (pvc.yaml):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: secure-pvc
  namespace: secure-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

Create storage resources:

kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml

4. MySQL Deployment with Secrets

Create Database Credentials:

kubectl create secret generic mysql-secret \
  --from-literal=mysql-root-password=root_password \
  --from-literal=mysql-user=user \
  --from-literal=mysql-password=user_password \
  --namespace secure-storage

StatefulSet Configuration (mysql-statefulset.yaml):

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: secure-mysql
  namespace: secure-storage
spec:
  serviceName: "mysql-service"
  replicas: 1
  template:
    metadata:
      labels:
        app: secure-mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: mysql-root-password
        # ... full config in GitHub repo
  volumeClaimTemplates:
  - metadata:
      name: mysql-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 500Mi

5. Enforce Pod Security

Apply restricted PSA policy:

kubectl label namespace secure-storage \
  pod-security.kubernetes.io/enforce=restricted \
  --overwrite

🧪 Security Validation

Test PSA Enforcement:

kubectl apply -f non-compliant-pod.yaml -n secure-storage
# Expected error: violates PodSecurity "restricted:latest"

Verify RBAC Restrictions:

kubectl delete pod --namespace kube-system
# Error: User cannot delete resources in kube-system

✅ Key Outcomes

Secure Storage: PVs/PVCs with RBAC-controlled access

Secret Protection: Sensitive data encrypted at rest

Pod Hardening: PSA enforces security contexts

Auditability: Clear access boundaries through roles

📚 Full Code & Contribution

Explore the complete implementation and contribute:

Github repository

💬 Discussion Points

How do you handle storage security in your Kubernetes clusters?

What additional security measures do you implement for stateful workloads?

Have you tried the new PSA policies in production?

Let's discuss in the comments! 👇

Hello Dev.to Community! My Journey into DevOps and Beyond

Ibrahim Cisse — Fri, 24 Jan 2025 06:34:55 +0000

Hello, Dev.to! 👋

I’m Ibraheem Cisse, a passionate tech enthusiast, aspiring DevOps/Site Reliability Engineer (SRE), and an AWS Community Builder. With a background in support engineering and extensive experience working with cloud technologies, my journey has been one of constant learning, hands-on experimentation, and sharing knowledge.

A Bit About Me

Current Role: Support Engineer with a knack for troubleshooting complex technical issues and optimizing workflows.

Interests: Automation, cloud infrastructure, containerization, and security.

Tech Stack: AWS, Azure, Kubernetes, Terraform, GitLab, Docker, and Linux systems.

Why I’m Here

I joined Dev.to to connect with like-minded individuals, share my learnings, and document my journey into mastering DevOps and SRE practices. My aim is to break into a Cloud Engineer or Junior SRE role and grow towards becoming a seasoned SRE.

Some of my Projects

Three-Tier Python Application on AWS: Building a scalable, multi-tier application on AWS using EKS, RDS, and ALB with Terraform automation.

Event-Driven Autoscaling with KEDA: Exploring custom metrics to dynamically scale Kubernetes workloads.

Infrastructure as Code (IaC): Automating multi-region deployments using Terraform to ensure reliability and scalability.

My content is aimed at being engaging, technically sound, and actionable.

Topics I’m particularly excited about include:

Kubernetes security best practices.
Infrastructure as code
Configuration Management
Automation and Scripting
Implementing GitOps workflows with ArgoCD and Flux.
Building CI/CD pipelines for containerized applications.
Monitoring and Observability.

Let’s Connect!

Feel free to connect with me here, on GitHub, or on Medium for more technical deep dives.

Looking forward to learning, collaborating, and growing together in this amazing community! 😊