fix(docs): update clustertool section (#32469)

**Description**
<!--
Please include a summary of the change and which issue is fixed. Please
also include relevant motivation and context. List any dependencies that
are required for this change.
-->
⚒️ Fixes  https://github.com/truecharts/public/issues/32176

**⚙️ Type of change**

- [ ] ⚙️ Feature/App addition
- [ ] 🪛 Bugfix
- [ ] ⚠️ Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] 🔃 Refactor of current code
- [x] 📜 Documentation Changes

**🧪 How Has This Been Tested?**
<!--
Please describe the tests that you ran to verify your changes. Provide
instructions so we can reproduce. Please also list any relevant details
for your test configuration
-->

**📃 Notes:**
<!-- Please enter any other relevant information here -->

**✔️ Checklist:**

- [ ] ⚖️ My code follows the style guidelines of this project
- [ ] 👀 I have performed a self-review of my own code
- [ ] #️⃣ I have commented my code, particularly in hard-to-understand
areas
- [ ] 📄 I have made changes to the documentation
- [ ] 🧪 I have added tests to this description that prove my fix is
effective or that my feature works
- [ ] ⬆️ I increased versions for any altered app according to semantic
versioning
- [ ] I made sure the title starts with `feat(chart-name):`,
`fix(chart-name):`, `chore(chart-name):`, `docs(chart-name):` or
`fix(docs):`

** App addition**

If this PR is an app addition please make sure you have done the
following.

- [ ] 🖼️ I have added an icon in the Chart's root directory called
`icon.png`

---

