You have mentioned in Github that you were able to overcome this issue.

For everyone else, here is the context and a bit more information.

In very early CFCR days, we did not support cloud provider and basically could not give access to the applications and API outside of the cluster. We had HA Proxies to give access to workloads and API.  At that point, several early adopters told us that they would like to try exposing routes in more dynamic way a-la CFAR and possibly reuse existing routing layer. The main point was that we would like to provision multiple clusters with ease and without changed to Cloud Config.

As result we created a route-sync. 

It solves two problems:

- have stable and known URL for the API, so we can use to sign the certificate

- have a way to expose applications

For API, we suggest people to wire their load balancers directly and then add the URL to the manifest. For example, check how BBL does it https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches/cfcr-gcp

For workloads, we suggest using Kubernetes Cloud Providers https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/ and Ingress Controllers https://kubernetes.io/docs/concepts/services-networking/ingress/

Yes, CFCR team is moving further to the "vanilla" Kubernetes. But we expect other team to provide solutions for both worlds. We don't have enough deep knowledge of CFAR components and getting this knowledge will slow us down in improving Kubernetes experience. 

We are ready to help anyone to understand Kubernetes more and provide better experience with both runtimes.

Sincerely,

Oleksandr