DEV Community: Emmanuel Chukwudi

Deploying Your First App on Kubernetes: A Beginner's Guide (Minikube & Kind)

Emmanuel Chukwudi — Mon, 25 May 2026 11:44:23 +0000

If you've just learned the basics of Kubernetes Pods, Deployments, ReplicaSets, and Services the best next step is to actually use them. Reading about self-healing and rolling updates is one thing; watching Kubernetes recreate a deleted Pod in real time is another.

In this guide, you'll deploy a simple Node.js app on a local Kubernetes cluster. We'll cover both Minikube and Kind (Kubernetes in Docker), so you can follow along whichever tool you prefer.

By the end, you'll have:

A containerised Node.js app running in Kubernetes
3 replicas managed by a Deployment and ReplicaSet
A Service exposing the app to your browser
Hands-on experience with self-healing and scaling

Prerequisites

Before we start, make sure you have these installed:

Docker required by both Minikube and Kind
kubectl the Kubernetes CLI
Either Minikube or Kind (installation covered below)

Part 1: Setting Up Your Local Cluster

You only need one of these. If you're not sure which to pick:

Minikube: slightly friendlier for beginners, has a built-in way to open services in the browser
Kind: lighter, faster, great if you already have Docker set up

Option A: Minikube

Install Minikube

macOS (Homebrew):

brew install minikube

Linux:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

Windows (via winget):

winget install Kubernetes.minikube

Start your cluster:

minikube start

Verify it's running:

kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   10s   v1.x.x

Option B: Kind (Kubernetes in Docker)

Install Kind

macOS (Homebrew):

brew install kind

Linux:

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Windows (via Chocolatey):

choco install kind

Create your cluster:

kind create cluster --name hello-cluster

Verify it's running:

kubectl get nodes
# NAME                         STATUS   ROLES           AGE   VERSION
# hello-cluster-control-plane  Ready    control-plane   10s   v1.x.x

Part 2: Build the Node.js App

Create a new folder for the project:

mkdir k8s-hello && cd k8s-hello

Create app.js:

nano/vim app.js

const http = require('http');
const os = require('os');

const server = http.createServer((req, res) => {
  res.end(`Hello from Pod: ${os.hostname()}\n`);
});

server.listen(3000, () => console.log('Running on port 3000'));

Why os.hostname()? In Kubernetes, each Pod gets a unique hostname. When the Service load-balances traffic across multiple Pods, you'll see different hostnames on each refresh proving which Pod served you.

Create Dockerfile:

FROM node:18-alpine
WORKDIR /app
COPY app.js .
CMD ["node", "app.js"]

Part 3: Build and Load the Docker Image

This step differs between Minikube and Kind pay attention here.

Minikube

Minikube runs its own Docker daemon inside a VM. Point your local Docker CLI at it so your build lands inside Minikube directly:

eval $(minikube docker-env)
docker build -t hello-app:v1 .

From this point, Minikube can see the image locally without needing Docker Hub.

Kind

Kind doesn't share a Docker daemon. You build the image normally, then explicitly load it into the cluster:

docker build -t hello-app:v1 .
kind load docker-image hello-app:v1 --name hello-cluster

Skipping kind load is the most common beginner mistake with Kind. Without it, your Pods will get stuck in ImagePullBackOff because Kind can't find the image.

Part 4: Write the Kubernetes YAML

Create deployment.yaml in your project folder:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: hello
          image: hello-app:v1
          imagePullPolicy: Never   # use local image, don't pull from Docker Hub
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  type: NodePort
  selector:
    app: hello          # matches the Pod label above this is how Services find Pods
  ports:
    - port: 80
      targetPort: 3000
      nodePort: 30080

What's happening here:

The Deployment tells Kubernetes to keep 3 replicas of our Pod running at all times
It automatically creates a ReplicaSet to enforce that replica count
The Service uses the app: hello label selector to find all matching Pods and route traffic to them
imagePullPolicy: Never tells Kubernetes to use the locally available image instead of going to Docker Hub

