DEV Community: Denish Tomar

CRDs in Kubernetes — Teach Your Cluster New Words

Denish Tomar — Sat, 19 Apr 2025 21:02:37 +0000

Ever wish Kubernetes could just understand your app’s needs out of the box?

Well… it actually can — with CRDs (Custom Resource Definitions).

🤔 What Are CRDs?

CRDs are a way to teach Kubernetes new words — letting you define custom objects beyond what’s built-in (Pod, Service, Deployment, etc.).

They’re the magic sauce behind tools like ArgoCD and Kyverno.

✨ Why Use CRDs?

Imagine wanting Kubernetes to manage something like:

DatabaseCluster
BackupSchedule
TaskRunner

With CRDs, you can define these as native-looking resources, so you can:


bash
kubectl get backupSchedules
kubectl apply -f my-database-cluster.yaml

Confession from a Recovering Cloud User: How Qumulus Gave Me My Sanity Back

Denish Tomar — Fri, 18 Apr 2025 11:34:23 +0000

i used to spend more time reading my cloud bill than writing actual code.

My Monthly Nightmare

Every month felt like:

❓ “Why did bandwidth spike?”
😓 “Did I forget to delete something?”
🧾 10 pages of usage‑based billing I didn’t ask for

I was spending more hours investigating invoices than shipping features.

Enter Qumulus

Then I found Qumulus, and everything changed:

🧊 No metering
📦 No surprise charges
⚙️ Fixed‑cost units called QUMs (compute, storage, memory, networking—all bundled)

With Qumulus, I finally got back to what I love: writing code.

Why I Sleep Better Now

Built for Devs: Focus on features, not finance
Priced for Clarity: One predictable monthly fee
Open Architecture: No vendor lock‑in, run your way

I’m not saying Qumulus solved all my problems…

but now I wake up excited to code instead of dreading my bill.

➡️ Check it out: qumulus.io

The cloud that doesn’t break bad — it breaks the rules

Denish Tomar — Thu, 10 Apr 2025 12:10:38 +0000

🧪 "Say my name."

"QUMULUS."

No, we’re not cooking meth in an RV — we’re just cooking up a better cloud platform.

Inspired by Breaking Bad, because frankly, cloud pricing has been breaking good developers for too long.

Here’s the pitch:

🔹 No metering

🔹 Fixed-cost pricing with QUMs (Qumulus Compute Units)

🔹 One unit includes compute, memory, storage & networking

🔹 No vendor lock-in. No billing nightmares.

Whether you’re running a side project or an enterprise platform, Qumulus lets you scale without stressing over usage-based bills.

"In a world full of metered madness, Qumulus just… makes sense."

🔗 Check it out → qumulus.io

Let me know your thoughts! Would love to hear how you're currently managing cloud cost complexity.

Kubernetes Admission Controllers — Your Cluster’s Gatekeepers

Denish Tomar — Thu, 10 Apr 2025 12:04:24 +0000

Imagine your Kubernetes API is a nightclub.

Every request (or person) wants in.

Before that happens, they face the bouncer — Admission Controllers.

These powerful components intercept API requests before they're persisted in etcd.

Types:
🔁 Mutating Admission Controllers — Modify the request object.

✅ Validating Admission Controllers — Approve/deny based on policies.

Use them for:

Sidecar injection
Enforcing security rules
Labeling workloads

🛠️ Tools like Kyverno and OPA Gatekeeper make writing policies easier.

📌 Pro tip: Admission controllers are the first line of defense. Use them wisely!

What's your favorite use case for Admission Controllers?

Kubernetes Admission Controllers: The Gatekeepers You Didn't Know You Needed

Denish Tomar — Sat, 05 Apr 2025 14:15:16 +0000

When we talk about Kubernetes security and governance, most discussions revolve around RBAC, Network Policies, or Pod Security. But there’s a lesser-known yet powerful layer that silently governs every object entering your cluster: Admission Controllers.

