Careful!
You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
Use Kong as a delegated Gateway
To get traffic from outside your mesh inside it (North/South) with Kuma you can use a delegated gateway.
In the quickstart, traffic was only able to get in the mesh by port-forwarding to an instance of an app inside the mesh. In production, you typically set up a gateway to receive traffic external to the mesh. In this guide you will add Kong as a delegated gateway in front of the demo-app service and expose it publicly.
--- title: service graph of the demo app with a Kong gateway on front --- flowchart LR subgraph Kong Gateway gw0(/ :80) end demo-app(demo-app :5000) redis(redis :6379) gw0 --> demo-app demo-app --> redis
Prerequisites
- Completed quickstart to set up a zone control plane with demo application
Install Kong ingress controller
Follow the steps on the Kong docs website to install the ingress controller.
The Kubernetes cluster needs to support LoadBalancer
for this to work.
If you are running minikube
you will want to open a tunnel with minikube tunnel -p mesh-zone
.
You may not have support for LoadBalancer
if you are running locally with kind
or k3d
.
One option for kind
is kubernetes-sigs/cloud-provider-kind may be helpful.
Enable sidecar injection on the kong
namespace
The Kong Ingress controller was installed outside the mesh. For it to work as a delegated gateway restart it with sidecar injection enabled:
Add the label:
kubectl label namespace kong kuma.io/sidecar-injection=enabled
Restart both the controller and the gateway to leverage sidecar injection:
kubectl rollout restart -n kong deployment kong-gateway kong-controller
Wait until pods are fully rolled out and look at them:
kubectl get pods -n kong
It is now visible that both pods have 2 containers, one for the application and one for the sidecar.
NAME READY STATUS RESTARTS AGE
kong-controller-675d48d48-vqllj 2/2 Running 2 (69s ago) 72s
kong-gateway-674c44c5c4-cvsr8 2/2 Running 0 72s
Retrieve the public URL for the gateway with:
export PROXY_IP=$(kubectl get svc --namespace kong kong-gateway-proxy -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $PROXY_IP
Verify the gateway still works:
curl -i $PROXY_IP
which outputs that there are no routes defined:
HTTP/1.1 404 Not Found
Date: Fri, 09 Feb 2024 15:25:45 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Content-Length: 103
X-Kong-Response-Latency: 0
Server: kong/3.5.0
X-Kong-Request-Id: e7dfe659c9e46639a382f82c16d9582f
{
"message":"no Route matched with those values",
"request_id":"e7dfe659c9e46639a382f82c16d9582f"
}%
Add a route to our demo-app
Patch our gateway to allow routes in any namespace:
kubectl patch --type=json gateways.gateway.networking.k8s.io kong -p='[{"op":"replace","path": "/spec/listeners/0/allowedRoutes/namespaces/from","value":"All"}]'
This is required because in the Kong ingress controller tutorial the gateway is created in the default
namespace.
To do this the Gateway API spec requires to explicitly allow routes from different namespaces.
Now add the gateway route in our kuma-demo
namespace which binds to the gateway kong
defined in the default
namespace:
echo "
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: demo-app
namespace: kuma-demo
spec:
parentRefs:
- name: kong
namespace: default
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: demo-app
kind: Service
port: 5000
" | kubectl apply -f -
This route is managed by the Kong ingress controller and not by Kuma.
Now call the gateway:
curl -i $PROXY_IP/
Which outputs:
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=UTF-8
Content-Length: 19
Connection: keep-alive
date: Fri, 09 Feb 2024 15:51:10 GMT
server: envoy
x-envoy-upstream-service-time: 0
X-Kong-Upstream-Latency: 2
X-Kong-Proxy-Latency: 0
Via: kong/3.5.0
X-Kong-Request-Id: 3b9d7d0db8c4cf25759d95682d6e3573
RBAC: access denied%
Notice the forbidden error. This is because the quickstart has very restrictive permissions as defaults. Therefore, the gateway doesn’t have permissions to talk to the demo-app service.
To fix this, add a MeshTrafficPermission
:
echo "
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
namespace: kuma-system
name: demo-app
spec:
targetRef:
kind: MeshService
name: demo-app_kuma-demo_svc_5000
from:
- targetRef:
kind: MeshSubset
tags:
app.kubernetes.io/name: gateway
k8s.kuma.io/namespace: kong
default:
action: Allow
" | kubectl apply -f -
Call the gateway again:
curl -i $PROXY_IP/increment -XPOST
Notice that the call succeeds:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 41
Connection: keep-alive
x-powered-by: Express
etag: W/"29-iu9zuSv48n703xjnEeBnBQzQFgA"
date: Fri, 09 Feb 2024 15:57:27 GMT
x-envoy-upstream-service-time: 7
server: envoy
X-Kong-Upstream-Latency: 11
X-Kong-Proxy-Latency: 0
Via: kong/3.5.0
X-Kong-Request-Id: 886cc96df034ea37cfbbb0450a987049
{"counter":149,"zone":"local","err":null}%
Next steps
- Read more about the different types of gateways in the managing ingress traffic docs.
- Learn about setting up observability to get full end to end visibility of your mesh.