The Gateway API isn’t simply an “Ingress v2”, it’s a wholly revamped strategy for exposing companies from inside Kubernetes and eliminates the necessity of encoding routing capabilities into vendor-specific, unstructured annotations. On this submit, we’ll discover tips on how to expose WebAssembly purposes constructed utilizing the CNCF Spin framework and served by SpinKube utilizing the Gateway API.
What’s SpinKube
SpinKube, a CNCF sandbox undertaking, is an open-source stack for working serverless WebAssembly purposes (Spin apps) on prime of Kubernetes. Though SpinKube leverages Kubernetes primitives like Deployments, Companies and Pods, there are not any containers concerned for working your serverless Spin apps in any respect. As a substitute, it leverages a containerd-shim implementation and spawns processes on the underlying Kubernetes employee nodes for working Spin apps.
You’ll be able to study extra about SpinKube and discover detailed directions on tips on how to deploy SpinKube to your Kubernetes cluster at
What’s Gateway API
The Gateway API is the fashionable, role-oriented successor to the legacy Ingress useful resource, designed to supply a extra expressive and extensible networking interface for Kubernetes. Not like Ingress, which frequently depends on a messy sprawl of vendor-specific annotations to deal with advanced logic, the Gateway API breaks visitors administration into atomic sources —GatewayClass, Gateway, and routes (like HTTPRoute or GRPCRoute).
This separation permits infrastructure admins to handle the entry factors whereas giving builders management over how their particular companies are uncovered, enabling native help for superior visitors patterns like canary rollouts, header-based routing, and visitors mirroring with out the necessity for bespoke configurations.
To dive deeper into the technical specs and useful resource hierarchy, head over to the official Gateway API documentation.
Provisioning a Kubernetes cluster, putting in SpinKube and implementing Spin apps are thought of past the scope of this text. Nonetheless, you may head over to – a repository containing all supply code, together with the required directions for organising a LKE cluster with SpinKube.
To comply with the article’s demo, you’ll deploy the required artifacts to your Kubernetes cluster. Be sure to have the next instruments put in:
Construct and deploy the Spin apps to Kubernetes
Let’s begin by compiling the supply code of our pattern Spin apps all the way down to WebAssembly. Doing so is as simple as executing the spin construct command from inside every software folder:
# Construct the greeter software
pushd apps/greeter
spin construct
Constructing part greeter with `cargo construct --target wasm32-wasip1 --release`
Completed `launch` profile [optimized] goal(s) in 0.21s
Completed constructing all Spin parts
popd
# Construct the prime_numbers software
pushd apps/prime-numbers
spin construct
Constructing part prime-numbers with `cargo construct --target wasm32-wasip1 --release`
Completed `launch` profile [optimized] goal(s) in 0.18s
Completed constructing all Spin parts
popd
As soon as the applying has been compiled, we use the spin registry push to distribute it as OCI artifact. (In case your OCI compliant registry requires authentication, you have to login first. Use the spin registry login to authenticate earlier than making an attempt to push).
Tip: For testing functions, we’ll use ttl.sh an nameless and ephemeral OCI compliant registry, which permits us to retailer our purposes for twenty-four hours by merely specifying the TTL as a tag.
# specify variables
greeter_app_artifact=ttl.sh/spin-greeter:24h
primenumbers_app_artifact=ttl.sh/spin-prime-numbers:24h
# non-obligatory: Authenticate in opposition to registry
oci_reg_server=
oci_reg_user=
oci_reg_password=
spin registry login $oci_reg_server -u $oci_reg_user -p $oci_reg_password
# distribute the Spin purposes
pushd apps/greeter
spin registry push $greeter_app_artifact --build
popd
pushd apps/prime-numbers
spin registry push $primenumbers_app_artifact --build
popd
Lastly, we use the spin kube scaffold command for producing the required Kubernetes manifests.
Tip: Spin doesn’t have any opinions on the way you deploy sources to your Kubernetes cluster. You’ll be able to both use kubectl, create a Helm chart and deploy it utilizing the helm CLI, or describe the specified state and deploy it with GitOps.
For the sake of this text, we’ll merely pipe the generated manifest to kubectl apply. The precise manifests are proven right here for illustration functions:
# Deploy the Spin purposes to Kubernets
spin kube scaffold --from $greeter_app_artifact | kubectl apply -f -
spin kube scaffold --from $primenumbers_app_artifact | kubectl apply -f -
apiVersion: core.spinkube.dev/v1alpha1
sort: SpinApp
metadata:
title: spin-greeter
spec:
picture: "ttl.sh/spin-greeter:24h"
executor: containerd-shim-spin
replicas: 2
---
apiVersion: core.spinkube.dev/v1alpha1
sort: SpinApp
metadata:
title: spin-prime-numbers
spec:
picture: "ttl.sh/spin-prime-numbers:24h"
executor: containerd-shim-spin
replicas: 2
Clearly, there are extra knobs you may flip when executing spin kube scaffold, I extremely encourage you to checkout the documentation for the command by offering the --help flag.
Testing the Spin app
We use conventional port-forwarding offered by kubectl to confirm that each Spin purposes runs as anticipated:
kubectl port-forward svc/spin-greeter 8080:80
Despatched a GET request to the applying utilizing curl:
curl -i localhost:8080/hiya/Akamaipercent20Developers
HTTP/1.1 200 OK
content-type: textual content/plain
transfer-encoding: chunked
date: Mon, 19 Jan 2026 13:55:34 GMT
Whats up, Akamai Builders!Subsequent, let’s check the second Spin software:
kubectl port-forward svc/spin-prime-numbers 8080:80Once more, use curl to invoke one of many endpoints uncovered by the Spin app:
curl -i localhost:8080/above/42
HTTP/1.1 200 OK
transfer-encoding: chunked
date: Mon, 19 Jan 2026 17:05:02 GMT
Subsequent prime quantity above 42 is 43Now that each apps are working, you may terminate port-forwarding once more (`CTRL+C) and dive into exposing each Spin apps.
Putting in Gateway API CRDs and Controller
To make use of the Gateway API, we should set up the corresponding Gateway API sources (CRDs) on our cluster together with a Gateway API Controller.
There are a number of controllers obtainable that implement the Gateway API. You will discover a listing of accessible Gateway API controllers at We’ll use NGINX Gateway Cloth for now.
To put in Gateway API sources run:
kubectl kustomize " | kubectl apply -f -To put in NGINX Gateway Cloth run:
helm set up ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway
Creating cluster-specific Gateway API sources
With the Gateway API controller put in, we’ll first deploy a Gateway to our cluster. Consider the Gateway as an entry level into your Kubernetes cluster, which could possibly be shared throughout a number of purposes. We’ll now create the spinkube Gateway, which can entrance our two Spin purposes which can be already working within the default namespace.
apiVersion: gateway.networking.k8s.io/v1
sort: Gateway
metadata:
title: spinkube
namespace: default
spec:
gatewayClassName: nginx
listeners:
- protocol: HTTP
port: 8080
title: http
allowedRoutes:
namespaces:
from: IdenticalWhen you’ve deployed the Gateway, you need to discover a new service being provisioned to the default namespace referred to as spinkube-nginx of sort LoadBalancer as soon as the cloud controller has acquired a public IP deal with, you need to discover it as a part of the output as properly.
kubectl get companies
NAME TYPE EXTERNAL-IP
spinkube-nginx LoadBalancer 172.238.61.25Notice down the exterior IP deal with of the spinkube-nginx service, we’ll use it in a couple of minutes to ship requests to our Spin purposes from outdoors of the cluster!
Creating application-specific Gateway API Assets
As we now have deployed two completely different Spin purposes to our Kubernetes cluster, we’ll additionally create two cases of HTTPRoute and hyperlink them to the Gateway we created within the earlier part.
Tip: As managing exterior DNS is past the scope of this text, we’ll use easy PathPrefix based mostly routing together with a Rewrite filter to route inbound requests to the specified Spin purposes.
Create the next HTTPRoute sources within the default namespace:
apiVersion: gateway.networking.k8s.io/v1
sort: HTTPRoute
metadata:
title: greeter
namespace: default
spec:
parentRefs:
- title: spinkube
guidelines:
- backendRefs:
- title: spin-greeter
port: 80
filters:
- sort: URLRewrite
urlRewrite:
path:
replacePrefixMatch: /
sort: ReplacePrefixMatch
matches:
- path:
sort: PathPrefix
worth: /greeter
---
apiVersion: gateway.networking.k8s.io/v1
sort: HTTPRoute
metadata:
title: prime-numbers
namespace: default
spec:
parentRefs:
- title: spinkube
guidelines:
- backendRefs:
- title: spin-prime-numbers
port: 80
filters:
- sort: URLRewrite
urlRewrite:
path:
replacePrefixMatch: /
sort: ReplacePrefixMatch
matches:
- path:
sort: PathPrefix
worth: /prime-numbers
Accessing the Spin apps
Having all Kubernetes sources in place, it’s time for a ultimate check. We found the general public IP deal with related to our Gateway earlier on this submit. Let’s use curl once more for sending requests to each Spin software:
# Ship request to the greeter app
curl -i http:///:8080/greet/hiya/Akamaipercent20Developers
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 19 Jan 2026 16:37:22 GMT
Content material-Sort: textual content/plain
Switch-Encoding: chunked
Connection: keep-alive
Whats up, Akamai Builders!
# Ship request to the prime-numbers app
curl -i http://:8080/prime-numbers/above/999
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 19 Jan 2026 16:37:50 GMT
Switch-Encoding: chunked
Connection: keep-alive
Subsequent prime quantity above 999 is 1009
As you may see, our requests get routed to the specified Spin software due to the trail prefix (both greeter or prime-numbers).
Conclusion
The Kubernetes Gateway API streamlines how we expose companies from inside a Kubernetes cluster and permits exact separation of issues. Cloud infrastructure and cluster operators create and handle sources that could possibly be shared throughout a number of purposes just like the Gateway, whereas software builders present software (or service) particular sources reminiscent of an HTTPRoute.
Particularly when working tens or a whole lot of various serverless purposes on prime of SpinKube it’s essential to have strong and dependable routing in place to make sure purposes are accessible from outdoors of the cluster. The Gateway API for Kubernetes makes managing these a breeze.
Contributors from Akamai collaborate on SpinKube growth to ship this runtime throughout its world cloud and edge. Further info is on the market.at akamai.com.