Let’s dive into what they are, how they work, and why they deserve your attention—especially if you're aiming for production-grade cluster security and consistency.

What Are Admission Controllers?

Admission Controllers are plugins that intercept API requests to the Kubernetes API server after authentication and authorization, but before the request is persisted to etcd.

They can validate, mutate, or even deny resource creation and updates based on custom logic or policy.

There are two main types:

Mutating Admission Controllers: Modify incoming requests (e.g., inject labels or sidecars).
Validating Admission Controllers: Enforce policies by allowing or rejecting requests.

The Flow of a Request

Here’s what happens when you make a request like kubectl create -f pod.yaml:

Authentication – Who are you?
Authorization – Are you allowed to do this?
Admission Control – Should this request be allowed? Should it be changed?
etcd – If all checks pass, the object is stored.

Built-In Admission Controllers

Kubernetes ships with many built-in admission plugins. Some of the most useful ones:

NamespaceLifecycle: Prevents deletion of system namespaces.
LimitRanger: Enforces resource limits (CPU/memory).
PodSecurity: Enforces security contexts (replaces the old PodSecurityPolicy).
NodeRestriction: Prevents nodes from modifying critical objects.
TaintNodesByCondition: Automatically taints nodes based on their condition.

You can see which controllers are enabled by checking your API server’s --enable-admission-plugins flag.

Dynamic Admission Controllers (Webhooks)

Static admission plugins are useful, but not flexible enough for most production use cases.

For more dynamic control, Kubernetes offers:

MutatingAdmissionWebhook
ValidatingAdmissionWebhook

These let you define external HTTP callbacks that run your custom logic against every resource creation/update.

Use cases include:

Automatically adding labels to every resource.
Enforcing naming conventions.
Preventing deployments without resource requests.
Blocking updates to protected ConfigMaps.

Writing Your Own Admission Webhook

If you want full control, you can write a webhook server that handles admission requests. Here’s a high-level view:

Write a small server in Go (or another language) that implements the admission logic.
Deploy it inside the cluster.
Create a MutatingWebhookConfiguration or ValidatingWebhookConfiguration resource.
Kubernetes will call your service for every relevant API request.

It's a powerful way to centralize and enforce policies.

Final Thoughts

Admission Controllers are the last line of defense before anything touches etcd. They offer deep control over the security, compliance, and consistency of your cluster.

If you're managing multi-tenant environments, production workloads, or regulated systems, Admission Controllers aren't optional—they're your secret weapon.

Next up: Want a walkthrough on writing a custom Validating Webhook in Go or how to test Admission Webhooks locally? Let me know in the comments!

🚀 Cloud That Makes Sense. Finally.

Denish Tomar — Sat, 05 Apr 2025 13:41:32 +0000

Let’s be honest:
We’ve all been there — spinning up a simple project, running a few services, and suddenly your cloud bill looks like you accidentally launched a satellite.

It doesn’t have to be that way.

Enter Qumulus — the cloud platform built with developers in mind.

We asked ourselves:

Why is cloud billing still this confusing in 2025?

Why do devs feel trapped the moment they go beyond a basic setup?

Why can’t infrastructure feel more... predictable?

So we flipped the script:

✅ QUM-based pricing – No hidden charges, no billing black magic. Just a clean, transparent model that scales with you.

✅ No vendor lock-in – Build, break, migrate, pivot. You're free to architect how you want — without infra handcuffs.

We're not here to sell you complexity.
We're building something developer-first. Something that doesn’t punish you for experimenting. Something that respects the way you work.

Because when the cloud works for you, everything else falls into place.

🔗 Check us out at qumulus.io

🛠️ Built with open-source principles at heart.

💬 Got feedback or ideas? We’d love to hear from you in the comments.

Own Your Cloud, Own Your Future 🔓

Denish Tomar — Fri, 21 Mar 2025 06:07:04 +0000

