A common kubernetes pattern is being able to create a Service of type LoadBalancer that provisions an external resource to get L4 traffic into the cluster for cases that aren't covered by Ingress/Gateway. While you can currently do this today using the TCPEdge, TLSEdge, and Tunnel CRDs, it can be tedious to do this and has a high potential for errors when creating the backend labels by hand. In addition, there exists a number of community tools that interact with kubernetes core types, but not CRDs. For example, external-dns can update DNS records based off of Load Balancer service's status, but doesn't know how to watch ngrok CRDs.
Instead, we have everything we need on the existing Service that we want to expose and can create the Tunnel and TLS/TCP Edge from the service.
How
Introduces a new Service controller which watches service objects that have a loadBalancerClass=ngrok
This controller calculates the required Tunnel and TLS/TCP Edge and creates the ngrok CRDs, updates them, and deletes them as required.
Resolves #375
What
A common kubernetes pattern is being able to create a
Serviceof typeLoadBalancerthat provisions an external resource to get L4 traffic into the cluster for cases that aren't covered by Ingress/Gateway. While you can currently do this today using theTCPEdge,TLSEdge, andTunnelCRDs, it can be tedious to do this and has a high potential for errors when creating the backend labels by hand. In addition, there exists a number of community tools that interact with kubernetes core types, but not CRDs. For example, external-dns can update DNS records based off of Load Balancer service's status, but doesn't know how to watch ngrok CRDs.Instead, we have everything we need on the existing
Servicethat we want to expose and can create theTunnelandTLS/TCP Edgefrom the service.How
loadBalancerClass=ngrok