Cloud Foundry Summit North America 2020

Come check out this talk on Cloud Foundry for Kubernetes (cf-for-k8s), a fully native Kubernetes foundation. We will walk through the project, give a glimpse of the community involvement, and explore how you can contribute to cf-for-k8s projects.

Over the past year, there has been major effort invested in re-platforming Cloud Foundry to run on Kubernetes. As part of this re-architecture, the idea of utilizing Custom Resource Definitions (CRDs) has come to the forefront of discussion.

In this session, Angela and Connor will examine why CRDs are so compelling to use as a core component of the future cf-for-k8s. We will highlight the benefits of a CRD-centric approach for users, application developers, and contributors and offer some thoughts on what a CRD-centric cf-for-k8s might look like. Attendees should leave with a strong understanding of why and how they might utilize CRDs.

SUSE has been at the forefront of adopting Kubernetes as a platform for running Cloud Foundry. As part of our mission to help our customers adopt cloud-native technologies, we've learned that the path to successful utilization of Kubernetes can be difficult - for end user software developers, for platform operators, and even for Cloud Foundry itself. This session will summarize how KubeCF, Quarks, and Stratos are building a bridge for platform operators from current BOSH-based releases to the next generation of Cloud Foundry components currently under development.

Kubernetes solves a lot of challenges that come with managing an infrastructure stack. At the same time giving development teams direct access to the Kubernetes API for workload deployment and maintenance isn’t an optimal user experience. In this talk we look at how VMware Tanzu is helping create a infrastructure stack that supports Kubernetes yet gives Development teams the CF experience via Tanzu Application Service Powered by cf-for-k8s.

The Eirini project is bringing Kubernetes as a container scheduler to the Cloud Foundry Application Runtime. In other words: the `cf push` developer experience we all love, with the most popular container orchestrator under the covers.

This session takes you on a whirlwind tour of the why and how of eirini. What is the latest state (v1.0+ released, v3 support, and more), how can you use it, what are we working on next.

And if you want to know how you get the latest and greatest Eirini running on your Kubernetes cluster, come and join the talk. Spoiler alert: The latest Eirini is now avaialbe on KubeCF and CF-for-K8s.

As CF for Kubernetes continues to grow, the process for pushing source code to production will still be as simple as running 'cf push'. But, the build path that your application travels from source to running container has changed. The buildpacks responsible for adding the dependencies an application needs have been completely reimagined.

Building on top of the experience building and maintaining Cloud Foundry Buildpacks comes the
Paketo Project. It aims to resolve the technical and organizational issues that affected the old CloudFoundry Buildpacks.

This talk will address how Paketo Buildpacks reshape the buildpack experience to be modular, extensible and approachable.

Cloud Foundry for Kubernetes seeks to bring the simple, self-service APIs of Cloud Foundry to the powerful, but complicated world of Kubernetes. By bringing the “cf map-route” experience to Kubernetes, developers can focus on core application business logic instead of complex Kubernetes networking configuration.

In this session, Tim and Nitya will cover the design decisions, implementation, and extensibility of the new networking tier in CF for Kubernetes. They will demonstrate how CF for Kubernetes leverages Istio service mesh and Kubernetes networking features to enhance the platform. They will also present a new Kubernetes custom resource and controller: the CF Route CRD and RouteController. The CF Route CRD and RouteController lend future extensibility to the networking tier by opening up potential for additional control planes and pluggable ingress implementations in the future.

The Cloud Foundry Toolsmiths team at VMware deploys up to 7,000 Cloud Foundry foundations a month for internal testing for VMware and open source Cloud Foundry R&D teams. Here's what we've learned about observability, reliability, repeatable deployments, and keeping our Concourse happy.

In this talk, I will review the progress made on the Stratos project since the last summit and demonstrate some of the newer features we've added recently. For those not familiar with Stratos, the demo will also provide an introductory overview of Stratos and its capabilities.

I'll end the session by looking forward, talking about what's next for the project, including adding support for the V3 API and improving the extension mechanism.

If you don't know what Stratos is, want to hear what the team has been up to and where they are going, this is the talk for you.

The services endpoints on the Cloud Controller API have been a general source of pain for consumers. Some of the problems with the V2 implementation include: needing several requests to get basic information about a service or service instance, multiple endpoints to manage the same resource, leaking abstractions between the API and the Service Broker, and lack of features like blocking during service instance creation. This contributes to frustrate not only API consumers but also CLI/GUI users.

The SAPI team is working on improving many aspects of the services API with V3 of the cloud controller API. The new services endpoints provide much more flexibility and control over the workflows available for service offerings and service instance management. Many of these features and improvements are already available as experimental APIs on recent versions of Cloud Foundry.

The CredHub team will be talking briefly about our current explorations in the Kubernetes space,
including service authentication/application bindings, credential generation, and more. We will also provide updates on our future roadmap plans.