Vendor lock-in? Not here. *Qumulus Cloud Platform * is built on open-source technology, giving you full control over your cloud resources.

✔ Deploy with flexibility – No proprietary traps.
✔ Use your favorite tools – Seamless open-source compatibility.
✔ Scale with confidence – Transparent pricing & zero lock-in.

Cloud should empower, not restrict. Experience freedom with Qumulus.

👉 Claim $1000 in free credit & experience true cloud transparency → qumulus.io

If the cloud ever did go down, would it be called fog? ☁️

Denish Tomar — Thu, 20 Mar 2025 04:38:46 +0000

what happens when the cloud isn’t quite… a cloud anymore? Thankfully, Qumulus is built to keep things crystal-clear. By focusing on high availability, transparent pricing, and seamless scalability, Qumulus helps ensure your cloud never drifts into “fog.”

How Qumulus Keeps Your Cloud Clear:

Reliable Uptime: Designed for stability, so downtime doesn’t become a question.
No Surprise Costs: Transparent, predictable billing—no hidden fees lurking in the mist.
Easy Scaling: Expand or adjust resources in a snap, no “foggy” complexities.

Keep your cloud bright and unobstructed.
Claim $1000 in free credit & experience true cloud transparency → qumulus.io

Securing Configurations: Managing ConfigMaps and Secrets in Kubernetes

Denish Tomar — Wed, 19 Mar 2025 11:15:04 +0000

In Kubernetes, separating configuration from code is essential for creating flexible, secure applications. This post dives into two key resources: ConfigMaps and Secrets. Learn how to manage your configuration data effectively while ensuring sensitive information remains secure.

What Are ConfigMaps and Secrets?

ConfigMaps: Store non-sensitive configuration data in key-value pairs. They allow you to decouple configuration artifacts from image content.
Secrets: Similar to ConfigMaps but designed to store confidential data such as passwords, tokens, and keys. They are encoded and can be managed with additional security controls.

Creating and Using a ConfigMap

Let’s start with a ConfigMap that holds application settings:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

You can mount this ConfigMap as environment variables or as a file in a Pod. For example, to set environment variables:

env:
- name: APP_MODE
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: APP_MODE

Handling Secrets Securely

Secrets should be managed with care. Here’s how to create a Secret:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: bXl1c2Vy   # base64 encoded value for 'myuser'
  password: c2VjcmV0   # base64 encoded value for 'secret'

Remember to decode and handle these values securely in your applications.

Best Practices for ConfigMaps and Secrets

Separation of Concerns: Keep non-sensitive data in ConfigMaps and only use Secrets for sensitive information.
Version Control: Avoid storing sensitive data in version-controlled files.
Encryption: Consider encrypting Secrets at rest and use Kubernetes RBAC policies to control access.
Environment Specifics: Use different ConfigMaps and Secrets for development, staging, and production environments.

Conclusion

Using ConfigMaps and Secrets properly enhances both the security and flexibility of your Kubernetes deployments. By separating configuration from code, you can change settings on the fly without redeploying your application—and keep sensitive information safe.

Have you encountered any challenges with configuration management in Kubernetes? Let’s discuss your tips and tricks in the comments!

Cloud bills shouldn’t feel like gambling. 🎰💸

Denish Tomar — Wed, 19 Mar 2025 05:21:29 +0000

We’ve all been there—left an instance running, forgot to turn it off, and got hit with a shocking bill. Traditional cloud pricing models make cost management a nightmare.

At Qumulus, we believe in:
✅ Flat, predictable pricing – no unexpected costs
✅ No metering, no billing surprises
✅ 100% transparency

Stop worrying about cloud bills. Build, scale, and innovate without fear. 🚀

Try Qumulus Cloud Platform with $1000 in free credits.
👉 qumulus.io

Exposing Your Apps: A Guide to Kubernetes Services and Ingress

