Talos Bootstrap is an automated bootstrapping and configuration tool for deploying Talos Linux clusters once they have been provisioned. The repository is structured as follows:
clusterscontains the bootstrap configuration for various clusters, each in their own file. Create a new file here to configure a new cluster. Take a look atclusters/example.yamlfor the configuration schema.patchcontains the various strategic merge patches that are applied to the machine configurations of nodes as instrumented by the configurations inclusters. Take a look atexample.yamlfor detailed information about the patch format.
Important
The bootstrap configuration file schema is intentionally unstable. Upon updating talos-bootstrap, one might need to update existing cluster configuration files to match the new schema. However, the strict validation logic should help with pointing out issues, such as changed fields. When updating cluster configuration, please refer to clusters/example.yaml, which will always comply with the current schema and describe the fields.
Install pipx from your distribution's repositories, then simply run
pipx install ./bootstrap # or with -e to install in editable modeThis will register the tool as the command bootstrap (assuming the pipx installation directory is in your PATH).
Check the available command line options with
bootstrap --help.
The bootstrap automates the end-to-end setup of a Talos Linux cluster. It only requires a set of un-configured Talos Linux nodes in a network with the proper DNS configuration. After choosing a cluster configuration from one of the available configurations in clusters and ensuring that the secrets are present, bootstrapping the cluster is as easy as running
bootstrap clusters/<cluster>.yamland monitoring the progress. The bootstrap tool requires the talosctl, helm,flux, and kubectl binaries to be present in $PATH. First, it will use talosctl to generate a configuration for the cluster and to patch the nodes, then it will apply the Cilium CNI networking layer using helm, after that it will use flux to install Flux and (optionally) point it to the upstream defined in the cluster configuration, and finally it will apply any static manifests in the form of a Kustomization using kubectl. If a SOPS GPG key is supplied in the cluster configuration, kubectl is also used to create the SOPS secret in the flux-system namespace before installing Flux.
The bootstrapping process requires one or two files with secrets: a secrets.yaml which contains the secrets for talosctl and the cluster and, if configured, a flux.key which contains an SSH private key that Flux will use to access the configuration repository. The expected location of these files (in the secrets directory) is defined by the cluster configuration in clusters. Additionally, for SOPS, one can (optionally) provide a GPG ID/fingerprint of a key that can be imported into the cluster.
If you want to create new secrets for a cluster, do the following:
- Create a new directory under
secretsnamed after your cluster. - Enter that directory and run
talosctl gen secretsto get a newsecrets.yaml. - Run
ssh-keygen -t ed25519 -N "" -f flux.keyto create a new private and public key for Flux. - Ensure that your cluster configuration under
clustersuses the newly generatedsecrets.yamlandflux.key. - Create a new repository to host your service layer deployments.
- Add the public key in
flux.key.pubto theRepository settings > Access keys(or similar) of that repository. - Create a SOPS GPG key:
gpg --batch --full-gen-key << EOF %no-protection Key-Type: EdDSA Key-Curve: Ed25519 Key-Usage: sign Subkey-Type: ECC Subkey-Curve: Curve25519 Subkey-Usage: encrypt Expire-Date: 0 Name-Comment: Flux SOPS Key Name-Real: my-cluster.example.com EOF - Proceed with the bootstrapping process.
- Dennis Marttinen (@twelho)
- Veeti Poutsalo (@Polychoronix)