Forem: Manikanta majeti

Why Kubernetes Alone Isn’t Enough: The Case for API Gateways and Service Meshes

Manikanta majeti — Sat, 07 Mar 2026 06:17:19 +0000

---

canonical_url: https://faun.pub/why-kubernetes-alone-isnt-enough-the-case-for-api-gateways-and-service-meshes-2ee856ce53a4

If Kubernetes already handles networking, why do we need API Gateways and Service Meshes like Istio?

Kubernetes (K8s) has become the go-to platform for deploying and scaling modern applications. It abstracts away infrastructure complexity, automates container orchestration, and provides resilience out of the box.

But there’s one question I often get asked:

👉 “If Kubernetes already handles networking, why do we need API Gateways and Service Meshes like Istio?”

The short answer: Kubernetes provides the runway, but you still need air traffic control and security checkpoints to ensure safe, controlled travel.

Let’s explore why.

North-South vs. East-West Traffic

To understand the gaps, it’s important to distinguish between two directions of traffic inside Kubernetes:

North-South Traffic → communication between external clients and services inside the cluster. (Example: a user accessing your app through an API endpoint.)
East-West Traffic → communication between services within the cluster. (Example: Service A calls Service B for data.)

Kubernetes Services and Ingress provide the basics for connecting this traffic — but “ basic ” is the key word.

Kubernetes Network Policies: The Built-in Guardrails

Before diving into advanced tools, let’s acknowledge what Kubernetes does offer.

Kubernetes comes with Network Policies , which act as a basic firewall inside the cluster. They let you define rules such as:

Which pods can communicate with which other pods.
Which external IPs or CIDRs are allowed.
Whether connections are ingress-only, egress-only, or both.

This is incredibly valuable. By default, pods in Kubernetes can talk to each other freely — Network Policies put up the first layer of guardrails.

But here’s the catch:

Network Policies are IP/label-based. They don’t understand application protocols, authentication headers, or user identity.
They don’t offer traffic shaping (like retries, circuit breaking, or canary deployments).
They provide no observability or encryption between services.

👉 In other words: Network Policies keep the doors locked, but they don’t check who’s knocking or why they’re there.

This is exactly where API Gateways and Service Meshes step in.

Enter API Gateway: Your Airport Gate

For north-south traffic , an API Gateway acts as the gatekeeper at the airport entrance.

It:

Authenticates incoming requests.
Validates payloads and enforces rate limits.
Routes requests to the right backend service.

Think of it as the check-in counter at an airport: only passengers with the right ticket can proceed, and their baggage is screened before entry.

Without a gateway, every service would have to implement its own external security and request validation — a recipe for duplication and inconsistency.

Enter Istio: Your Airport Security Inside the Terminal

For east-west traffic , Istio (a service mesh) is like the airport’s internal security system.

It:

Provides mTLS encryption between services.
Enforces fine-grained, application-aware policies.
Offers traffic control (blue/green, canary, retries, circuit breaking).
Delivers deep observability with metrics and tracing.

Think of Istio as the security gates and flight information systems : they keep unauthorized movement in check, scan interactions, and make sure flights (services) run on schedule with full visibility.

K8s Network Policy vs ISTIO Service Mesh

The Power-Up: Gateway + Mesh Together

Individually, an API Gateway and Istio solve specific problems. Together, they give your Kubernetes environment airport-grade security and control.

API Gateway secures and manages north-south traffic.
Istio secures and manages east-west traffic.
Combined, they elevate Kubernetes from just a “runway” to a full airport with checkpoints, security, and flight control.

Without them, Kubernetes provides the planes and runway — but leaves you vulnerable to misrouted flights, unauthorized passengers, and security blind spots.

Closing Thoughts

Kubernetes is powerful, but it’s not a security or traffic-management silver bullet.

Network Policies give you a solid foundation.
API Gateways add control over external entry points.
Service Meshes like Istio bring deep visibility and in-cluster security.

Together, they transform Kubernetes from “just orchestration” into a resilient, secure, production-ready platform.

So, next time someone asks:

👉 “Why do we need API Gateway and Istio when we already have Kubernetes?”

You can answer confidently:

“Because Kubernetes gives you the runway — but you still need airport-grade security to keep the flights safe.”

✈️ And if you want to see this analogy in action, check out my article:

👉 How API Gateways and Istio Service Mesh Work Together (Airport Analogy)

Workload Identity Federation Explained in 2 Minutes (with a School Trip Analogy)

Manikanta majeti — Sat, 16 Aug 2025 13:10:24 +0000

Static keys and long-lived credentials are one of the biggest risks in cloud workloads.

In this 2-minute video, I explain Workload Identity Federation (WIF) using a simple school trip analogy — students, teachers, buses, and wristbands — to make the concept crystal clear.

Key Takeaways:

The risks of static keys
How WIF works step by step
Benefits of short-lived tokens
When to use (and when not to use) WIF

