The Dojo team is here again. Recently, we worked on a project called Cloud Foundry (CF) on Kubernetes (K8S) and we are thrilled to share with you how we did it.
Table of contents:
1. Why CF on K8S?
3. Demo Video
1.Why CF on K8S?
Putting CF on K8S is a good idea because of its ease of deployment, resource utilization, and flexibility.
- The overall deployment of CF on K8S is simpler than other IaaS because creating and destroying containers is quicker than that of VMs. Therefore, we are saving a significant amount of time and resources when we deploy CF components, which involves more than ten VMs. Woah! 😮
- Having CF on K8S helps utilize resources better. A traditional Diego Cell VM consumes more resources when NATS or Consul VMs are deployed as separate VMs because resources are assigned to each VM. For example, the NATS and Consul VMs each need 2GB of RAM on top of the Diego Cell using 5GB of RAM, but this not an efficient way of using resources as this is not scalable. Instead of deploying two VMs for NATS and Consul, we can deploy these as jobs using two containers sitting inside a node (or VM) that the Diego Cell has access to. Inside these nodes, the containers share the same resources that are allocated for the VMs.
- We can pretend K8S is acting as an IaaS to put CF on top of. Knowing this, CF can be in any environment K8S is on because K8S can be deployed on top of any IaaS (including bare metal).
Figure 1: CF on K8S on GCP architecture
There is a Kubernetes cluster of nodes (or VMS) that reside in GCP. Inside of the Kubernetes cluster, there are CF components that are utilizing K8S nodes. The Diego Cells nodes are separate from the main CF components because it is difficult to run containers within a container (as Diego is also a container orchestrator).
Special thanks to the kubernetes bosh cpi team from SAP for helping us. Please check out their repo at kubernetes_cpi.