Part 5: Deploy It

kubectl apply -f deployment.yaml

You should see:

deployment.apps/hello-deployment created
service/hello-service created

Check your Pods are coming up:

kubectl get pods

Wait until all three show Running:

NAME                                READY   STATUS    RESTARTS   AGE
hello-deployment-57c4d87bf-abc12    1/1     Running   0          15s
hello-deployment-57c4d87bf-def34    1/1     Running   0          15s
hello-deployment-57c4d87bf-ghi56    1/1     Running   0          15s

Check your ReplicaSet and Service too:

kubectl get replicaset
kubectl get service hello-service

Part 6: Open the App in Your Browser

Minikube

minikube service hello-service

Minikube opens the URL in your browser automatically.

Kind

Kind doesn't expose NodePort services directly, so use port-forwarding:

kubectl port-forward service/hello-service 8080:80

Then open http://localhost:8080.

Hit refresh a few times. You'll see the Pod hostname change the Service is load-balancing across your 3 Pods.

Hello from Pod: hello-deployment-57c4d87bf-abc12
Hello from Pod: hello-deployment-57c4d87bf-ghi56
Hello from Pod: hello-deployment-57c4d87bf-def34

Part 7: Experiments (The Real Learning)

Now that everything is running, try these one by one. Each one demonstrates a core Kubernetes behaviour.

1. Self-healing...delete a Pod manually

# grab any pod name
kubectl get pods

# delete it
kubectl delete pod hello-deployment-57c4d87bf-abc12

# watch what happens
kubectl get pods -w

Kubernetes detects the replica count dropped to 2 and immediately creates a new Pod. This is the ReplicaSet controller doing its job.

2. Scaling up

kubectl scale deployment hello-deployment --replicas=5
kubectl get pods

Two new Pods appear almost instantly.

3. Scaling down

kubectl scale deployment hello-deployment --replicas=1
kubectl get pods

Four Pods terminate gracefully, one remains.

4. Rolling update with zero downtime

Edit app.js to change the response message:

res.end(`Hello from Pod v2: ${os.hostname()}\n`);

Build a new image:

# Minikube
eval $(minikube docker-env)
docker build -t hello-app:v2 .

# Kind
docker build -t hello-app:v2 .
kind load docker-image hello-app:v2 --name hello-cluster

Update the Deployment:

kubectl set image deployment/hello-deployment hello=hello-app:v2

Watch the rolling update:

kubectl rollout status deployment/hello-deployment

Kubernetes replaces Pods one at a time, keeping the app available throughout.

5. Inspect a Pod

kubectl describe pod <pod-name>

This shows you the Pod's IP, which Node it's on, its labels, and a full event log — useful for debugging.

6. Roll back

If something goes wrong with an update:

kubectl rollout undo deployment/hello-deployment

Kubernetes switches back to the previous ReplicaSet.

Part 8: Clean Up

kubectl delete -f deployment.yaml

Minikube:

minikube stop

Kind:

kind delete cluster --name hello-cluster

Note for Kind users: Kind clusters don't survive a machine restart. If you reboot and come back to this project, run kind create cluster --name hello-cluster and kind load docker-image hello-app:v1 --name hello-cluster before applying your YAML again.

What You Just Built

Here's what was happening under the hood the whole time:

Your Browser
     ↓
 [Service]             ← watched for Pods with label app: hello
     ↓
 [ReplicaSet]          ← enforced 3 running replicas at all times
  ↓     ↓     ↓
[Pod] [Pod] [Pod]      ← each ran your Node.js container

Every concept from the Kubernetes basics maps to something you just did:

Concept	What you observed
Pod	The unit running your container, with a unique hostname
ReplicaSet	Recreated a Pod immediately after you deleted one
Deployment	Managed the rolling update and rollback
Service	Load-balanced traffic across all 3 Pods using label selectors

What's Next?

Now that you have the fundamentals working, here are good next topics to explore:

Namespaces isolate workloads for different teams or environments
ConfigMaps & Secrets externalise config and credentials from your container
Ingress a cleaner alternative to NodePort for routing external traffic
Persistent Volumes attach storage that survives Pod restarts
Liveness & Readiness Probes teach Kubernetes when your Pod is actually healthy

If you ran into issues or have questions, drop them in the comments. The most common problems are forgetting kind load docker-image (Kind) or not running eval $(minikube docker-env) before building (Minikube).

How to Read Any GitHub Repo and Write Its Dockerfile From Scratch

Emmanuel Chukwudi — Sun, 17 May 2026 14:13:07 +0000

A DevOps Engineer's Evidence-Based Approach

This guide walks through a real open-source project Ridan Express and shows you exactly how to analyze a repo's files, understand what the app needs, and write a production-ready Dockerfile without guessing.

Who This Is For

You're learning DevOps. You clone a repo, stare at it, and freeze you don't know where to start. Should you Dockerize it? What base image do you use? What commands do you run inside the container?

This article teaches you the mental model professionals use: reading a project's files as clues and letting the evidence tell you what to build.

The Project: Ridan Express

Ridan Express is a React frontend for a ride/delivery platform (think Uber or DoorDash). It uses:

React 18 + Vite as the build tool
Tailwind CSS + Material UI for styling
Redux for state management
socket.io-client for real-time features (live tracking)
mapbox-gl for maps
Stripe for payments
Google OAuth for login

Currently deployed on Vercel. No Dockerfile exists. That's your job.

Step 1: Read the Files Before You Write Anything

The golden rule: never write a Dockerfile cold. Always read these files first:

File	What it tells you
`package.json`	Language, runtime version, dependencies, build commands
`package-lock.json`	Exact locked dependency versions
`vite.config.js` / `webpack.config.js`	Build tool and output configuration
`vercel.json` / `netlify.toml`	How it's currently deployed (big clue)
`build/` or `dist/` folder	Where compiled output lands
`.env.example`	Environment variables the app needs

Let's walk through each clue in Ridan Express.

Clue 1: `package.json` → Choose Your Base Image

Opening package.json, the first thing to notice is this:

"engines": {
  "node": "22.x"
}

The developer told you exactly which Node.js version this app needs. This directly maps to your Dockerfile's first line:

FROM node:22-alpine

Why alpine? The Alpine variant of Node is a minimal Linux distribution around 50MB instead of 900MB+ for the full image. Always prefer Alpine for production unless you need specific system libraries.

The rule: "engines" in package.json → your FROM node:X-alpine version.

Clue 2: `package-lock.json` → Use `npm ci`, Not `npm install`

The presence of package-lock.json alongside package.json is a deliberate signal. Here's the critical distinction:

Command	Behavior
`npm install`	Installs dependencies, may update versions
`npm ci`	Installs exact versions from `package-lock.json`, fails if they don't match

In a Docker build, you always want npm ci. It's faster, deterministic, and prevents "it worked on my machine" bugs. Your Dockerfile should copy both files before installing:

COPY package*.json ./
RUN npm ci

The package*.json glob copies both package.json and package-lock.json in one line.

Why copy these before the rest of the code? Docker builds in layers and caches each one. If you copy everything first, any code change invalidates the dependency cache and forces a full npm ci on every build slow. Copying package*.json first means Docker only re-runs npm ci when dependencies actually change.

Clue 3: `vite.config.js` + Scripts → Your Build Command

In package.json, the scripts section reads:

"scripts": {
  "ridan": "vite",
  "build": "vite build"
}

vite build compiles your entire React app JSX, TypeScript, CSS modules, imports into plain HTML, CSS, and JavaScript files. No more React, no more JSX, no more Node.js required. Just static files a browser can load directly.

This translates to:

COPY . .
RUN npm run build

After this runs, a build/ folder appears containing your compiled app, ready to be served.

Clue 4: The `build/` Folder → You Don't Need Node Anymore

This is the insight that changes everything.

After npm run build finishes, the output in build/ is just:

build/
  index.html
  static/
    js/main.abc123.js
    css/main.def456.css
    media/logo.png

