Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Decouple gslb from the kubernetes Ingress resource (#1557)
* Decouple gslb from the kubernetes Ingress resource This change makes the GSLB resource independent of a Kubernetes Ingress. This is a first step to allow integrations with other ingress Resources (e.g. istio virtual services for Istio Gateway, HTTP routes for Gateway API) #552 The change is fully backwards compatible, embedding an Ingress resources will still behave the same way it worked before. In addition to the code refacting a new ResourceRef field is introduced. This field allows referencing resources that are not embedded in the GSLB definition and opens the gates to reference any resource types. As an example, the configuration bellow allows a GSLB resource to load balance the application defined in the Ingress resource on the same namespace with labels `app: demo` ``` spec: resourceRef: ingress: matchLabels: app: demo ``` --- Implementation details A couple of functions crucial for business logic, namely `GslbIngressExposedIPs` and `getServiceHealthStatus`, need to read configuration present in the Ingress resource. Since the code would become too complicated once new ways to configure ingress are integrated, the format of the data they depend on was generalized from the Kubernetes Ingress resource to an ingress agnostic format. The processing of the data looks as follows: A new `GslbReferenceResolver` interface was created. An implementation of this interface is capable of understanding a type of ingress configuration (e.g.: kubernetes' ingress, istio's virtual service, gateway API's http route) and implements two functions: `GetServers` and `GetGslbExposedIPs`. These functions extract the backends of the applications and the IP addresses they are exposed on, respectively. Once a reconciliation operation is triggered a new `GslbReferenceResolver` is instatiated. Then, the list of servers and the exposed IPs are read and stored in the status of the GSLB resource. Finally, the rest of the logic remains the same, with the difference that functions implementing business logic read the configuration from the status instead of looking up the Kubernetes Ingress resource. --- Points for discussion: * Should the list of servers and exposed IPs be stored in the status of GSLB resource? An internal data structure would also work, however we would need to pass it as an argument to numerous functions. * There is already a `depresolver` interface. Even though the names look similar `depresolver` resolves startup configuration, while `refresolver` resolves runtime configuration. In addition, logging is useful to communicate with the users but a logger cannot be instantiated in the `depresolver` package because it would lead to circular dependencies. For these reasons, a new package was created instead of adding this logic to the `depresolver` package. Naming of the package can also be discussed, the proposal `refresolver` comes from the fact that it resolves references to other resources. Signed-off-by: abaguas <andre.aguas@protonmail.com> * go lint Signed-off-by: abaguas <andre.aguas@protonmail.com> * go lint Signed-off-by: abaguas <andre.aguas@protonmail.com> * terratest roundrobin Signed-off-by: abaguas <andre.aguas@protonmail.com> * fix namespace isolation Signed-off-by: abaguas <andre.aguas@protonmail.com> --------- Signed-off-by: abaguas <andre.aguas@protonmail.com>
- Loading branch information
