Support API gateway ingress solutions in network view

[cyrus-mc]

Summary

There are many API gateway solutions (such as Ambassador - https://www.getambassador.io/) which act as an ingress for services.

As opposed to an ingress API object these services map routes/paths/etc through solution specific means (usually CRD; example https://www.getambassador.io/docs/latest/topics/using/intro-mappings/) and are almost always exposed via a Service (sometimes Ingress) with type LoadBalancer.

It would be nice if ArgoCD was able to rendered the network traffic flow when using these type of ingress solutions.

Motivation

API Gateway are a common pattern to expose microservices. Within the Kubernetes ecosystem there exist various solutions such as Ambassador, Kong and APIGee in which microservices are routed through the API gateway solution which itself is exposed via a standard service object (usually with Type LoadBalancer).

Traffic flow is as follows:

External LB (Service) -> API Gateway (POD(s)) -> Mapping/Route (CRD) -> Service -> POD(s)

Having the ability to see the network flow and object association in the network view would beneficial to end users/developers.

Proposal

The majority of API gateway solutions functions the same way. First the API gateway itself is exposed via a standard service API object (with type LoadBalancer). Then application POD or Services are mapped to various routes within the API gateway through configuration (this configuration is almost always done via CRD).

This results in a bit of an indirect relationship between the ingress object (service or ingress) and the actual service/POD (whereas Service objects map directly to PODs via selectors and Ingress objects directly to services, which in turn map to PODs).

In order to associate the ingress object with the actual service/CRD I propose annotating the necessary objects such that the association can be done at sync or render time.

i.e:

In terms of Ambassador, which uses the Mapping CRD:

apiVersion: getambassador.io/v2
kind: Mapping
metadata:
  annotations:
    argocd.argoproj.io/ingress: ambassador
  name: example
spec:
  service: helm-helloworld.test
  prefix: /helloworld/
  rewreite: /
...

Would be associated with service ambassador in the same namespace as CRD. Or you can specify the namespace in the value of the annotation (i.e: default/ambassador).

During the cluster sync phase or application rendering, we can update associate these two objects.

[cyrus-mc]

I have already started on a PR to add this functionality and will be opening that within the next day or so and linking back to this issue.

[cyrus-mc]

Example of what this should look like.

This shows a test deployment that supports blue / green rollout.

[cyrus-mc]

@alexmt @jannfis

Looking to get some eyes on this proposal. I also have a working PR implementing the above.

[benjamin-bergia]

HI, I am currently testing Contour and I would also be interested if ArgoCD could support the HTTPProxy resource in the network view.

[trevor-vaughan]

I'm interested in this, but the implementation might be a bit interesting.

For instance, includes are widely used in HTTPProxy and I'm not sure how this would show in the GUI.