Cloud Foundry Advisory Board Meeting, Mar 2020: CF4K8s Demo
This month’s Cloud Foundry Community Advisory Board (CAB) meeting centered around the recent developments under CF4K8s, and how the initiative differs/relates to KubeCF. CF4K8s is a deployment artifact for the Cloud Foundry Application Runtime (CFAR) on Kubernetes. KubeCF is a distribution of CFAR for Kubernetes.
At the meeting, there were also discussions about the upcoming summit in Texas, as well as regular updates on the ecosystem projects. The call was moderated by Troy Topnik of SUSE.
CF4K8s: From a repo to an app in a month
During the call, Saikiran Yerram of Pivotal spoke about the progress and ongoing activities around CF4K8s. Saikiran noted that things are moving really fast with the research launched back in November 2019 and the first repository created in February 2020. The team prides itself on the fact that a
cf-push Docker app was also released back in February. This month, Saikiran demoed a
cf-push buildpacks app.
He also provided a high-level overview of what CF4K8s has under the hood. For instance, there are two namespaces: one for the deployed apps and one for the Cloud Foundry components and the dependencies. The team is using kapp to manage a Cloud Foundry life cycle. Thanks to kpack, which employes cloud-native buildpacks, it is possible to build images in a consistent and reproducible way. For templates, ytt is utilized. Istio manages intercomponent communication, such as security, enforcement policy, etc.
At the moment, the team is working on an alpha release, which will include
cf-push with buildpacks, HTTP app routing, and a hook for an external app registry. The next steps will involve running Cloud Foundry acceptance tests, validating CF4K8s on one another distro, and building a contribution model to consume component releases. Moving toward version 1.0, it is also planned to explore upgrade workflows, perform smoke testing, establish a workflow for CVE fixes, etc.
You can check out how to deploy and maintain CF4K8s, as well as how to contribute to the project, in the official documentation.
How CF4K8 and KubeCF differ?
According to Troy, SUSE, IBM, and SAP had been working on a sort of containerized Cloud Foundry in a different stream for a while. The goal was to get not only Kubernetes-native, but a Kubernetes-idiomatic place for Cloud Foundry, so that it would become an integral part of the cluster.
“The components teams have to make Kubernetes-native components from the start. We’ve started calling them Kubernetes-idiomatic. Using the parts of Kubernetes that are really good at delivering cloud-native applications.” —Troy Topnik, SUSE
In parallel to this, especially for SUSE, which has its own Kubernetes distribution based on BOSH releases, there was a need for continuity with the extensive BOSH community. So, the KubeCF team was pursuing the way of consuming BOSH releases and combining them into a Foundation-certifiable release that can be run in production.
“The plan with KubeCF is to replace BOSH releases with Kubernetes-native artifacts from the upstream component teams, and gradually make it more like what you’re seeing with CF4K8. On the other side, you are going to see CF4K8 complete more of the functionality that you would see out-of-the-box right now in KubeCF. So, we are going to the same place, which is a distribution of Cloud Foundry on Kubernetes, or may be two distributions.” —Troy Topnik, SUSE
Troy noted that there might be slight differences in both projects, for instance, in the way they are deployed, but the components would be the same. At the moment, there are major architectural and workflow differences between KubeCF and CF4K8. Generally, Saikiran agreed to the idea promoted by Troy, though, saying that the time will show.
Eric Malm of Pivotal reported on the following developments:
- KubeCF was incubated with v1.0.1 released.
- Rel Int is planning for cf-deployment v13, refining the contribution process for CF4K8s.
- The CAPI team is working with Rel Int to integrate kpack into CF4K8s.
- The UAA team is refining secret management for a Kubernetes-deployable artifact.
- The Networking team is recommending the component teams, working on CF4K8s, to rely on Istio sidecars for transparent mTLS.
- The Loggregator team has app logs in CF4K8s, working to integrate container metrics.
- The Diego team is evaluating an interesting pull request for the first-bin container placement.
CF Foundation updates
Swarna Podila reassured that the upcoming summit in Austin, Texas, is still scheduled for for June 25, 2020, as planned. In the view of COVID-19 spreading worldwide, many local and international events were already postponed for better times. The state of Texas is not an exception with a lot of limitations on mass events in force at the moment. However, the Cloud Foundry Foundation hopes for the best, and will keep the community updated about the summit. Swarna also noted that call for proposals was extended until April 3.
This year, the Cloud Foundry Summit will be collocated with the Open Source Summit. To dispel obvious concerns, Chip Childers also noted that the Linux Foundation consults with an epidemiologist to ensure safety at both events. Chip inspired to continue submissions for the summit as it will surely take place in any format, either in-person or virtually.
“We are absolutely going to, if necessary, to pivot to some type of a virtual format, and there’s a ton of amazing technical content. It won’t be like, you know, staring at a video feed all day. We’re going to find ways to break it up and spread it out over a course of days. So, your talk submission ideas are just as valuable irregardless of the format we end up getting the community together again.” —Chip Childers, the CF Foundation
The next CAB call is preliminary scheduled for April 15, 2020, at 8 a.m. PDT. Anyone interested can join Cloud Foundry’s CAB Slack channel.