Configuration file structure

furyctl uses a configuration file (named furyctl.yaml by default) to define the complete configuration of a Kubernetes Fury Cluster.

The configuration file structure depends on the kind (alias for the Provider) of the cluster being created.

All configuration files share a common base structure though:

apiVersion: <version>
kind: <kind>
metadata:
  name: <name>
spec:
  infrastructure:
  kubernetes:
  distribution:
  plugins:

You can find the reference schemas for each Provider here

Spec

The .spec portion contains the phases that are exeucted by furyctl to provision a KFD cluster.

.spec.infrastructure

The .spec.infrastructure portion will contain all the parameters needed to create the infrastructure that will host a Kubernetes cluster. For example, on AWS this will configure the VPC and VPN. Not all providers have this phase, see the Providers documentation for more details.

.spec.kubernetes

The .spec.kubernetes portion will contain the actual configuration for the Kubernetes cluster, options and nodepools. It is used to drive the creation of a Kubernetes cluster with a provider of your choice. Not all providers have this phase, see the Providers documentation for more details.

.spec.distribution

The .spec.distribution portion will contain all the configurations on the Kubernetes Fury Distribution core modules that will be installed inside the Kubernetes cluster.

note

N.B.: in the furyctl.yaml config file, the default configuration will install all modules with some default values. This also means that if you don't specify a module it will be installed anyway. If you want to not install a module, you must set the following parameter in its configuration:

spec:
  distribution:
    networking: # or any other module
      type: "none"

.spec.plugins

The .spec.plugins portion will contain all the additional Helm Charts/Kustomize projects that we want to install inside the Kubernetes cluster. This is intended to be the place where you add things that you consider to be part of the cluster's core components, which will be managed by furyctl and not by other means. It's not intended as a mean to place actual workload inside the cluster.

As an example, you could install as a plugin the resources needed to use a CSI of your choice.

Phases

Each one of the aforementioned portions defines also a phase of furyctl's execution.

During creation, the phases will be executed in the following order: infrastructure -> kubernetes -> distribution -> plugins.

The phases can also be executed in standalone mode if necessary, using the flag --phase with furyctl.