Cloud Foundry is an open source cloud application platform that makes building, testing, deploying, and scaling applications easier and faster. It provides a choice of clouds, developer frameworks, and application services. The open source project is available through a variety of private cloud distributions and public cloud instances, including IBM Cloud.
To deploy Cloud Foundry yourself, you must prepare several virtual machines and use the BOSH tool. Due to the popularity of Kubernetes, most cloud software now runs on it. Therefore, the Cloud Foundry community created a Kubernetes operator pattern, called
cf-operator, which can be used to deploy and manage Cloud Foundry applications natively on a Kubernetes cluster. This article explains what the
cf-operator pattern is and how you can use it.
- Understanding of Kubernetes operators.
- Understanding of BOSH deployment config.
- Understanding of Cloud Foundry concepts.
Allow about 15 minutes to read this article and try out the example.
Overview of the cf-operator pattern
cf-operator is a Kubernetes operator pattern to package, deploy, and manage Kubernetes native applications. These applications are both deployed on Kubernetes and managed by its APIs and the
kubectl command-line tool. The operator automates installation, self-service provisioning, and maintenance of the application.
To install and manage your applications that run on Kubernetes clusters, the operator uses a custom resource definition (CRD) file to extend a set of cohesive APIs and a controller pattern that enables the operator to reconcile the current state of the Kubernetes system to a desired state. The CRD allows you to define the application resources including configurations and orchestration. The controller watches the resource instances and invokes the reconcile loop to arrange your application into a desired state. For example, the deployment controller will create new pods when you scale up deployment.
How cf-operator works
The diagram above shows the two main parts of Cloud Foundry on Kubernetes. To run Cloud Foundry applications on Kubernetes, you must create container images. The Cloud Foundry community currently uses BOSH releases as a means for delivery, so the first step is to translate your Cloud Foundry BOSH releases into container images. To do so, the Cloud Foundry community recommends using a tool named Fissile.
After you create the necessary Cloud Foundry container images, you must tell the
cf-operator pattern how to deploy each container image on the Kubernetes cluster. You can use the
cf-deployment manifest to tell
cf-operator to create Kubernetes Jobs, Pods, and StatefulSets as Cloud Foundry components running on the Kubernetes cluster. After that,
cf-operator will watch all of the Kubernetes resources that belong to Cloud Foundry, compare them with the
cf-deployment manifest, and reconcile to update Kubernetes resources. The watch and reconcile mechanism is very helpful from an operations perspective, such as when to update Cloud Foundry and correct the Kubernetes resources when any Cloud Foundry component fails.
cf-operator implements the following features to help Cloud Foundry jobs run smoothly on Kubernetes:
- Fetch the
cf-deploymentmanifest that contains Cloud Foundry configurations and convert them to CRD files.
- Render BOSH templates in runtime and move rendering jobs from main containers to Init Containers.
- Remove the Cloud Foundry
monittool in the main container and trigger each BOSH job exclusively in a container.
How cf-operator deploys Cloud Foundry on Kubernetes
To deploy Cloud Foundry on Kubernetes,
cf-operator watches and manages four different types of custom resources:
These Kubernetes resources are extended from Kubernetes’ native Job, Secret, and StatefulSet, and add new features, such as a blue/green update strategy for StatefulSet. As a result,
cf-operator creates and manages Kubernetes with the custom resources: ExtendedJob, ExtendedSecret, and ExtendedStatefulSet.
Another important custom resource is BoshDeployment. It defines the desired
cf-operator watches it and performs the following actions:
- Reads the deployment manifest and generates Secrets.
- Converts the BOSH workloads into the Kubernetes resources mentioned above.
- Deploys these Kubernetes resources on a Kubernetes cluster.
This diagram abstracts and highlights how
cf-operator controllers work after BoshDeployment is created. The controllers watch BoshDeployment resources and other configuration resources (Secrets, ConfigMaps). After creating the BoshDeployment resource on Kubernetes,
cf-operator will start reconciliation, which will eventually result in the deployment of Cloud Foundry on Kubernetes as ExtendedJob, ExtendedSecret, and ExtendedStatefulSet to make all of Cloud Foundry run correctly on the Kubernetes cluster.
This section shows an example of how to install
cf-operator and use it to deploy Cloud Foundry.
cf-operatoron Kubernetes by following the README instructions within the
Run the following command to install
helm install --name cf-operator --namespace cfo --set "global.operator.watchNamespace=kubecf" https://s3.amazonaws.com/cf-operators/helm-charts/cf-operator-v0.4.2%2B121.g0be7cf70.tgz
Monitor and make sure the
cf-operatorpod is running in
kubectl get pod -n cfo
Install Cloud Foundry using
cf-operatorby first downloading the latest Helm release for Cloud Foundry on Kubernetes.
Run the following command to install Cloud Foundry in the
helm install --name kubecf --namespace kubecf https://scf-v3.s3.amazonaws.com/kubecf-3.0.0-04bca19.tgz
Monitor and make sure the Cloud Foundry pod is running in
kubectl get pod -n kubecf
Deploy an app using a command such as
cf push app1
Verify the app is running.
As a result, you now have the Cloud Foundry experience on top of Kubernetes. You can easily manage your Cloud Foundry deployment because it is fully compatible with the applications and lifecycle.
By using the
cf-operator pattern, you can easily deploy Cloud Foundry on Kubernetes. Note that the community is actively enhancing
- Introducing BOSH tooling, such as manual repair with CloudCheck.
- Integrating cloud native components, such as Istio, to manage components.
- Enhancing operation efforts about self-healing and rollback.