Ingress

Implements a Kubernetes ingress controller using tunnels to connect a Web Relay managed URL (https://yoursubdomain.webrelay.io) to a Kubernetes service based on ingress resources. Single ingress controller can manage multiple tunnels and route to multiple namespaces.

Deployment files and issue tracker is available on GitHub:

https://github.com/webrelay/ingress

Introduction

Have you ever created a Kubernetes deployment and then spent a considerable amount of time just thinking about how to actually connect to the application?

Configuring load balancers on every cloud requires slightly different resources and settings. Web Relay ingress changes that; every cloud is equal, even the one on your laptop. It opens a reverse tunnel to expose your services. No public IP or external load balancer is required. Therefore, Web Relay ingress controller is a perfect tool for testing, developing and demoing your Kubernetes applications.

Web Relay ingress

This guide covers Web Relay ingress controller installation steps as well as an example ingress resource file for your application to be exposed through Web Relay tunnel.

If you have any questions feel free to contact us [email protected].

Installation

You can try out Web Relay ingress controller by creating a deployment from a hosted manifest, no clone or local install necessary.

What you do need:

To add Web Relay ingress controller to your cluster, run:

relay ingress init

Manifests are available here: https://github.com/webrelay/ingress/tree/master/deployment

This command:

If RBAC isn’t enabled on your cluster (for example, if you’re on GKE with legacy authorization or Minikube without RBAC), run:

relay ingress init --no-rbac

You can also generate tokens through the Web UI here https://my.webhookrelay.com/tokens or relay token create command on the CLI.

Configuration

In order for your application to be exposed, an ingress resource has to be created that defines relationships between virtual hosts (tunnel public endpoints) and internal services (names and their ports). Feel free to read more about ingresses at Kubernetes documentation page.

If you are on a free plan, then you should create tunnels either through UI or via CLI before creating an ingress resource file as free plan doesn’t have custom subdomains. Once you create a tunnel, use tunnel’s hostname in your ingress.yaml.

Ingress controller will try to dynamically create tunnels if they are not present. Custom subdomains are available for all paid plans. However if you are on a free plan, you will have to create a tunnel first. If you wish to change or upgrade plan, please visit plans page.

Dynamic tunnel names

Relay Ingress with Kuard

Create an ingress resource with webrelay class. Replace host, serviceName and servicePort with your desired domain and services:

# ingress.yml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: webrelay # other ingress classes will be ignored
name: relay-ingress
namespace: default
spec:
rules:
- host: <your subdomain>.webrelay.io
http:
paths:
- path: /
backend:
serviceName: <your service name>
servicePort: <your service port>

Each virtual host rule will create a separate tunnel.

kubectl apply -f ingress.yml

After a few seconds, a tunnel should be configured and ready:

$ relay ingress ls
ID NAME HOST BACKENDS CRYPTO AUTH AGE
50bd538d-ab43-4003-a25e-097b6410a498 webrelay-ingress-kuard.webrelay.io kuard.webrelay.io default/kuard/8080 off - 2 minutes

You can also see your current tunnels at: https://my.webhookrelay.com/tunnels.

Pre-configured tunnel names

Since free plan does not provide custom subdomains; users need to create a tunnel before defining an ingress resource file. So, the first step is to create
a tunnel that belongs to a group webrelay-ingress:

$ relay tunnel create --group webrelay-ingress mytunnel
oomdwdehm6l9oiilsm6trc.webrelay.io<---->http://127.0.0.1

Now, if you check your ingresses:

$ relay ing ls
ID NAME HOST BACKENDS CRYPTO AUTH AGE
6c83e6dd-fbc5-41f1-a7af-76237b4602bf mytunnel oomdwdehm6l9oiilsm6twa.webrelay.io off - 2 minutes

And then the last step is to modify ingress host field to the newly acquired tunnel’s host:

# ingress.yml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: webrelay # other ingress classes will be ignored
name: relay-ingress
namespace: default
spec:
rules:
- host: oomdwdehm6l9oiilsm6twa.webrelay.io # <- host has to match tunnel host
http:
paths:
- path: /
backend:
serviceName: <your service name>
servicePort: <your service port>

After a few seconds tunnel should be updated with the ingress route rules and service will be accessible through the supplied host.

Troubleshooting

If you encounter any problems that the documentation does not address, file an issue, send us an email.

Send us an email

FAQ