These are static files. A browser can load them directly. You no longer need Node.js, npm, React, or any of your dependencies. They were only needed during the build process.

So why keep a 500MB Node.js environment in your production image just to serve a few HTML files? You don't.

Clue 5: Static Output → Serve With Nginx

Since the output is static files, the right tool to serve them is Nginx a battle-tested, lightweight web server used by some of the highest-traffic sites in the world.

FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

/usr/share/nginx/html is Nginx's default document root the folder it serves files from. You're dropping your compiled app right there.

The nginx:alpine image is around 25MB total. Compare that to keeping Node.js around at 500MB+.

Putting It All Together: The Multi-Stage Dockerfile

Here's the complete Dockerfile with every line explained:

# ── STAGE 1: Build ─────────────────────────────────────────────
# Use Node 22 (matches "engines" in package.json), Alpine for small size
FROM node:22-alpine AS builder

# Set working directory inside the container
WORKDIR /app

# Copy dependency manifests FIRST (enables Docker layer caching)
# Only re-runs npm ci when package files change, not on every code change
COPY package*.json ./

# Install exact versions from package-lock.json (deterministic, production-safe)
RUN npm ci

# Copy the rest of the source code
COPY . .

# Compile React → static HTML/CSS/JS in the /app/build folder
RUN npm run build


# ── STAGE 2: Serve ─────────────────────────────────────────────
# Start fresh with a minimal Nginx image (~25MB vs 500MB+ for Node)
FROM nginx:alpine

# Copy ONLY the compiled output from Stage 1 nothing else
# Node.js, npm, node_modules, and source code are all left behind
COPY --from=builder /app/build /usr/share/nginx/html

# Tell Docker this container listens on port 80
EXPOSE 80

# Nginx starts automatically no CMD needed for the default config

Understanding Multi-Stage Builds Visually

┌─────────────────────────────┐       ┌──────────────────────────┐
│      Stage 1: builder       │       │     Stage 2: final       │
│      node:22-alpine         │       │      nginx:alpine        │
│                             │       │                          │
│  ✓ Node.js runtime          │  ──▶  │  ✓ Compiled HTML/CSS/JS  │
│  ✓ npm + package manager    │  only │  ✓ Nginx web server      │
│  ✓ 300MB node_modules       │  /build  │                       │
│  ✓ React source code        │       │  ✗ No Node.js            │
│  ✓ Vite build toolchain     │       │  ✗ No npm               │
│                             │       │  ✗ No source code        │
│  ← DISCARDED after build →  │       │  ← SHIPPED TO PROD →     │
│       ~600MB                │       │       ~30MB              │
└─────────────────────────────┘       └──────────────────────────┘

The first stage is a construction site. The second stage is the finished building. You ship the building, not the scaffolding.

The Evidence-to-Dockerfile Mental Map

Every line in the Dockerfile traces back to a file in the repo:

package.json
  ├── "engines": { "node": "22.x" }  ──────▶  FROM node:22-alpine
  └── "build": "vite build"  ────────────────▶  RUN npm run build

package-lock.json exists
  └──────────────────────────────────────────▶  RUN npm ci

vite.config.js exists
  └── output goes to /build folder  ─────────▶  COPY /app/build → nginx

Output is static files (no server-side rendering)
  └──────────────────────────────────────────▶  FROM nginx:alpine

Nothing is guessed. Everything is derived from evidence.

When to Use Nginx vs Keeping Node Running

You used a static Nginx serve here because Vite pre-compiles everything. But not all React apps work this way:

App type	Clue in repo	Serve with
Static React (Vite/CRA)	`vite build` or `react scripts build`	Nginx (static files)
Next.js with SSR	`next start` in scripts	Keep Node running
Express API backend	`server.js` or `app.js` at root	Keep Node running
Nuxt.js	`nuxt start` in scripts	Keep Node running

If npm start runs a server (not just opens a browser), keep Node. If npm run build produces a folder of files, use Nginx.

What Comes Next for This Project

