While we’ve covered “What is Cloud Foundry” in another tutorial, and there are plenty of great resources explaining Kubernetes, let’s summarize them in the context of each other. Both are open-source projects.
Cloud Foundry is supplemental to Kubernetes - you can install Cloud Foundry in addition to, or on, Kubernetes to make app developers more productive. Application developers could use Kubernetes without Cloud Foundry.
Not every technology is suitable in every use case. In this section we briefly list some of the ways that you can tell if Cloud Foundry on Kubernetes is right for you.
Workloads can be deployed to the cloud at varying levels of abstraction. Understanding the difference between the levels of abstraction may help you decide which technology is most appropriate for different workloads.
In this section we’ll look at what things need to happen in order to go from some source code (or compiled code in the case of Java applications) to a running application in the cloud.
Having already looked at the abstract steps that are required to get and keep an app running, let’s look in more detail at what that experience looks like when using Cloud Foundry.
In earlier sections we looked at the conceptual steps to get and keep an app running, and also what those look like when using Cloud Foundry. In this section we’ll look at the same steps when using Kubernetes directly, without Cloud Foundry.
Because Kubernetes can run any workload distributed as container images, Kubernetes can run Cloud Foundry itself. When installed on Kubernetes, Cloud Foundry presents a streamlined self-service interface for application developers to deploy apps onto Kubernetes, whilst allowing the Kubernetes operators to maintain more control over what is running on the system.
Unless you’re particularly interested in how Cloud Foundry and Kubernetes create containers, you don’t really need to know what Project Eirini is or how it works. It’s an implementation detail that is only really of concern to people operating Cloud Foundry.