DEV Community: Noushad Hasan

Kubernetes Gateway API

Noushad Hasan — Tue, 16 Sep 2025 06:14:01 +0000

Gateway API in Kubernetes: The Next Evolution in Traffic Management

Kubernetes has become the de facto platform for running containerized applications at scale. But running apps in Kubernetes isn’t just about deploying Pods — it’s about getting external traffic in. For years, the go-to way of doing that was with the Ingress API.
Ingress is the traffic routing mechanism primarily used in the Kubernetes environments. However it comes with several limitations. One such example is, it supports only Layer 7 HTTP based traffic. So,to overcome all the Ingress limitations, the Kubernetes Gateway API was development.

Gateway API, a more powerful and flexible evolution of Ingress. Think of it like moving from an old Nokia phone to a modern smartphone — both make calls, but one unlocks a whole new set of possibilities.

The Gateway API has the following key features-

Protocol Agnosticism:
It provides a unified API for managing different layers of network traffic, from simple L4 TCP/UDP connections to complex L7 application-aware routing based on HTTP and gRPC protocols.
Advanced Request Matching:
It enables sophisticated traffic control by allowing routing decisions
to be based on HTTP request attributes, such as path, header values, and
query parameters.
Cross-Team Routing:
It safely allows traffic from a public entry point to be routed to
applications managed by different teams in different namespaces.
Portability & Standardization:
It reduces lock-in by offering a common, vendor-neutral specification
for ingress configuration, minimizing the reliance on implementation-
specific annotations and making manifests portable across different
Kubernetes environments and ingress controllers.
Consistent API for Mesh & Ingress:
It extends the same routing principles and API objects beyond the
cluster edge into the service mesh, providing a consistent operational experience for both north-south (ingress) and east-west (mesh) traffic
when integrated with providers like Istio and Linkerd.

In summary, the Gateway API is an improved version of Kubernetes Ingress that offers more powerful and flexible traffic management.

Gateway API Controller
As we learned in the Ingress lesson, even though we define routing rules in the Ingress object, the actual routing is handled by the Ingress Controller.

The same concept applies to the Gateway API.

While the Gateway API provides many objects to manage cluster traffic, the actual routing is done by a Gateway API Controller. This controller is not built into Kubernetes. You need to enable them by installing the Gateway API Custom Resource Definitions (CRDs).

Various Gateway API controllers are available, some of them are

Nginx Gateway Fabric
Kong Gateway
Envoy Gateway

How Gateway API Actually Works

One of the coolest things about Gateway API is that it isn’t just “Ingress v2.” It’s built around a component model that makes networking modular, role-based, and flexible. Let’s break it down:

The Core Components

GatewayClass

Defines the “blueprint” for how Gateways are provisioned.

Usually provided by a controller (like NGINX, Traefik, Istio, Cilium).

Example: nginx, istio, or cilium GatewayClass.

Gateway

An instance of a GatewayClass.

Think of it as the data-plane entry point (like a load balancer or proxy).

It defines listeners (ports, protocols, TLS config).

Routes (HTTPRoute, TCPRoute, GRPCRoute, TLSRoute, etc.)

Define how traffic flows once it hits the Gateway.

Each Route type matches a specific protocol.

Routes are attached to Gateways using parentRefs.

Gateway Controller

The real engine under the hood.

Each GatewayClass is implemented by a controller (e.g., nginx-gateway-controller, cilium-gateway-controller).

The controller watches Gateway + Route objects, configures the data plane (like Envoy, NGINX, HAProxy), and applies the rules.

TL;DR:
GatewayClass = template
Gateway = instance (entry point)
Route = traffic rules
Controller = brains that makes it work

Enabling Protocols in YAML

Unlike Ingress (which was HTTP/HTTPS only), Gateway API supports multiple protocols right out of the box. You specify them under the listeners section of the Gateway.

Here’s how:
HTTPS with TLS

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: https-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert

gRPC Example

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: grpc-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: grpc
    protocol: GRPC
    port: 50051

How It All Comes Together:

The infra team creates a GatewayClass and provisions a Gateway. This is like dropping a load balancer in front of the cluster.
The app teams create HTTPRoute, TCPRoute, or GRPCRoute objects that attach to the Gateway.
The controller (e.g., Cilium, Istio, NGINX) watches these resources and updates the proxy or load balancer accordingly.
Boom 💥 — traffic flows according to your rules, across multiple protocols, without messy annotations.

Why This Matters

By splitting things into GatewayClass → Gateway → Routes, Kubernetes now supports:

Clear separation of duties (infra vs app teams).
Native support for more than just HTTP.
A standardized way for controllers to extend functionality.
Future-ready traffic management (mTLS, retries, canaries, etc.).

Understanding Init Containers in Kubernetes: Use Cases, Examples, and Best Practices

Noushad Hasan — Thu, 19 Jun 2025 10:45:38 +0000

Introduction

Kubernetes gives you a powerful way to manage your containerised applications but what happens when your app needs a little prep work before it runs? That’s where init containers come in.

Think of init containers as setup assistants. They handle important tasks like waiting for a database, setting permissions, or pulling down config files—before your main app even starts. In this guide, you’ll learn what init containers are, when to use them, how to write them, and the best ways to keep them secure and reliable.

Whether you’re just getting started with Kubernetes or you're building more complex deployments, init containers can help you build apps that start right—and stay running.

What Are Init Containers and Where Are They Used?

Init containers are special containers that run before your main application containers in a Kubernetes pod. Their job is to get everything ready before your app kicks off.

Common Use Cases:

Setting up configs: Pulling configuration files from a repo or service
Database readiness: Waiting for a database to become available
Secrets: Grabbing secrets from tools like HashiCorp Vault
Permissions: Fixing file permissions before your app starts
Data sync: Downloading large assets or syncing from a repo
Health checks: Making sure a service is reachable before launching