_Please don't blindly check all the boxes. Read them and only check
those that apply.
Those checkboxes are there for the reviewer to see what is this all
about and
the status of this PR with a quick glance._
This commit is contained in:
Alfred Göppel
2025-02-23 23:47:52 +01:00
committed by GitHub
parent 5226f19529
commit 126d6cdc48
15 changed files with 159 additions and 177 deletions
@@ -1,6 +1,14 @@
---
title: adv
---
:::caution[Advanced Commands]
Commands in this section are advanced and aren't covered by support.
Proceed at your own risk!
:::
## clustertool adv
Advanced cluster maintanence commands
@@ -1,6 +1,14 @@
---
title: adv precommit
---
:::caution[Advanced Commands]
Commands in this section are advanced and aren't covered by support.
Proceed at your own risk!
:::
## clustertool adv precommit
Runs the PreCommit encryption check
@@ -1,6 +1,14 @@
---
title: adv test
---
:::caution[Advanced Commands]
Commands in this section are advanced and aren't covered by support.
Proceed at your own risk!
:::
## clustertool adv test
tests specific code for developer usages
@@ -1,31 +0,0 @@
---
title: Rook-Ceph
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
Rook-CEPH is a kubernetes operator to deploy a ceph cluster from within kubernetes.
Its a lot more complex and offers a LOT more features compared to most other CSIs and any issues would likely require significant time investment, for it being a actual enterprise-grade storage solution.
## Ceph-Cluster
TODO: Add description of what a CEPH cluster is and a basic overview on how to set it up
## Ceph-Block
TODO: Add description of what a CEPH Block-Storage is and a basic overview on how to set it up
## Ceph-FS
TODO: Add description of what a CEPH-FS is and a basic overview on how to set it up, including performance issues when using volsync and its general performance negatives.
## Ceph-ObjectStorage
TODO: Add description of what a CEPH S3 ObjectStorage is and a basic overview on how to set it up
@@ -2,18 +2,8 @@
title: Democratic-CSI
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
Democratic CSI is a multi-platform CSI, mostly using either local or network (NFS/iSCSI) based storage.
## Values
Their Helm-Chart is available at: https://democratic-csi.github.io/charts/
@@ -21,7 +11,6 @@ All below examples, are based on their Helm-Chart
### NFS
```yaml
csiDriver:
name: "nfs"
@@ -40,6 +29,7 @@ storageClasses:
node-stage-secret:
node-publish-secret:
controller-expand-secret:
# if you want to use snapshots
volumeSnapshotClasses:
- name: nfs-snapshot
@@ -138,7 +128,6 @@ driver:
Due to flaws in TrueNAS SCALE, this script needs to run each day est. 20min after volsync cycle to clear stuck jobs. (Truenas Cronjob)
```python
from datetime import datetime, timedelta, timezone
from truenas_api_client import Client
@@ -207,7 +196,6 @@ if __name__ == "__main__":
main()
```
## Other references
Other resource for guidance: https://github.com/fenio/k8s-truenas
@@ -2,18 +2,9 @@
title: Container Storage Interfaces
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
Container Storage Interfaces, better known as "CSI", are used to connect storage to kubernetes PVCs.
The base ClusterTool setup, includes a single-node setup of Longhorn, which can be easily tweaked from single-node to multi-node setup.
However there are much better CSIs out there, if you date!
Guides under this section give some user-made examples of CSI storage options available.
However, as those are user-made, they are not covered by TrueCharts Discord Support.
@@ -23,8 +14,7 @@ For users that want to keep things simple, with data on the OS disk and decent s
This would not require extra drives and can easily be configured for single-node (1 replica, the default) as wel as clustered storage (3 replicas).
In addition longhorn would, by default, not conflict with any of the other CSIs listed above, meaning users can easily start experimenting with other CSIs as well, while still relying on Longhorn.
Hence for most users starting-out we would advice starting-out using Longhorn and have included it as the default storage backend (CSI) when deploying clustertool
Hence for most users starting-out we would advice starting-out using Longhorn and have included it as the default storage backend (CSI) when deploying clustertool.
## Overview
@@ -40,12 +30,10 @@ Hence for most users starting-out we would advice starting-out using Longhorn an
| Democratic NFS | Networked | Partial | Yes | RWX | Requires TrueNAS Cron script due to instability |
| Democratic iSCSI | Networked | Partial | Yes | RWO | Requires TrueNAS Cron script due to instability |
## General notes
Some general notes might be cool as well, wirthen out a little longer obviously:
- ClusterTool already includes snapshot controller by default
- Some CSIs try to claim unused disks or even wipe used disks. Be carefull when mixing multiple "full disk" CSIs!
- For multi-pod charts sharing storage, a RWX CSI is required!
@@ -54,7 +42,7 @@ Some general notes might be cool as well, wirthen out a little longer obviously:
## Our Top Picks
- Local non-volsync storage: OpenEBS hostPath
- Local general storage: TopoLVM
- Local general storage: Longhorn
- Clustered RWO storage: CEPH-Block
- Clustered RWX storage: CEPH-FS
- Networked Storage: Democratic NFS
@@ -2,15 +2,6 @@
title: Longhorn
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
Longhorn is a distributed block storage system for Kubernetes. Longhorn is cloud-native storage built using Kubernetes and container primitives.
Their Helm-Chart is available at: <https://github.com/longhorn/charts>
@@ -41,6 +32,7 @@ spec:
retain: 0
task: filesystem-trim
```
This runs a filesystem trim at midnight UTC. To free the "used" space.
In addition to trim, it is possible to delete and cleanup all snapshots by adding tasks for snapshot-delete and snapshot-cleanup.
@@ -51,7 +43,6 @@ This tasks should only be used with caution, as they will delete manually create
:::
```yaml
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
@@ -67,6 +58,7 @@ spec:
retain: 0
task: snapshot-delete
```
This runs a snapshot delete task at 22:00 UTC.
```yaml
@@ -84,6 +76,7 @@ spec:
retain: 0
task: snapshot-cleanup
```
This runs a snapshot cleanup task at 22:30 UTC.
## Other references
@@ -2,13 +2,5 @@
title: csi-driver-nfs
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
csi-driver-nfs is used to provision static and dynamic storage.
It can be used as an alternative to democratic CSI and is compatible with TrueCharts integrated NFS/SMB csi options for easily adding and storing credentials
@@ -2,15 +2,6 @@
title: OpenEBS
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
OpenEBS is a multi-storage CSI solution.
However, its important to note that its snapshot capabilities either are relatively unstable or non-existent.
@@ -2,13 +2,5 @@
title: csi-driver-smb
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
csi-driver-smb is used to provision static and dynamic storage.
It can be used as an alternative to democratic CSI and is compatible with TrueCharts integrated NFS/SMB csi options for easily adding and storing credentials
@@ -2,15 +2,6 @@
title: TopoLVM
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
TopoLVM is a CSI plugin using LVM for Kubernetes. It can be considered as a specific implementation of local persistent volumes using CSI and LVM.
Their repo and helm chart are available at: https://github.com/topolvm/topolvm
@@ -21,14 +12,15 @@ Nothing in this guide is specific to TrueCharts. There are some Talos-specific s
TopoLVM requires it's own LVM Volume Group to provision storage from. In this guide we'll assume you're accomplishing this by providing a separate drive (or virtual disk) specifically for TopoLVM to keep it more simple.
### LVM Prep
In this guide we are preparing LVM to use in a clustertool environment. Also the configuration is done in a way it can be used by e.g. volsync for backup/restore functionalities.
Complete preparation is based upon:
- https://github.com/topolvm/topolvm/blob/main/docs/getting-started.md
- https://github.com/topolvm/topolvm/blob/main/docs/snapshot-and-restore.md
Most important highlights of above are the:
- Use of cert-manager
- Correctly labeled namespaces
- Installation of CRDs and the controller for volume snapshots
@@ -41,7 +33,9 @@ Chart information at: https://truecharts.org/charts/system/lvm-disk-watcher/
Find the name of the disk you want to use for TopoLVM. With Talos OS, use `talosctl disks` to list the names of the available disks. You may need to install another disk to your VM or your bare-metal server.
## Install Lvm_Disk
Create the namespace with these labels:
```yaml
apiVersion: v1
kind: Namespace
@@ -53,6 +47,7 @@ metadata:
```
Example of deployment:
```yaml
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
@@ -83,6 +78,7 @@ spec:
```
## Install TopoLVM
Now that you've completed your prep on the node to create volumes for TopoLVM to use, we can install TopoLVM.
The reference Values and their explanations could be find here:
https://github.com/topolvm/topolvm/blob/main/charts/topolvm/values.yaml
@@ -125,14 +121,10 @@ The following example can be used and adjust where necesarry.
# replicaCount: 1
```
## Snapshots
TBD
## Kernel Modules
Add these two kernel modules. Use modprobe for typical linux installs or add them to your talconfig.yaml if using TalHelper or ClusterTool as shown below:
```yaml
#talconfig.yaml
nodes:
@@ -153,14 +145,19 @@ These steps could lead to data loss if done on the wrong disks.
These commands set up a Volume Group and Thin Pool for TopoLVM to use. The names of these will need to be put into your TopoLVM Helm Values. The name of the disk may vary depending on your setup.
Create a Physical Volume
```bash
pvcreate /dev/vdb
```
Create a Volume Group
```bash
vgcreate topolvm_vg /dev/vdb
```
Create a Thin Pool
```bash
lvcreate -l 100%FREE --chunksize 256 -T -A n -n topolvm_thin topolvm_vg
```
@@ -168,6 +165,7 @@ lvcreate -l 100%FREE --chunksize 256 -T -A n -n topolvm_thin topolvm_vg
## Create Privilaged Namespace
Create the namespace with these labels:
```yaml
apiVersion: v1
kind: Namespace
@@ -178,7 +176,6 @@ metadata:
topolvm.io/webhook: ignore
```
## Other references
Other resource for guidance: https://github.com/topolvm/topolvm/blob/main/docs/proposals/thin-volumes.md
@@ -2,25 +2,24 @@
title: Files and Folders
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
File and Folder structure on init, is as follows
## Created Files and Folders
- talconfig.yaml -> Contains your Talos Cluster layout
- clusterenv.yaml -> Contains configuration options for both your Charts and Talos Cluster
- talsecret.yaml -> Contains Talos Cluster encryption keys
- age.agekey -> Contains SOPS encryption keys which can be used to encrypt data. It's **IMPERATIVE** you save this specific file elsewhere as a backup, not doing so *will* result in future data loss
- age.agekey -> Contains SOPS encryption keys which can be used to encrypt data. It's **IMPERATIVE** you save this specific file elsewhere as a backup,
not doing so *will* result in future data loss
- .sops.yaml -> Contains specifications on how to decrypt any encrypted files found
- .pre-commit-config.yaml -> Contains configurations for users of "pre-commit"
- talconfig.json -> Contains the validations "schema" for talconfig.yaml
- /patches/ -> This folder contains our custom Talos Machine Configuration patches, these should not be altered by any end-user. however, you can add your own here
- /manifests/ -> This folder will contain some pre-generated files that will be used to bootstrap the cluster and, if configured, can be consumed by fluxcd for automatic updates and manual configuration
- /patches/ -> This folder contains our custom Talos Machine Configuration patches, these should not be altered by any end-user. however,
you can add your own here
- /generated/ -> This folder will contain some pre-generated files that will be used to bootstrap the cluster and,
if configured, can be consumed by fluxcd for automatic updates and manual configuration
- .devcontainer -> Contains a preconfigured dev-container for vscode usage of clustertool
- .vscode -> Contains recommended extensions for your talos cluster in vscode
- /repositories/ -> Contains all repositories used within fluxcd helm-releases
- /clusters/ -> Contains all kubernetes clusters you run within the same clustertool github repo
- /kubernetes/ -> Contains all the files of your kubernetes cluster
@@ -4,11 +4,9 @@ sidebar:
title: Getting Started
---
:::caution[Work In Progress]
:::caution[Guide]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
Please follow this guide step by step and only skip (Optional) sections.
:::
@@ -25,26 +23,27 @@ All things considered, we would advise users to prepare their repository beforeh
- [Setup GIT](https://docs.github.com/en/get-started/getting-started-with-git/set-up-git)
- [Cloning a Repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)
Besides these basic getting-started steps, we would also advise users to have already followed [this](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic). We also would advise users to save this token somewhere secure until needed.
## Prepare your Config
## 1. Prepare your Files
Let's get started!
Make sure you either have a new empty folder open that is going to contain all your cluster configuration *or* the previously made, and cloned, github repo.
From this step forward, we're going to assume a github repo. If you're starting with a local folder, that's perfectly fine, however some steps need to be skipped.
Make sure you either have a new empty folder open that is going to contain all your cluster configuration *or* the previously made,
and cloned, github repo.
From this step forward, we're going to assume a github repo. If you're starting with a local folder,
that's perfectly fine, however some steps need to be skipped.
### Downloading ClusterTool
## 2. Downloading ClusterTool
ClusterTool is available on [GitHub](https://github.com/truecharts/public/releases). Please extract the archive and copy the executable into your `configuration folder`.
ClusterTool is available on [GitHub](https://github.com/truecharts/public/releases).
Please extract the archive and copy the executable into your `configuration folder`.
### Initialisation
## 3. Initialisation
First off we need to generate all file and folder structure for us to store any configuration.
For this, in a terminal, run:
`ClusterTool init`
`clustertool init`
or, on Windows:
@@ -52,31 +51,36 @@ or, on Windows:
This builds all config files and folders.
### Save your encryption key
## 4. Save your encryption key
This step also will have generated a file called `age.agekey`. This file contains your encryption key and will, as such, **not** be saved to your github repository.
This step also will have generated a file called `age.agekey`.
This file contains your encryption key and will, as such, **not** be saved to your github repository.
It's **absolutely crucial** you save this file somewhere safe and preferably have multiple copies in safe places. Not saving this file can and **will** lead to loss of your config.
It's **absolutely crucial** you save this file somewhere safe and preferably have multiple copies in safe places.
Not saving this file can and **will** lead to loss of your config.
## Configuration
## 5. Configuration
Thanks to our use of TalHelper, a streamlined Talos configuration tool, there are only two files that contain all our configuration for Talos:
- `clusters/main/clusterenv.yaml`
- `clusters/main/talos/talconfig.yaml`
### ClusterEnv
This file that contains the most important settings, its content also gets saved on the cluster for use with FluxCD and its settings get referenced in multiple places.
This file that contains the most important settings,
its content also gets saved on the cluster for use with FluxCD and its settings get referenced in multiple places.
You're free to add settings as you please, or as you need them. Feel free to adapt them if needed!
Primary settings that **need** to be adapted:
- `MASTER1IP`: The static-DHCP IP that was set during the TalosOS network configuration
- `VIP`: Contains the shared IP for all master-nodes
- `METALLB_RANGE`: Contains the range MetalLB will allow IPs to be distributed in *(cannot overlap with any nodeIP or VIP, nor should it overlap with local dhcp range)*
- `DASHBOARD_IP`: The IP, within the MetalLB range, that the kubernetes monitoring/management dashboard will be made available on *(should be a free ip adres on your network, not overlapping with dhcp adresses)*
- `MASTER1IP`: The static-DHCP IP that was set during the TalosOS network configuration
- `GATEWAY`: Your local network gateway
- `METALLB_RANGE`: Contains the range MetalLB will allow IPs to be distributed in *(cannot overlap with any nodeIP or VIP,
nor should it overlap with local dhcp range)*
- `DASHBOARD_IP`: The IP, within the MetalLB range, that the kubernetes monitoring/management dashboard will be made available on
*(should be a free ip adres on your network, not overlapping with dhcp adresses)*
#### (optional) Enabling FluxCD Bootstrapping
@@ -85,11 +89,15 @@ It should start with `ssh://`, so be sure to pick the SSH repository url option
### TalConfig
This file contains purely the structure of the Talos Cluster and its nodes themselves. As such, it also contains a number of `${VARIABLE}` references to `clusterenv.yaml`. These should **not** be removed.
This file contains purely the structure of the Talos Cluster and its nodes themselves.
As such, it also contains a number of `${VARIABLE}` references to `clusterenv.yaml`. These should **not** be removed.
We generate an opinionated variant of this file, that is optimised to run with our default setup. *Making any changes outside of the nodes section, might completely break ClusterTool*
We generate an opinionated variant of this file, that is optimised to run with our default setup.
*Making any changes outside of the nodes section, might completely break ClusterTool*
We would advise to adapt the nodes so they fit your cluster design. By default we've a single node, with a single disk and a single network interface added. This is sufficient for all our VM guides and will be enabled for both 'controlplane', controlling the cluster itself, as well as 'worker' workloads.
We would advise to adapt the nodes so they fit your cluster design. By default we've a single node,
with a single disk and a single network interface added.
This is sufficient for all our VM guides and will be enabled for both 'controlplane', controlling the cluster itself, as well as 'worker' workloads.
For more information on talconfig.yaml and talhelper, please see [here](https://budimanjojo.github.io/talhelper/latest/)
@@ -97,48 +105,63 @@ For more information on talconfig.yaml and talhelper, please see [here](https://
If you want to use FluxCD, you need to add the SSH public key defined in `./ssh-public-key.txt`, to your Github Account.
For More info, see:
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account
For More info, see: [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
## Generating ClusterConfig and updating files from Config
## 6. Run init again
To finalize all the configuration changes please run:Ö
`clustertool init`
or, on Windows:
`ClusterTool.exe init`
again. This will generate all remaining necessary files
## 7. Generating ClusterConfig and updating files from Config
:::caution[Compatibility]
While our genconfig *can* generate a clusterconfig, that can get applied 'out of the box' through TalosCTL. By default, our `talconfig.yaml` is completely designed around our ClusterTool expected defaults.
While our genconfig *can* generate a clusterconfig, that can get applied 'out of the box' through TalosCTL.
By default, our `talconfig.yaml` is completely designed around our ClusterTool expected defaults.
Hence these cannot be expected to work directly through TalosCTL.
:::
Clusterconfig are the files Talos itself sends to the nodes and uses to connect to the nodes. To create these files, which are not saved to git by default, from the config you created earlier, please run:
Clusterconfig are the files Talos itself sends to the nodes and uses to connect to the nodes.
To create these files, which are not saved to git by default, from the config you created earlier, please run:
In a terminal, run:
`ClusterTool genconfig`
`clustertool genconfig`
or, on Windows:
`ClusterTool.exe genconfig`
This also will update a number of files we (pre)generate for FluxCD and/or prepare to be uploaded to the cluster. This includes things like the CNI (Cilium and MetalLB).
This also will update a number of files we (pre)generate for FluxCD and/or prepare to be uploaded to the cluster.
This includes things like the CNI (Cilium and MetalLB).
### Saving your config
## 8. Saving your config
To save your config, it's important to first ensure none of your secrets leak out, by encrypting all confidential settings.
For this, in a terminal, run:
`ClusterTool encrypt`
`clustertool encrypt`
or, on Windows:
`ClusterTool.exe encrypt`
It's important to note that from this point onwards, some settings might be hidden behind encryption text. You can still safely alter anything else, but to access these settings again, please follow the below:
It's important to note that from this point onwards, some settings might be hidden behind encryption text.
You can still safely alter anything else, but to access these settings again, please follow the below:
In a terminal, run:
`ClusterTool decrypt`
`clustertool decrypt`
or, on Windows:
@@ -148,7 +171,7 @@ To be 100% sure encryption worked out correctly, you can always check for the en
In a terminal, run:
`ClusterTool checkcrypt`
`clustertool checkcrypt`
or, on Windows:
@@ -162,7 +185,7 @@ To send the data to git run:
- `git commit -a -m "some description"`
- `git push`
## Bootstrapping your first node
## 9. Bootstrapping your first node
To ensure stability, we will first apply the configuration to the first ControlPlane node in the list and bootstrap this node.
@@ -177,9 +200,39 @@ or, on Windows:
You will be asked if you want to bootstrap the cluster, to do this enter `y` or `yes`
After this is finished successfully, make sure the node is running correctly. It should have everything loaded already.
## Applying config to the rest of your cluster
:::note[Warnings/Errors]
Now we can continue to add more nodes to the cluster. This is completely automated, we can apply the configuration to every node in the cluster, new or existing, by simply running:
It is completly normal that the bootstrap takes some time and reboots your talos vm.
Additionally clustertool might show multiple warnings/errors during the bootstrap while the vm is unreachable.
Example Warnigs/Errors:
```bash
WRN Not all required pods are running, waiting before checking again
```
or
```bash
ERR status: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp 192.168.0.224:50000
```
THis can be safely ignored if the bootstrap finishes successfully with:
```bash
INF checking if node is back online: 192.168.0.224
INF Checking node status node=192.168.0.224
INF Node status retrieved successfully status="running\n"
INF Healthcheck: node currently reporting status: 192.168.0.224 running
INF Checking node readiness status node=192.168.0.224
INF Node is ready
```
:::
## 10. Applying config to the rest of your cluster
Now we can continue to add more nodes to the cluster.
This is completely automated, we can apply the configuration to every node in the cluster, new or existing, by simply running:
In a terminal, run:
@@ -188,3 +241,15 @@ In a terminal, run:
or, on Windows:
`ClusterTool.exe talos apply`
## 11. Final
:::caution[ISO]
Don't forget to remove the ISO from your VM at this point.
Otherwise it will reset your talos-vm during next restart.
:::
Your talos-cluster should now be bootstrapped and you should be able to add your first charts.
Have fun!
@@ -4,14 +4,6 @@ sidebar:
title: Introduction to ClusterTool
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
ClusterTool is TrueCharts' own easy deployment and maintenance tool for TalosOS clusters.
It has support for both single-node and multi-node clusters, both as Virtual Machines and on Bare-Metal.
@@ -4,14 +4,6 @@ sidebar:
title: 'TrueNAS SCALE -> ClusterTool'
---
:::caution[Work In Progress]
This program, all its features and its general design, are all a Work-In-Progress. It is not done and not widely available.
All code and docs are considered Pre-Beta drafts
:::
With the upcoming 24.10 "Electric Eel" version of TrueNAS SCALE, iX-Systems has decided to completely gut the Kubernetes backend of SCALE. However, we've got you covered so you can safely keep running your TrueCharts Charts.
Our new ClusterTool can, among other things, be used to craft yourself a new kubernetes backend to continue self-hosting using TrueCharts. For this guide we'll be using a TalosOS VM on TrueNAS SCALE, but any solid hypervisor would suffice.