The Dockerfile handles the frontend. But Ridan Express has more moving parts visible in package.json:

socket.io-client: there's a Socket.io server somewhere handling real-time ride tracking
stripe: there's a payment processing backend
mapbox-gl: likely server-side route calculations
@react-oauth/google a backend endpoint validates the Google token

To fully containerize this platform you'd eventually write:

# docker-compose.yml (when you find/build the backend)
services:
  frontend:
    build: ./frontend
    ports: ["3000:80"]

  backend:
    build: ./backend
    ports: ["5000:5000"]
    environment:
      - STRIPE_SECRET_KEY=${STRIPE_SECRET_KEY}

  socket:
    build: ./socket-server
    ports: ["4000:4000"]

  database:
    image: postgres:15-alpine
    volumes: [pgdata:/var/lib/postgresql/data]

And that's when Kubernetes becomes relevant when you have multiple services that need to scale independently.

Quick Reference Cheat Sheet

See this in the repo          →  Do this in Dockerfile
─────────────────────────────────────────────────────────
package.json only             →  npm install
package.json + lock file      →  npm ci
"engines": node X             →  FROM node:X-alpine
"build": "vite build"         →  RUN npm run build → serve with Nginx
"build": "next build"         →  RUN npm run build → keep Node + CMD next start
server.js at root             →  Keep Node, CMD ["node", "server.js"]
requirements.txt              →  FROM python:3.X-slim
go.mod                        →  FROM golang:X-alpine + multi-stage
pom.xml (Java/Maven)          →  FROM maven:X AS builder + FROM eclipse-temurin

Summary

Writing a Dockerfile isn't about memorizing syntax it's about reading the project. The files in every repo are instructions waiting to be translated:

package.json engines → tells you the runtime version
package-lock.json → tells you to use npm ci
Build scripts → tells you the compile command
Output type (static vs server) → tells you whether to use Nginx or keep Node
Multi-stage builds → keep images small by separating build from runtime

Next time you open a repo, don't stare at it blankly. Start with package.json, follow the clues, and let the evidence write the Dockerfile for you.

Found this useful? The same detective approach applies to CI/CD pipelines and Kubernetes manifests the repo always tells you what it needs. Follow for more DevOps breakdowns.

Validate JWTs from Multiple Issuers in kgateway

Emmanuel Chukwudi — Sun, 17 May 2026 07:52:37 +0000

Production APIs often need to accept tokens from more than one identity provider for example, a tenant's own Auth0 tenant and Google Workspace for internal tools. kgateway's JWTPolicy resource lets you declare multiple issuers in one policy and attach it to any HTTPRoute, so you don't need a separate gateway per IdP.

This guide walks through a working, reproducible configuration. By the end you will have a policy that validates tokens from two issuers, rejects mismatched audiences, and forwards selected claims as upstream headers.

What is a JWT?

A JSON Web Token (JWT) is a compact, self-contained credential that an identity provider (IdP) issues to a user or service after they authenticate. Instead of your API checking a username and password on every request, the client attaches a JWT and your API trusts it because it was cryptographically signed by someone it already trusts.

Think of it like a signed event wristband. The venue (IdP) checks your ID once at the gate and gives you a wristband. Staff inside the venue (your APIs) can verify the wristband is genuine without phoning the front gate again. The wristband also says which areas you can access and it expires at midnight.

Structure of a JWT

A JWT is three Base64URL-encoded JSON objects joined by dots:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9   ← Header
.
eyJzdWIiOiJ1c2VyXzEyMyIsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20i...  ← Payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← Signature

Part	What it contains
Header	Algorithm (`RS256`) and token type. Tells the verifier how to check the signature.
Payload	Claims about the user and the token who issued it, who it's for, when it expires.
Signature	Cryptographic proof the token hasn't been tampered with. Verified against the IdP's public key.

You can paste any JWT into jwt.io to decode it instantly.

What's inside the payload?

The payload is a JSON object of claims statements about the token and its subject. Some are standard; some are custom fields added by your IdP.