Watch here → https://youtu.be/UZa5LWndb8k
Read more at → https://medium.com/@mmk4mmk.mrani/how-my-kids-school-trip-helped-me-understand-workload-identity-federation-f680a2f4672b

Would love to hear your thoughts — are you already using WIF in your org?

IAM Explained, by the Avengers

Manikanta majeti — Wed, 13 Aug 2025 15:02:03 +0000

🦸‍♂️ What if your team had superhero powers… but no boundaries?
Thor smashes production. Spidey deletes your logs. Chaos.

⚡ Here’s how to bring order to your superhero squad with IAM:
🎥 Watch the comic-style explainer → https://youtu.be/GJaBXQXJ35I
📖 Read the full breakdown → https://medium.com/faun/iam-explained-by-the-avengers-39a3fe4265e5

Great power… great responsibility. And a lot fewer broken servers. 😅

Why Platform Engineering? A Tale from a Busy Kitchen

Manikanta majeti — Mon, 07 Jul 2025 11:13:59 +0000

What if developers were chefs expected to run the entire restaurant — cooking, cleaning, provisioning ingredients, and keeping the kitchen running?

In Part 1 of my Platform Engineering series, I dive into:
🍳 The overwhelming DevOps burden on developers
⚙️ Where Platform Engineers, SREs, and DevOps intersect
📈 How internal platforms help teams scale with sanity

This isn’t just theory — it's a story, an analogy, and a framework to rethink your dev workflow.

Watch of YouTube:

Read on Medium:

medium.com

Kubernetes Workloads & Services — Explained with an Amusement Park Analogy

Manikanta majeti — Sun, 20 Apr 2025 10:43:15 +0000

Hey folks 👋 — here’s a fun analogy-driven explainer on Kubernetes workloads and services. Hope it helps simplify things for you!

Ever felt overwhelmed trying to understand Kubernetes workloads and services? Let’s make it fun — imagine it’s an amusement park!

Goal of this article
Kubernetes can be overwhelming for beginners. But what if we took a step back and viewed it through a lens we all understand — an amusement park?

This article is structured to help readers first understand the technical Kubernetes concepts (workloads and services) and then bring them to life using an engaging analogy.

If you prefer visual explanations 🎥 Watch the full journey on YouTube

Don’t forget to like, share, and subscribe to stay updated on the next chapters!

And stay tuned for the next chapter: Managing Microservice Traffic Like a Pro with Istio.

Section 1: Kubernetes Workloads: What Actually Runs Your Code
At its core, a workload is anything you deploy on Kubernetes to do work. Let’s walk through the K8s Workload types:

Pods

The smallest deployable unit in K8s
One or more containers that share storage, network, and a spec.

apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
spec:
  containers:
    - name: hello-container
      image: nginx

Above is code snippet for creation of a pod with a single container running NGINX. Nothing fancy here.

Sometimes a pod is standalone. Sometimes, there are copies of the same pod running across the K8s. Which brings us to…

ReplicaSets

Ensure a specified number of Pod replicas are running at all times.
Usually managed by Deployments directly.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: hello-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: hello-container
          image: nginx

Above is code snippet for creation of a ReplicaSet which ensures there are always 3 pods running the same app. If one fails, it’s recreated.

A ReplicaSet ensures that a specific number of pod replicas are always running. If one breaks, another is spun up immediately as they are managed by….

Deployments

Used for stateless applications.
They manage replicas of Pods and handle updates and rollbacks.

Imagine a smart system that not only monitors replicas but also updates them, rolls them out gradually, or rolls them back if anything fails. That’s a Deployment — your operations manager for all of our pods + ReplicaSets.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: hello-container
          image: nginx:1.21

Above is code snippet for creation of Deployments that takes care of managing app updates. Want to change the image version? Just update it here.

StatefulSets

For stateful applications like databases.
Each Pod gets a persistent identity and storage.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db-stateful
spec:
  serviceName: "db"
  replicas: 2
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: db
          image: mongo
          volumeMounts:
            - name: data
              mountPath: /data/db
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi

Above is a code snippet for StatefulSet. Each StatefulSet pod has a unique name and its own persistent storage — ideal for databases or apps needing state.

Jobs

Run a task to completion (e.g., batch data processing).
Once done, it doesn’t restart.

apiVersion: batch/v1
kind: Job
metadata:
  name: run-once-job
spec:
  template:
    spec:
      containers:
        - name: hello
          image: busybox
          command: ["echo", "Hello from the job"]
      restartPolicy: Never

Above is a code snippet for Jobs. Jobs are used for one-off tasks, like data migration or sending one-time emails.

CronJobs

Like Jobs, but run on a schedule (e.g., backups every night).

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-task
spec:
  schedule: "0 6 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: task
              image: busybox
              command: ["echo", "Good morning!"]
          restartPolicy: OnFailure

Above is a code snippet for CronJobs. CronJobs run on a schedule. This one says: run at 6 AM every day