Denish Tomar — Wed, 19 Mar 2025 04:24:41 +0000

One of the critical challenges in managing Kubernetes applications is ensuring that they are accessible—both within the cluster and to the outside world. In this post, we’ll explore how Kubernetes Services and Ingress work together to expose your applications effectively.

Kubernetes Services: The Basics

A Service in Kubernetes is an abstraction that defines a logical set of Pods and a policy by which to access them. There are several types of Services:

ClusterIP: Exposes the Service on an internal IP in the cluster. This is the default.
NodePort: Exposes the Service on the same port of each selected node.
LoadBalancer: Provisions a load balancer for the Service, making it accessible externally.

Example of a ClusterIP Service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Deploy this with kubectl apply -f service.yaml and your Pods become reachable through a stable IP address.

Ingress: Beyond Basic Service Exposure

While Services expose Pods, Ingress offers advanced routing capabilities. An Ingress controller manages external access to the services in a cluster, often via HTTP/HTTPS. It can provide:

Load Balancing: Distribute traffic to multiple services.

SSL Termination: Handle HTTPS encryption.

Path-Based Routing: Route requests based on URL paths.

Example Ingress Configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

This YAML snippet configures an Ingress to route traffic from myapp.example.com to your Service.

Practical Tips
Security: Always secure Ingress endpoints with TLS.
Testing: Use tools like curl to test your routes and debug issues.

Documentation: Consult the documentation of your Ingress controller (e.g., NGINX, Traefik) for advanced configurations.

Conclusion

By combining Kubernetes Services and Ingress, you can efficiently manage both internal communication and external access. This layered approach not only improves security but also provides flexibility for managing traffic and scaling your applications.

What methods do you use for exposing your Kubernetes applications? Share your insights in the comments below!

Mastering Deployments: Rolling Updates and Scaling with Kubernetes

Denish Tomar — Tue, 18 Mar 2025 04:09:34 +0000

description: "A comprehensive guide to managing Kubernetes Deployments, focusing on rolling updates and dynamic scaling strategies."

Deployments are the workhorse of Kubernetes application management. They allow you to define, update, and scale your application seamlessly. In this post, we’ll dive deep into how to perform rolling updates and autoscale your applications without downtime.

What Is a Deployment?

A Kubernetes Deployment provides declarative updates to Pods and ReplicaSets. It ensures your application runs the desired number of replicas and makes it easy to roll out changes.

Rolling Updates: Zero Downtime Deployments

One of the key benefits of using Deployments is the ability to perform rolling updates. Instead of taking your application offline to deploy a new version, Kubernetes incrementally updates Pods while maintaining availability.

How It Works:

Step-by-Step Replacement: New Pods are created before terminating old ones.
Health Checks: Kubernetes monitors the new Pods to ensure they’re running correctly.
Rollback Support: If an update fails, you can revert to the previous stable version.

Here’s an example YAML snippet for a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80

Apply it with kubectl apply -f deployment.yaml and watch your Deployment evolve with kubectl rollout status deployment/web-deployment.

Scaling Your Application

Kubernetes makes it easy to scale your application up or down using the kubectl scale command. Autoscaling can be configured based on CPU usage, memory usage, or custom metrics.

Example: Scaling Out

kubectl scale deployment/web-deployment --replicas=5

This command adjusts your Deployment to run five Pods instead of three, ensuring your application can handle increased traffic.

Best Practices

Monitor Performance: Use Kubernetes metrics to trigger autoscaling.

Test Rollbacks: Always have a rollback plan in case an update introduces issues.

Automate Deployments: Integrate with CI/CD pipelines to deploy changes automatically.

Conclusion

Mastering Deployments in Kubernetes not only ensures that your applications remain available during updates but also makes scaling effortless. By understanding rolling updates and autoscaling, you can maintain a robust and resilient application environment.

Have you implemented rolling updates or autoscaling in your projects? Let’s discuss your strategies in the comments!