I merged #525 to develop by mistake. Reopening this to merge to contour-ingress branch.
By removing the system component's dependency on Istio Virtual Services and using Ingress, will be able to support multiple Ingress solutions (e.g. Contour), with the Ingress API which is leveraged by both Istio and Contour.
When I have a cluster deployed with this PR
And I get the ingresses with kubectl get -n cf-system ingress
Then I see uaa, and capi Ingress resources called capi-external and uaa-external
And when I get Virtual Services with kubectl get -n cf-system vs
Then I only see log-cache Virtual Service*
And I can push apps and see logs
I merged #525 to develop by mistake. Reopening this to merge to
contour-ingress
branch.By removing the system component's dependency on Istio Virtual Services and using Ingress, will be able to support multiple Ingress solutions (e.g. Contour), with the Ingress API which is leveraged by both Istio and Contour.
#175234234
Acceptance Steps
When I have a cluster deployed with this PR And I get the ingresses with
kubectl get -n cf-system ingress
Then I see uaa, and capi Ingress resources calledcapi-external
anduaa-external
And when I get Virtual Services withkubectl get -n cf-system vs
Then I only seelog-cache
Virtual Service* And I can push apps and see logsTag your pair, your PM, and/or team
@cloudfoundry/cf-for-k8s-networking