DaemonSets

Run one copy of a Pod on every node (e.g., for logging or monitoring agents).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      name: log-agent
  template:
    metadata:
      labels:
        name: log-agent
    spec:
      containers:
        - name: agent
          image: fluentd

The above code snippet is for DaemonSets that ensure one pod runs on every node — great for log collectors, security scanners, etc.

Section 2: Kubernetes Services: Connecting the Dots
The Need for Services — Managing Entry Points
While workloads are doing the work, services make sure they can be found and talked to.

We need to expose pods reliably — sometimes internally, sometimes externally. We also need routing rules, load balancing, and access controls.

Let’s walk through the types of service entry points.

ClusterIP (default)

Internal-only communication.
Useful when components within the cluster need to talk to each other.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP  # Internal-only access
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376  # Port exposed by the container

NodePort

Exposes a pod on a specific port on each Node’s IP
Useful for basic external access.

apiVersion: v1
kind: Service
metadata:
  name: nodeport-service
spec:
  type: NodePort 
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30007

LoadBalancer

Assigns an external IP and distributes incoming traffic.
Distributing external traffic evenly across pods.
It creates a cloud provider-manged external load balancer with a public IP.
Often used in production environments.

apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-service
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 8080

Ingress

Acts as a smart entry point, routing HTTP requests based on the path or host.
Can be integrated with TLS, rate-limiting, and more.

Routing traffic based on path rules like /customers, /payments, /orders. It consolidates external access through a single smart gateway.

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

Now for the Fun Part: Kubernetes Park
Now that the fundamentals are clear, let’s turn on the lights and enter the park. Let’s take a walk through Kubernetes Park, and meet its quirky residents: the workloads and the service types.

Section 3: Workloads Zone: The Backbone of the Park
Each ride, game, and attraction in the park is a workload — something that does the actual work to keep the park running.

Welcome Map Recap

🎯 Pods — The Basic Ride

Think of a Pod as a single ride or stall — like a popcorn stand or a bumper car setup.
It’s the smallest deployable unit in the park. Each one runs a specific task (a container), and when it crashes, it’s just… gone.

Real-world note: Pods aren’t meant to live long. They’re ephemeral and usually managed by something smarter.

♻️ ReplicaSets — Ensuring There Are Enough Rides

Imagine a supervisor walking around ensuring you always have 3 bumper car rides running, even if one breaks down. That’s a ReplicaSet.
It ensures the right number of identical pods are always active.

🚀 Deployments — Managers Who Plan the Shows

These are the smart managers deciding when to roll out a new show, upgrade old rides, or scale the number of rides up or down.
Deployments use ReplicaSets underneath but add the magic of controlled updates and rollbacks.

🧳 StatefulSets — Personalized, Memory-Heavy Attractions

Some attractions, like personalized escape rooms, need to remember who visited them. That’s StatefulSets — pods with persistent identities and stable storage.

⏱️ Jobs — One-Time Shows

Imagine organizing a one-off fireworks show at night — it happens once, and then it’s done. That’s what a Job is — runs once and completes.

🕰️ CronJobs — Scheduled Park Events

Think of those scheduled magic shows at 6 PM every day — that’s a CronJob in Kubernetes, recurring on a schedule like clockwork.

🌍 DaemonSets — Staff Assigned to Every Zone

Some team members (like janitors or security) must be present in every zone of the park. That’s what DaemonSets are — one pod per node, always.

Section 4: Services Zone: Navigating the Park

Workloads is nothing but having attractions — Services is to let people find those attractions. Services in Kubernetes act as entry points or guides for traffic.

🛜 ClusterIP — Staff Walkie-Talkie Network

Only staff can talk to each other internally using their walkie-talkies. That’s what a ClusterIP does — enables internal communication between attractions. Example: The ticket counter wants to talk to the food stalls backend. ClusterIP connects them.

🚪 NodePort — Side Staff-Only Gate

Imagine a special staff entrance on the side, accessible via a unique pass.
That’s NodePort — exposes a service on a specific port externally.

🌀 LoadBalancer — Grand Main Entrance

Your public-facing main entrance, with fancy gates and automatic load balancers routing visitors evenly to different rides. That’s a LoadBalancer service.

🤖 Ingress — Smart Robot Tour Guide

A futuristic welcome center with a smart robot who asks, “Do you want rides, food, or games?” and routes you to the right section. That’s Ingress, handling path-based routing, SSL, and more.

🎟️ Coming Up Next…The Service Mesh Story 🧩
Even with the park fully operational, new challenges arise:

Surge in visitors (traffic control)
Need for observability (who’s going where?)
Enforcing rules (who’s allowed on what ride?)

This is where **Istio **and the service mesh come in — providing fine-grained control, security, and insights across your microservices.

What did you think of the theme park analogy? Do you have your own creative way of understanding complex systems like Kubernetes?
Let me know your thoughts, analogies, or questions in the comments — I’d love to hear them!