Cloud Foundry Enterprise Environment sizing

To install Cloud Foundry Enterprise Environment, your instance must meet the following size requirements.

Cell instance worker nodes

Each worker node that is used as a Cloud Foundry Enterprise Environment cell is tainted to reserve the maximum amount of resources strictly for Cloud Foundry cell use. However, there are IBM® Cloud Private essential infrastructure pods that must run on every worker node as part of the management services for Kubernetes.

To view the nodes that are labeled for use by Cloud Foundry Enterprise Environment, run the following command:

kubectl get nodes -L bcf.type

To view the pods that are running on a node and see which ones are required by the IBM Cloud Private infrastructure, run the following command:

kubectl describe node <node name>

Each pod in the kube-system namespace is part of the infrastructure. Each pod in the UAA and Cloud Foundry namespace is part of the Cloud Foundry Enterprise Environment infrastructure.

Typically, the IBM Cloud Private infrastructure pods consume approximately 256 MB - 1 GB on each worker node, depending on the number of IBM Cloud Private management services that are enabled. When you size the worker nodes, use the following guidelines for a minimal configuration:

When you size the worker nodes, use the following guidelines for a standard production configuration:

Ratio of control plane instances to cell instances

Diego cell pods are responsible for scheduling Cloud Foundry application containers in the Cloud Foundry Enterprise Environment environment. Cloud Foundry Diego runtime assumes that it has exclusive control over the worker node's CPU, memory, and disk resources. Additional configuration steps are needed to ensure that the worker nodes are dedicated for exclusive use by the Diego cell pods that are deployed. For more information, see Installing Cloud Foundry Enterprise Environment. The deployer must identify, label, and taint worker nodes that run Diego cell pods in the Cloud Foundry Enterprise Environment environment. The number of worker nodes that run Diego cell pods must be equal to the number of Diego cells in Cloud Foundry Enterprise Environment that you are configuring.

As the number of cell instances scales up, you also need to scale up the number of control plane instances. The following table provides the recommended ratio:

Note: Scale down is not supported.

Persistent volumes

The administrator must create a persistent volume. The storage class of the persistent volume is used for the persistent volume claim of the Cloud Foundry Enterprise Environment chart and the Cloud Foundry deployment. GlusterFS storage is recommended, but other shared persistent storage is supported, such as NFS. The persistent storage class must allow dynamic creation of persistent volumes by the storage class. The use of hostPath/local storage can be used only in demonstration.

The persistent volume must be set with "Retain" for the persistent volume claim policy to keep the deployment data in case the application is removed temporarily.

Persistent volume for the Helm release

The persistent volume must have at least 10 GB available for the deployment tool and 1 GB available for the management console.

Persistent volume for Cloud Foundry Enterprise Environment

Separate persistent storage is needed for the Cloud Foundry Enterprise Environment. The storage class name is needed when you use the Cloud Foundry deployment tool in the Kubernetes storage class name field.

The persistent volume for the cf and uaa namespaces must have at least 120 GB available for the various databases plus an extra 10 GB for each cell instance.

Limitations

1. Cloud Foundry Enterprise Environment currently supports only IBM Cloud Private that is installed on Ubuntu.
2. The IBM Cloud Private config.yaml cluster_domain must use the default cluster.local
3. Only one Cloud Foundry Enterprise Environment can be deployed per IBM Cloud Private instance.