Each init container runs one at a time, in the order you define. If any of them fail, your main app won’t start—so you can be sure everything is ready.

When Should You Use Init Containers?

Init containers are useful when:

Your app needs something else to be ready (like a database).
You want to keep setup logic separate from your app.
The setup requires tools not included in your main container.
Tasks need to run in a specific order.
You want to keep your app image clean and lightweight.

When Not to Use Them

For background tasks that need to run alongside your app.
For anything that needs to keep running or restart if it fails.
For simple tasks that don’t affect whether your app can start.

How to Use Init Containers (With Example)

Here’s a practical example of using init containers to wait for a database and clone config files before starting the app -

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:1.0
    ports:
    - containerPort: 80
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  initContainers:
  - name: init-db
    image: busybox:1.28
    command: ['sh', '-c', 'until nc -z database-service 3306; do echo waiting for database; sleep 2; done;']
  - name: init-config
    image: alpine/git
    command: ['git', 'clone', 'https://github.com/myorg/config-repo.git', '/etc/config']
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    emptyDir: {}

What’s happening here:

init-db waits until the database is up and reachable.
init-config clones a Git repo into a shared volume.
Both steps must succeed before the main container starts.
The config is shared using a volume mounted in both containers.

Benefits of Using Init Containers

Here’s why init containers are worth using:
✅ Keep things separate: Setup logic stays out of your main app

✅ Order matters: Ensure steps run in the right sequence

✅ Improve security: Run init containers with limited permissions

✅ Lightweight images: Use special-purpose images for setup tasks

✅ Better reliability: Don’t start your app unless everything’s ready

✅ Easier debugging: If something breaks, you’ll know it’s in the setup

✅ Flexible tools: Use different languages, packages, or shells

Potential Backdoors and Security Considerations

Init containers can introduce risks if not handled carefully:
Watch Out For:

Too many privileges: Avoid running init containers as root unless absolutely needed.
Secret exposure: Be careful when fetching and storing secrets.
Bad images: Vulnerable or untrusted images can open up your cluster.
Persistent changes: Anything written to shared volumes will stick around.

Mitigation Tips:

Give init containers only the permissions they need.
Use read-only filesystems if possible.
Scan init container images for vulnerabilities regularly.
Use PodSecurityPolicies (or PodSecurity Standards) to control what containers can do.
For temporary debugging, use ephemeral containers instead.

Conclusion

Init containers give you control and flexibility when starting up your applications in Kubernetes. They make sure everything your app needs is ready before it even starts.

Key Takeaways:

Use them for one-off setup tasks
Keep setup logic clean and separate
Use secure, minimal images
Monitor their execution for early warning signs

If you’re just starting with Kubernetes, init containers might feel like “extra work.” But once you use them, you’ll see how they can simplify your app logic, boost reliability, and give you a cleaner deployment process.

[Boost]

Noushad Hasan — Tue, 27 May 2025 05:03:58 +0000

Noushad Hasan

May 27 '25

Debugging Docker? You’re Probably Missing This Hidden Gem

#docker #containers #monitoring #devops

Comments

2 min read

Debugging Docker? You’re Probably Missing This Hidden Gem

Noushad Hasan — Tue, 27 May 2025 04:56:32 +0000

Everyone uses Docker, but almost no one knows how to really debug a container.

No, I’m not talking about the usual suspects:

`docker logs` → often empty or useless

`docker inspect` → static snapshot

`docker exec` → can’t attach before the container dies

Sound familiar?

When your container crashes in production (but works fine locally), you end up in a loop: tweaking the Dockerfile, redeploying, and praying.

But there’s a better way.
Enter docker events – The Secret Weapon

This little-known command streams real-time, low-level events straight from the Docker daemon. It exposes what docker logs won’t tell you.

Example:

Your container keeps restarting. The logs show nothing. Instead of guessing, run:

docker events --filter container=<your_container_id>

Output:

2025-05-04T18:20:01Z container create ...  
2025-05-04T18:20:02Z container start ...  
2025-05-04T18:20:03Z container health_status: unhealthy ...  
2025-05-04T18:20:04Z container kill signal=SIGTERM  
2025-05-04T18:20:04Z container restart

Boom. Now you see:

Health check failed → Container killed → Docker auto-restarted it Your app logs? They won’t show this. The health check runs outside your main process.

Pro Tips:

Filter by time:

docker events --filter contaner=<container-id> --since="30m" --until "2025-05-04T18:00:00"

Structured JSON output:

docker events --filter container=<cont_id> --since="5m" --format '{{json .}}' | jq

But What About Observability Tools?

Sure, Grafana, Prometheus, and Loki are great. But they won’t catch:

OOM kills before metrics are scraped
Failed volume mounts
Init containers that crash silently
Sidecars restarting in the background

docker events sees everything—in real time.
If you’re debugging Docker without it, you’re not debugging. You’re guessing.

DEV Community: Noushad Hasan

Kubernetes Gateway API

Gateway API in Kubernetes: The Next Evolution in Traffic Management

Understanding Init Containers in Kubernetes: Use Cases, Examples, and Best Practices

Introduction

What Are Init Containers and Where Are They Used?

When Should You Use Init Containers?

When Not to Use Them

How to Use Init Containers (With Example)

Benefits of Using Init Containers

Potential Backdoors and Security Considerations

Conclusion

[Boost]

Debugging Docker? You’re Probably Missing This Hidden Gem

Debugging Docker? You’re Probably Missing This Hidden Gem

Example:

Output:

Pro Tips:

Structured JSON output:

Found this useful? Repost ♻️ to save your team hours of debugging pain.