KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  

 

KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  

 

In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  

 

It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  

 

There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  

 

You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 

 

Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  

 

So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 

 

Thanks! 

 

SUSE Cloud Foundry Team 

KubeCF (formerly the v3 branch of SUSE/scf) produces builds of CFAR which can be deployed to Kubernetes with Helm and managed by the cf-operator. Though this is currently in the SUSE namespace, the plan is to make this an upstream project under the Runtime PMC.  

 

KubeCF releases are passing CATS and we are on track for a 0.1.0 release of KubeCF this month, after which SUSE will transferring this repo to Cloud Foundry Foundation control.  

 

In other words, the Cloud Foundry *community* now has a CFAR distribution for Kubernetes that closely tracks cf-deployment.  

 

It exists. You can use it. If you work on a Runtime PMC project, KubeCF already consumes your BOSH release and packages it for Kubernetes.  

 

There has been a lot of discussion in the Kubernetes SIG meetings about how component teams should ultimately build truly "Kube-native" CFAR components which would not rely on BOSH or cf-operator.  Some teams have already started to refactor or rewrite their CFAR components to deliver Kubernetes artifacts (containers with Kubernetes YAML, YTT templates, or Helm charts).  

 

You don't have to do this in isolation! The members of the Quarks team have years of experience packaging CFAR for Kubernetes. They can be a great resource when making design decisions for your project, and are open to working with you. 

 

Though we want to ensure teams have a certain amount of freedom to create their releases with the tools of their choosing, these releases must eventually come together in a cohesive CFAR release that is deployable and manageable with tools familiar to the Kubernetes community. Right now, we use BOSH releases as the contract between individual components and cf-deployment releases. With KubeCF, you can optionally substitute Helm charts for BOSH releases, but this could be extended to support Kubernetes YAML or other templating mechanisms.  

 

So, if you're working on Kube-ifying your piece of CFAR, get in touch with the Quarks team on #quarks-dev and let them know how they can help, or how you could help! 

 

Thanks! 

 

SUSE Cloud Foundry Team