In a previous blog post we discovered how to deploy a single KubeCF with a single cf-operator. Exciting stuff! What if you wanted to deploy a second KubeCF? A third?
With a couple minor changes to subsequent installs you can deploy as many instancess of KubeCF as you like, each in their own namespaces.
Creating the first KubeCF is done by Helm installing the cf-operator, configuring a
values.yaml file for KubeCF and finally Helm installing KubeCF. Each of the two operators will exist in their own namespace. With the
feature.eirini.enable: true option set in the
values.yaml of the KubeCF Helm chart a third namespace named
<kubecf-name>-eirini will be created for all the Cloud Foundry apps to live in.
For each additional instance of KubeCF, you’ll need an install of the
cf-operator referencing an install of
kubecf. Each pair of
kubecf will get their own namespaces so if you intend on deploying a great number of KubeCF installs consistent naming will become important.
Deploy the First KubeCF
A quick overview of installing a single instance of KubeCF is below. For complete instruction visit the blog post.
- Helm install the
cf-operatorconfigured to watch a particular namespace
- Configure a
values.yamlfile for KubeCF, leave the default NodePort of 32123 for the Eirini service.
- Helm install KubeCF
For each additional deployment of KubeCF there is a 1:1 install of the cf-operator required as well.
cf-operator configuration needs a few additional pieces:
- A unique namespace
- Name override so the helm chart creates all the cluster roles with unique names
- Disable creating the CRDs again as they aren’t namespaced
In the example below, a second cf-operater is deployed, extra points if you can guess the naming for the third one:
kubectl create namespace cf-operator2helm install cf-operator2 \ --namespace cf-operator2 \ --set "global.operator.watchNamespace=kubecf2" \ --set "fullnameOverride=cf-operator2" \ --set "applyCRD=false" \ https://s3.amazonaws.com/cf-operators/release/helm-charts/cf-operator-v2.0.0-0.g0142d1e9.tgz
values.yaml for KubeCF
There are two important pieces of information which must be unique between each of the installs:
system_domain– Don’t reuse the same system_domain for any existing Cloud Foundry deployment which is visible by your DNS, regardless of whether it is KubeCF, Tanzu Pivotal Platform (PCF), or
cf-deployment-based. Debugging is hard enough without having to figure out which coconut we are talking to.
features.eirini.registry.service.nodePortmust be a unique number across the entire cluster. Verify the port you hard code is not in use before deploying.
system_domain: kubecf18.104.22.168.10.netip.cc # Must be unique ... features: eirini: enabled: true registry: service: nodePort: 32124 # Must be unique cluster-wide
An example of a modified
There are a couple minor changes from the install of the first KubeCF:
- Again make sure you have a unique helm chart name
- The namespace name should match the
global.operator.watchNamespaceof the corresponding
- Reference the
values.yamlfile for this install of KubeCF
helm install kubecf2 \ --namespace kubecf2 \ --values /Users/chris/projects/kubecf/kubecf2/values.yaml \ https://github.com/SUSE/kubecf/releases/download/v0.2.0/kubecf-0.2.0.tgz
At some point you will run yourself out of Kubernetes resources if you keep spinning additional KubeCF installs. Two concurrent installs run happily on 3 worker nodes with 2vCPU and 16GB of memory each.
We’ll have instructions soon for installing KubeCF on Rancher. Are there other infrastructures that you’d like to see KubeCF deployed to? Respond in the comments sections below!