Kubernetes service discovery is a critical component of most applications as they rely on DNS to resolve other services. Netbird enables exposing resources inside and outside of Kubernetes in the for of a network resource. The network resource can be addressed by IP or DNS depending on how it is configured. A common request from end users is to simplify the process of both exposing Kubernetes services to the wide network, and also "importing" Netbird resources into Kubernetes service discovery.
The former is implemented currently with the help of annotations on services. While it does allow for a certain level of configuration it does have its drawbacks. A major one is the use of a shared cluster domain which can cause collisions as described in #69. We need to be able to support exposing the same service in different clusters even when they are in the same namespace and have the same name. One option would be to adopt some of the standards proposed in multicluster.
The latter has to do with importing select Netbird services into Kubernetes service discovery to allow for simple routing across cluster. This is a bit more complicated as it requires possibly modifying the core dns running in the cluster to add another zone pointing to the local Netbird DNS server.
The best way forward right now is to continue the work in #117 to add integrations with TCPRoutes to expose Services. Allowing us to abandon the use of Service annotations in the future. TCPRoutes could also be used to import services in other clusters but more exploration needs to be done in that department.
Kubernetes service discovery is a critical component of most applications as they rely on DNS to resolve other services. Netbird enables exposing resources inside and outside of Kubernetes in the for of a network resource. The network resource can be addressed by IP or DNS depending on how it is configured. A common request from end users is to simplify the process of both exposing Kubernetes services to the wide network, and also "importing" Netbird resources into Kubernetes service discovery.
The former is implemented currently with the help of annotations on services. While it does allow for a certain level of configuration it does have its drawbacks. A major one is the use of a shared cluster domain which can cause collisions as described in #69. We need to be able to support exposing the same service in different clusters even when they are in the same namespace and have the same name. One option would be to adopt some of the standards proposed in multicluster.
The latter has to do with importing select Netbird services into Kubernetes service discovery to allow for simple routing across cluster. This is a bit more complicated as it requires possibly modifying the core dns running in the cluster to add another zone pointing to the local Netbird DNS server.
The best way forward right now is to continue the work in #117 to add integrations with TCPRoutes to expose Services. Allowing us to abandon the use of Service annotations in the future. TCPRoutes could also be used to import services in other clusters but more exploration needs to be done in that department.