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.
What is does
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
How we solve it now
Are we diverging further from CFAR?
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.