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:
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.
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].
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:
kubectlconfigured with admin access to your cluster
relayCLI, installation instructions can be found here
To add Web Relay ingress controller to your cluster, run:
Manifests are available here: https://github.com/webrelay/ingress/tree/master/deployment
If RBAC isn’t enabled on your cluster (for example, if you’re on GKE with legacy authorization or Minikube without RBAC), run:
You can also generate tokens through the Web UI here https://my.webhookrelay.com/tokens or
relay token createcommand on the CLI.
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.
Create an ingress resource with
webrelay class. Replace
servicePort with your desired domain and services:
Each virtual host rule will create a separate tunnel.
After a few seconds, a tunnel should be configured and ready:
You can also see your current tunnels at: https://my.webhookrelay.com/tunnels.
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
Now, if you check your ingresses:
And then the last step is to modify ingress host field to the newly acquired tunnel’s host:
After a few seconds tunnel should be updated with the ingress route rules and service will be accessible through the supplied host.
If you encounter any problems that the documentation does not address, file an issue, send us an email.
relaydtunneling agent only supports HTTP protocol. Support for TCP exists but it has not been released. Furthermore, ingress resources can only define HTTP services and are not meant for any other purpose.