{
  "iss": "https://my-tenant.auth0.com/",  // issuer — who created the token
  "sub": "user_123",                       // subject — the user's unique ID
  "aud": "my-api",                         // audience — which service this token is for
  "exp": 1717000000,                       // expiry — Unix timestamp
  "email": "alice@example.com",            // custom claim added by Auth0
  "roles": ["admin", "editor"]             // custom claim for RBAC
}

How signature verification works (JWKS)

JWTs signed with RS256 use asymmetric cryptography: the IdP signs tokens with a private key that only it holds, and publishes the corresponding public keys at a well known URL called the JWKS endpoint (JSON Web Key Set). Anyone including kgateway can fetch these public keys and verify that a token was genuinely issued by that IdP and hasn't been altered since.

This means kgateway never needs to call back to your IdP on every request. It fetches the JWKS once, caches the keys, and verifies signatures locally at the data plane making validation fast and offline capable.

Why this matters for multi-issuer setups: Each IdP has its own JWKS endpoint and its own signing keys. kgateway can hold keys from multiple providers simultaneously, matching each incoming token to the right key by checking its iss claim first.

What you'll build

An HTTPRoute on /api that:

Accepts RS256-signed JWTs from Auth0 and Google
Enforces aud: my-api on tokens from both providers
Forwards the sub and email claims as X-User-Id and X-User-Email headers to your upstream service

Before you begin

kgateway ≥ 1.2 installed in your cluster
kubectl access with permissions to create custom resources
An Auth0 tenant with an API audience configured
A Google OAuth 2.0 client ID

How kgateway validates JWTs

Validation happens in the Envoy data plane before a request ever reaches your upstream. On each request, kgateway:

Extracts the bearer token from the Authorization: Bearer <token> header (configurable to cookies or query params).
Resolves the matching issuer by comparing the token's iss claim against each issuer declared in JWTPolicy.spec.providers. The first match wins.
Fetches and caches JWKS from the provider's jwks_uri. Keys are cached per the cacheDuration you set and never re-fetched mid-request.
Validates claims and signature verifies exp, nbf, aud, and the cryptographic signature. Any failure returns 401 Unauthorized immediately.
Forwards claims as headers injects declared claims into request headers so your upstream can make authorization decisions without reparsing the JWT.

Step 1: Create the JWTPolicy

The JWTPolicy is a namespace scoped custom resource that declares which issuers to trust, where to fetch their public keys, and which claims to forward upstream. Create a file named jwt-policy.yaml:

apiVersion: gateway.kgateway.dev/v1alpha1
kind: JWTPolicy
metadata:
  name: multi-issuer-policy
  namespace: default
spec:
  providers:

    # Provider 1: Auth0 tenant
    - name: auth0
      issuer: https://my-tenant.auth0.com/     # note the trailing slash
      audiences:
        - my-api
      remoteJwks:
        uri: https://my-tenant.auth0.com/.well-known/jwks.json
        cacheDuration: 10m
      claimsToHeaders:
        - claim: sub
          header: X-User-Id
        - claim: email
          header: X-User-Email

    # Provider 2: Google
    - name: google
      issuer: https://accounts.google.com      # no trailing slash
      audiences:
        - my-api
      remoteJwks:
        uri: https://www.googleapis.com/oauth2/v3/certs
        cacheDuration: 5m
      claimsToHeaders:
        - claim: sub
          header: X-User-Id
        - claim: email
          header: X-User-Email

⚠️ Issuer strings must be exact. The issuer field is compared character-for-character against the token's iss claim. Auth0 includes a trailing slash in its tokens; Google does not. A mismatch here means every token from that provider will be rejected, even if the signature is valid.

Step 2: Attach the policy to your HTTPRoute

Reference the policy via an annotation on your HTTPRoute. You do not need to modify the route's rules:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: default
  annotations:
    gateway.kgateway.dev/jwt-policy: multi-issuer-policy
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: my-service
          port: 8080

Step 3: Apply and verify

