The next generation of
furyctl
, called "furyctl next", has been officially released. It is now in a stable state and available starting from version v0.25.0. The previous version, furyctl 0.11, is considered legacy and will only receive bug fixes. It will be maintained under the v0.11 branch.
furyctl
is the command line companion for the Kubernetes Fury Distribution to manage the full lifecycle of your Kubernetes Fury clusters.
π‘ Learn more about the Kubernetes Fury Distribution in the official site.
If you're looking for the old documentation for furyctl legacy, you can find it here.
EKSCluster
: Provides comprehensive lifecycle management for an EKS cluster on AWS. It handles the installation of the VPC, VPN, EKS using the installers, and deploys the Distribution onto the EKS cluster.KFDDistribution
: Dedicated provider for the distribution, which installs the Distribution (modules only) on an existing Kubernetes cluster.OnPremises
: Provider to install a KFD Cluster on VMs.
Check the compatibility matrix for additional information about furyctl
and KFD
compatibility.
You can find furyctl
binaries on the Releases page.
To download the latest release, run:
curl -L "https://github.com/sighupio/furyctl/releases/latest/download/furyctl-$(uname -s)-amd64.tar.gz" -o /tmp/furyctl.tar.gz && tar xfz /tmp/furyctl.tar.gz -C /tmp
chmod +x /tmp/furyctl
sudo mv /tmp/furyctl /usr/local/bin/furyctl
Alternatively, you can install furyctl
using the asdf plugin.
Installing with asdf
Add furyctl asdf plugin:
asdf plugin add furyctl
Check that everything is working correctly with furyctl version
:
$ furyctl version
...
goVersion: go1.23
osArch: amd64
version: 0.29.10
Prerequisites:
make >= 4.1
go >= 1.23
goreleaser >= 2.3
You can install
goreleaser
with the following command once you have Go in your system:go install github.com/goreleaser/goreleaser/v2@v2.3.2
Once you've ensured the above dependencies are installed, you can proceed with the installation.
-
Clone the repository:
git clone git@github.com:sighupio/furyctl.git # cd into the cloned repository cd furyctl
-
Build the binaries by running the following command:
go build .
-
You will find the binaries for your current architecture inside the current folder:
$ ls furyctl furyctl
-
Check that the binary is working as expected:
$ ./furyctl version buildTime: 2024-10-08T07:46:28Z gitCommit: 217cdcc8bf075fccfdb11c41ccc6bb317ec704bc goVersion: go1.23.2 osArch: arm64 version: 0.29.10
-
(optional) move the binary to your
bin
folder, in macOS:sudo mv ./furyctl /usr/local/bin/furyctl
See all the available commands and their usage by running furyctl help
.
π‘ TIP
Enable command tab autocompletion for
furyctl
on your shell (bash
,zsh
,fish
are supported). See the instruction on how to enable it withfuryctl completion --help
π‘ TIP
You can follow the Kubernetes Fury Distribution quick start guides for cloud and on-premises installations in KFD's official documentation site: https://docs.kubernetesfury.com/docs/quickstart/quickstart
Check KFD Compatibility matrix for the furyctl / KFD versions to use.
Basic usage of furyctl
for a new project consists on the following steps:
- Creating a configuration file defining the required infrastructure, Kubernetes cluster details, and KFD modules configuration.
- Creating a cluster as defined in the configuration file.
- Destroying the cluster and its related resources.
furyctl
provides a command that outputs a sample configuration file (by default called furyctl.yaml
) with all the possible fields explained in comments.
furyctl configuration files have a kind that specifies what type of cluster will be created, for example the EKSCluster
kind has all the parameters needed to create a KFD cluster using the EKS managed clusters from AWS.
You can also use the KFDDistribution
kind to install the KFD distribution on top of an existing Kubernetes cluster or OnPremises
kind to install a KFD cluster on VMs.
Additionally, the schema of the file is versioned with the apiVersion
field, so when new features are introduced you can switch to a newer version of the configuration file structure.
To scaffold a configuration file to use as a starter, you use the following command:
furyctl create config --version v1.29.4 --kind "EKSCluster"
π‘ TIP
You can pass some additional flags, like the schema (API) version of the configuration file or a different configuration file name.
See
furyctl create config --help
for more details.
Open the generated configuration file with your editor of choice and edit it according to your needs. You can follow the instructions included as comments in the file.
Once you have filled your configuration file, you can check that it's content is valid by running the following command:
furyctl validate config --config /path/to/your/furyctl.yaml
π NOTE
The
--config
flag is optional, set it if your configuration file is not namedfuryctl.yaml
Requirements (EKSCluster):
- AWS CLI
- OpenVPN (when filling the
vpn
field in the configuration file)
In the previous step, you have created and validated a configuration file that defines the Kubernetes cluster and its surroundings, you can now proceed to actually creating the resources.
furyctl divides the cluster creation in four phases: infrastructure
, kubernetes
, distribution
and plugins
.
- The first phase,
infrastructure
, creates all the prerequisites needed to be able to create a cluster. For example, the VPC and its networks. - The second phase,
kubernetes
, creates the actual Kubernetes clusters. For example, the EKS cluster and its node pools. - The third phase,
distribution
, deploys KFD modules to the Kubernetes cluster. - The fourth phase,
plugins
, installs Helm and Kustomize plugins into the cluster.
π NOTE
You will find these four phases when editing the furyctl.yaml file.
Just like you can validate that your configuration file is well-formed, furyctl
let you check that you have all the needed dependencies (environment variables, binaries, etc.) before starting a cluster creation process.
To validate that your system has all the dependencies needed to create the cluster defined in your configuration file, run the following command:
furyctl validate dependencies
Last but not least, you can launch the creation of the resources defined in the configuration file by running the following command:
βοΈ WARNING
You are about to create cloud resources that could have billing impact.
π NOTE
The cluster creation process, by default, will create a VPN in the
infrastructure
phase and connect your machine to it automatically before proceeding to thekubernetes
phase.
furyctl create cluster --config /path/to/your/furyctl.yaml
π‘ TIP
You can use the alias
furyctl apply
instead offuryctl create cluster
.
π NOTE
The creation process will take a while.
π Congratulations! You have created your production-grade Kubernetes Fury Cluster from scratch and it is now ready to go into battle.
Note
This is a quick overview of the process. For a more complete documentation please see the universal upgrade guide.
Upgrading a cluster is a process that can be divided into two steps: upgrading the fury version and running the migrations (if present).
The first step consists in bringing the cluster up to date with the latest version of the Kubernetes Fury Distribution. This is done by:
-
Identifying the target version to which upgrade to with:
furyctl get upgrade-paths
-
Bumping the version in the configuration file to the desired one.
-
Upgrading the cluster:
furyctl apply --upgrade --config /path/to/your/furyctl.yaml
Once that is done, if you were also planning to move to a different configuration (e.g.: changing from logging type opensearch
to loki
), you can run the following command to run the migrations as usual:
furyctl apply --config /path/to/your/furyctl.yaml
βοΈ WARNING
You must first upgrade the cluster using the old configuration (e.g.: logging type
opensearch
), update the configuration file to use the new type (e.g.:loki
) and then run the command above.
You can also split nodes upgrade process into several steps, for example, you can upgrade the control plane nodes first:
furyctl apply --upgrade --config /path/to/your/furyctl.yaml --skip-nodes-upgrade
And then upgrade the worker nodes, one by one:
furyctl apply --upgrade --config /path/to/your/furyctl.yaml --upgrade-node workerNode1
At the end of the node upgrade process, a check is performed to ensure every pod is either Running
or in a Completed
state. You can specify a timeout for this check with the --pod-running-check-timeout
flag or skip it with the --force pods-running-check
flag.
Destroying a cluster will run through the four phases mentioned above, in reverse order, starting from distribution
.
To destroy a cluster created using furyctl
and all its related resources, run the following command:
βοΈ WARNING
You are about to run a destructive operation.
furyctl delete cluster --dry-run
Check that the dry-run output is what you expect and then run the command again without the --dry-run
flag to actually delete all the resources.
π‘ TIP
Notice the
--dry-run
flag, used to check what the command would do. This flag is available for other commands too.
The following steps will guide you through the process of creating a Kubernetes Fury cluster from zero.
- Follow the previous steps to generate a
furyctl.yaml
and download the modules. - Edit the
furyctl.yaml
to customize the cluster configuration by filling the sectionsinfrastructure
,kubernetes
anddistribution
. - Check that the configuration file is valid by running
furyctl validate config
. - Run
furyctl create cluster
to create the cluster. - (Optional) Watch the logs of the cluster creation process with
tail -f ~/.furyctl/furyctl.<timestamp>-<random>.log
.
On-premises clusters need a set of certificates authorities and certificate files to work as a prerequisite. Both for the Kubernetes control plane and for the etcd database.
furyctl provides a command that allows the creation of this PKI:
furyctl create pki
The command supports some additional options, like --etcd
to create only the PKI for etcd, or creating the files in a different path.
See all the additional options with the --help
flag:
furyctl create pki --help
Same as the previous section, but you can skip the infrastructure creation phase
by not filling the section infrastructure
in the furyctl.yaml
file and
running furyctl create cluster --start-from kubernetes
.
The cluster creation process can be split into three phases:
- Infrastructure
- Kubernetes
- Distribution
The furyctl create cluster
command will execute all the phases by default,
but you can limit the execution to a specific phase by using the --phase
flag.
To create a cluster step by step, you can run the following command:
furyctl create cluster --phase infrastructure
If you choose to create a VPN in the infrastructure phase, you can automatically connect to it by using the flag --vpn-auto-connect
.
furyctl create cluster --phase kubernetes
After running the command, remember to export the KUBECONFIG
environment variable to point to the generated kubeconfig file or
to use the flag --kubeconfig
in the following command.
furyctl create cluster --phase distribution
The new furyctl still embeds some legacy features, for example the command furyctl legacy vendor
to download KFD dependencies from a deprecated Furyfile.yml
.
This can be still used to manually manage all the components of the distribution.
π‘ TIP
you can also use
--furyfile
to point to aFuryfile.yaml
in a different folder
furyctl supports Helm and Kustomize plugins.
To install a Helm plugin (chart), follow these steps:
- Add the repository to the
spec.plugins.helm.repositories
section of yourfuryctl.yaml
file. - Add the release to the
spec.plugins.helm.releases
section, specifying the chart name, the namespace, the chart version and the values to override. To override the values you can use thespec.plugins.helm.releases[].set
or thespec.plugins.helm.releases[].values
section.
For example to install the Prometheus Helm chart you have to add the following to your furyctl.yaml
:
...
spec:
...
plugins:
helm:
repositories:
- name: prometheus-community
url: https://prometheus-community.github.io/helm-charts
releases:
- name: prometheus
namespace: prometheus
chart: prometheus-community/prometheus
version: "24.3.0"
set:
- name: server.replicaCount
value: 3
values:
- path/to/values.yaml
To install a Kustomize plugin (project) you have to configure the spec.plugins.kustomize
section of your furyctl.yaml
file, specifying a name and the path to the folder.
For example:
...
spec:
...
plugins:
kustomize:
- name: kustomize-project
folder: path/to/kustomize/project
furyctl comes with the flag --distro-location
, allowing you to use a local copy of KFD instead of downloading it from the internet. This allows you to test changes to the KFD without having to push them to the repository, and might come in handy when you need to test new features or bug fixes.
On the same note, the tool comes with the --upgrade-path-location
flag, too, allowing you to test changes to the upgrade path without having to push them to the repository, and to support cases that are not covered by the official release, such as upgrading from a beta or release candidate release to a stable one.
If, for any reason, the cluster creation or update process fails, you can restart it from a specific (sub-)phase by using the --start-from
flag. Starting from v0.27.0 we introduced the support for sub-phases, to give the operator more control over the process. The supported options are: pre-infrastructure
, infrastructure
, post-infrastructure
, pre-kubernetes
, kubernetes
, post-kubernetes
, pre-distribution
, distribution
, post-distribution
, plugins
.
There are four kinds of tests: unit, integration, e2e, and expensive.
Each of them covers specific use cases depending on the speed, cost, and dependencies at play in a given scenario. Anything that uses i/o should be marked as integration, with the only expectation of local files and folders: any test that uses the local filesystem and nothing more can be marked as 'unit'. This is made for convenience and it's open to change in the future should we decide to refactor the code to better isolate that kind of i/o from the logic of the tool.
That said, here's a little summary of the used tags:
- unit: tests that exercise a single component or function in isolation. Tests using local files and dirs are permitted here.
- integration: tests that require external services, such as github. Test using only local files and dirs should not be marked as integration.
- e2e: tests that exercise furyctl binary, invoking it as a cli tool and checking its output
- expensive: e2e tests that incur in some monetary cost, like running an EKS instance on AWS
In case you experience any problems with furyctl
, please open a new issue on GitHub.
This software is open-source and it's released under the following LICENSE.