Date
1 - 6 of 6
Deprecate route-sync from CFCR to CFAR
|
Hi, cf-dev
Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment. We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team. If someone uses it, please contact us via email or Slack (#cfcr). Thanks, Oleksandr |
|
|
|
arghya88@...
Hi Oleksandr, What alternative do we have if we want to use kubectl with tls Thanks, Arghya On Fri, Jul 13, 2018, 3:01 PM <oslynko@...> wrote: Hi, cf-dev |
|
|
|
Gabriel Rosenhouse <grosenhouse@...>
Also: I suspect that the CFCR route-sync feature has a dangerous interaction with CFAR Cloud Controller, if both CFCR and CFAR are sharing a TCP Routing API. CFAR Cloud Controller creates and uses a TCP Router Group for itself, and expects to completely own that router group. My reading of the CFCR code is that route-sync will happily discover and use that Router Group as-is. The CFAR Routing API has no mechanism to prevent this collision, or to prevent the two clients from reserving the same TCP port for different backends. I think that the result will be that ingress to that TCP Router Port will get load balanced to both the CFAR App and the CFCR Service. This is likely not what the user intends. On Fri, Jul 13, 2018 at 4:14 AM, arghya sadhu <arghya88@...> wrote:
|
|
|
|
Shannon Coen
That issue could be addressed by having CFCR use a different router group, which is part of the solution we have proposed here: https://docs.google.com/document/d/1RXu-o44zxwrU5gKqsghT86hXKwgPrPpSk6-TWSTlrBs/edit Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Fri, Jul 13, 2018 at 11:47 AM Gabriel Rosenhouse <grosenhouse@...> wrote:
|
|
|
|
Hi Arghya, 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. History 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 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/ 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. Sincerely, Oleksandr |
|
|
|
Hi
Oleksandr
and Shannon, I wonder what's the current plan for routing to CFCR workloads from CFAR ? Is there a concensus towards the proposed usage of TCP router [1] with an associated
CloudFoundryRouteController component, or rather leverage K8S cloud providers ?Which team would be working on this as I could not yet find related stories in the routing/tcp-routing/kubo pivotal trackers [2][3][4] Thanks in advance, Guillaume. On Mon, Jul 16, 2018 at 12:57 PM, Oleksandr Slynko <oslynko@...> wrote:
|
|
|