# Apply both resources
$ kubectl apply -f jwt-policy.yaml -f httproute.yaml

# Confirm the policy is accepted by the control plane
$ kubectl get jwtpolicy multi-issuer-policy \
    -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
True

# Test with a valid Auth0 token
$ curl -H "Authorization: Bearer $AUTH0_TOKEN" https://my-gateway/api/health
200 OK

# Test rejection: no token → 401
$ curl https://my-gateway/api/health
401 Unauthorized

# Confirm upstream receives the forwarded headers
$ kubectl logs deploy/my-service | grep X-User-Id
X-User-Id: user_123

⚠️ JWKS caching on first request: kgateway fetches JWKS the first time a token from a given issuer arrives. If the jwks_uri is unreachable at that moment, the request fails with 503. Use a cacheDuration of at least 5m in production never 0s outside of development.

Claim validation reference

Claim	Validated automatically	Notes
`iss`	Yes	Must exactly match a declared provider's `issuer`. First match wins; no fallback.
`aud`	Yes, if configured	Token must contain at least one value from the `audiences` list. Omit the field to skip audience validation (not recommended in production).
`exp`	Yes	Expired tokens are rejected with 401. Clock skew tolerance is 60 s by default.
`nbf`	Yes	Tokens with a future `nbf` (not-before) are rejected.
`sub`, `email`, `roles`	No	kgateway does not validate custom claims. Use `claimsToHeaders` to forward them and enforce access rules in your upstream service.

Next steps

Use a local JWKS secret: Mount JWKS as a Kubernetes secret for air gapped or high security environments.
Claim based routing: Route requests to different backends based on forwarded claim headers.
Full OIDC with Auth0: Add the authorization code flow for browser facing applications.
Monitor validation errors: Surface JWT rejection rates in Prometheus and set alerting thresholds.

DEV Community: Emmanuel Chukwudi

Deploying Your First App on Kubernetes: A Beginner's Guide (Minikube & Kind)

Prerequisites

Part 1: Setting Up Your Local Cluster

Option A: Minikube

Option B: Kind (Kubernetes in Docker)

Part 2: Build the Node.js App

Part 3: Build and Load the Docker Image

Minikube

Kind

Part 4: Write the Kubernetes YAML

Part 5: Deploy It

Part 6: Open the App in Your Browser

Minikube

Kind

Part 7: Experiments (The Real Learning)

1. Self-healing...delete a Pod manually

2. Scaling up

3. Scaling down

4. Rolling update with zero downtime

5. Inspect a Pod

6. Roll back

Part 8: Clean Up

What You Just Built

What's Next?

How to Read Any GitHub Repo and Write Its Dockerfile From Scratch

A DevOps Engineer's Evidence-Based Approach

Who This Is For

The Project: Ridan Express

Step 1: Read the Files Before You Write Anything

Clue 1: package.json → Choose Your Base Image

Clue 2: package-lock.json → Use npm ci, Not npm install

Clue 3: vite.config.js + Scripts → Your Build Command

Clue 4: The build/ Folder → You Don't Need Node Anymore

Clue 5: Static Output → Serve With Nginx

Putting It All Together: The Multi-Stage Dockerfile

Understanding Multi-Stage Builds Visually

The Evidence-to-Dockerfile Mental Map

When to Use Nginx vs Keeping Node Running

What Comes Next for This Project

Quick Reference Cheat Sheet

Summary

Validate JWTs from Multiple Issuers in kgateway

What is a JWT?

Structure of a JWT

What's inside the payload?

How signature verification works (JWKS)

What you'll build

Before you begin

How kgateway validates JWTs

Step 1: Create the JWTPolicy

Step 2: Attach the policy to your HTTPRoute

Step 3: Apply and verify

Claim validation reference

Next steps

Clue 1: `package.json` → Choose Your Base Image

Clue 2: `package-lock.json` → Use `npm ci`, Not `npm install`

Clue 3: `vite.config.js` + Scripts → Your Build Command

Clue 4: The `build/` Folder → You Don't Need Node Anymore