Remaining Dependencies

Fuzzball requires a few more components to be present and operational before using the operator for installation.

Note

In a 3-node HA setup, the only additional requirement on the second and third node are NFS packages. See below.

metallb

A bare-metal deployment RKE2 requires the metallb load-balancer for the assignment of external IP addresses.


# kubectl apply -f \
    https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml

Once metallb is deployed, add a pool to tell K8s what addresses it is allowed to use for external services. Adjust the address list for the local environment. Fuzzball will require an address in addition to the address used for the prerequisite OCI registry.


# IP1="" # set this according to your environment and preference (for example 10.0.0.99)

# IP2="" # set this according to your environment and preference (for example 10.0.0.100)


# cat >metallb-pool.yaml<<EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
  - ${IP1}/32
  - ${IP2}/32
EOF

# kubectl apply -f metallb-pool.yaml

After applying the pool to the cluster, create an advertisement to make the pool available on a local L2 network.


# INTERNAL_INTERFACE="" # populate this with the value of your internal interface (e.g. enp8s0)


# cat >metallb-advertisement.yaml<<EOF
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default-advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - default-pool
  interfaces:
  - ${INTERNAL_INTERFACE}
EOF

# kubectl apply -f metallb-advertisement.yaml

Helm

Many Kubernetes applications (including the Fuzzball Operator) use the Helm “package manager” to manage deployments. The official Helm installation instructions recommend a curl | sh approach.

Warning

It is usually considered a bad practice to perform a curl | sh since you never can be completely sure of the code you are running. A bad actor could compromise the server hosting the URL and change the script. You may want to download and inspect the script before running it.


# curl -sfL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash -

StorageClass

The Fuzzball Operator expects a StorageClass to be deployed as a prerequisite. If you are installing Fuzzball on a single server node, we recommend you use Local Path Provisioner. If you are installing Fuzzball in a 3-node HA setup, we suggest you use the Longhorn distributed block storage system.

Tip

You will need to set the $STORAGE_CLASS environment variable to either local-path or longhorn later in the guide to complete the Fuzzball configuration. Remember the type of StorageClass that you install.

Please select the tab with instructions appropriate for your environment.

select

singe node (Local Path Provisioner)

HA (Longhorn)

Please select either the single node (Local Path Provisioner) or HA (Longhorn) tab for instructions appropriate to your environment.

Install Local Path Provisioner with the following command (or similar).


# kubectl apply -f \
    https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.28/deploy/local-path-storage.yaml

RKE2 ships with a policy that permits access to /opt/local-path-provisioner via a container_file_t. To ensure that the path is created and properly labeled, we can perform the following.


# mkdir -p /opt/local-path-provisioner

# restorecon -vr /opt/local-path-provisioner

Install the Longhorn distributed block storage system with the following commands.


# systemctl enable --now iscsid

# kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.10.1/deploy/longhorn.yaml

NFS

Fuzzball Orchestrate uses NFS to deliver configuration to the compute nodes and share containers. This shared filesystem can easily be provided by NFS from the Server node, particularly in single-node deployments. If you want to server NFS from the Server node, you can follow these steps:


# PRIVATE_SUBNET="" # populate this with the proper value for your environment (e.g. 10.0.0.0/20)


# dnf install -y nfs-utils

# systemctl enable --now nfs-server

# mkdir -p /srv/fuzzball/shared

# echo "/srv/fuzzball/shared ${PRIVATE_SUBNET}(rw,sync,no_subtree_check,no_root_squash)" >>/etc/exports

# exportfs -a

CLICK TO EXPAND: Special Instructions for a 3 node HA setup

In a 3-node HA setup, it is necessary to install the NFS packages on the second and third node. It is not required to mount /srv/fuzzball/shared from the first node, or carry out any of the other steps detailed above on nodes 2 and 3.

Run the following command on your remaining server nodes.


# dnf install -y nfs-utils

Congratulations! At this point you should have a working K8s (RKE2) deployment suitable for a Fuzzball installation. If you decide that you want to remove the deployment, you can do so by using the rke2-uninstall.sh script from the same URL as above.

Now head over to the Fuzzball Installation Guide to complete your setup.

Installing RKE2 on the Server Node Setting up a hosted zone with Route53