mirrors/sidero
1
0
Fork 0
mirror of https://github.com/siderolabs/sidero.git synced 2026-05-05 12:26:40 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: fix links and getting started overview

Browse Source 
Fixes #825

Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This commit is contained in:
Andrey Smirnov 2022-04-18 16:19:20 +03:00
parent 7c7a377857
commit 835d5cf227
No known key found for this signature in database
GPG Key ID: 7B26396447AB6DFD
53 changed files with 346 additions and 371 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/v0.1/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

2
website/content/v0.1/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: Patching
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.8/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

2
website/content/v0.1/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.8/introduction/getting-started/#kernel-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.1/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Metadata server manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.8/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration

58
website/content/v0.2/Getting Started/_index.md
View File

@ -1,4 +1,60 @@
---
title: "Getting Started"
weight: 20
---
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, but it does need to be x86 for
now, and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastruture.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

61
website/content/v0.2/Getting Started/index.md
View File

@ -1,61 +0,0 @@
---
description: "Overview"
weight: 1
title: "Overview"
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, but it does need to be x86 for
now, and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastruture.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

2
website/content/v0.2/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

4
website/content/v0.2/Guides/iso.md
View File

@ -12,7 +12,7 @@ For folks who are willing to take care of their management plane in other ways,
The rough outline of this process is very short and sweet, as it relies on other documentation:
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/docs/v0.10/introduction/getting-started/) docs.
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/latest/introduction/getting-started/) docs.
These docs go into heavy detail on using the ISO, so they will not be recreated here.
- With a Kubernetes cluster now in hand (and with access to it via `talosctl` and `kubectl`), you can simply pickup the Getting Started tutorial at the "Install Sidero" section [here](../../getting-started/install-clusterapi).
@ -20,4 +20,4 @@ The rough outline of this process is very short and sweet, as it relies on other
> Note: It may also be of interest to view the prereq guides on [CLI](../../getting-started/prereq-cli-tools) and [DHCP](../../getting-started/prereq-dhcp) setup, as they will still apply to this method.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/docs/v0.10/guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/docs/v0.10/guides/upgrading-talos/) itself.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/latest/talos-guides/upgrading-talos/) itself.

2
website/content/v0.2/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: Patching
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.8/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

4
website/content/v0.2/Guides/upgrades.md
View File

@ -6,9 +6,9 @@ title: Upgrading
Upgrading a running workload cluster or management plane is the same process as describe in the Talos documentation.
To upgrade the Talos OS, see [here](https://www.talos.dev/docs/v0.9/guides/upgrading-talos).
To upgrade the Talos OS, see [here](https://www.talos.dev/latest/talos-guides/upgrading-talos/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/docs/v0.9/guides/upgrading-kubernetes/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/).
## Upgrading Talos 0.8 -> 0.9

2
website/content/v0.2/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.8/introduction/getting-started/#kernel-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.2/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Metadata server manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.8/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration

58
website/content/v0.3/Getting Started/_index.md
View File

@ -1,4 +1,60 @@
---
title: "Getting Started"
weight: 20
---
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastruture.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

61
website/content/v0.3/Getting Started/index.md
View File

@ -1,61 +0,0 @@
---
description: "Overview"
weight: 1
title: "Overview"
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastruture.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

2
website/content/v0.3/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

4
website/content/v0.3/Guides/iso.md
View File

@ -12,7 +12,7 @@ For folks who are willing to take care of their management plane in other ways,
The rough outline of this process is very short and sweet, as it relies on other documentation:
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/docs/v0.11/introduction/getting-started/) docs.
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/latest/introduction/getting-started/) docs.
These docs go into heavy detail on using the ISO, so they will not be recreated here.
- With a Kubernetes cluster now in hand (and with access to it via `talosctl` and `kubectl`), you can simply pickup the Getting Started tutorial at the "Install Sidero" section [here](../../getting-started/install-clusterapi).
@ -20,4 +20,4 @@ The rough outline of this process is very short and sweet, as it relies on other
> Note: It may also be of interest to view the prereq guides on [CLI](../../getting-started/prereq-cli-tools) and [DHCP](../../getting-started/prereq-dhcp) setup, as they will still apply to this method.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/docs/v0.11/guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/docs/v0.11/guides/upgrading-talos/) itself.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/latest/talos-guides/upgrading-talos/) itself.

2
website/content/v0.3/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: "Patching"
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.11/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

2
website/content/v0.3/Guides/rpi4-as-servers.md
View File

@ -30,7 +30,7 @@ We will use the EEPROM to boot into UEFI, which we will then use to PXE and iPXE
### Update EEPROM
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/docs/v0.11/single-board-computers/rpi_4/#updating-the-eeprom),
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/#updating-the-eeprom),
you can either flash it with the one mentioned below, or visit [the EEPROM config docs](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md)
and change the boot order of EEPROM to `0xf21`.
Which means try booting from SD first, then try network.

6
website/content/v0.3/Guides/sidero-on-rpi4.md
View File

@ -10,7 +10,7 @@ In this guide, we are going to install Talos on Raspberry Pi4, deploy Sidero and
## Prerequisites
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/docs/v0.11/single-board-computers/rpi_4/).
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/).
Download the `clusterctl` CLI from [CAPI releases](https://github.com/kubernetes-sigs/cluster-api/releases).
The minimum required version is 0.3.17.
@ -154,5 +154,5 @@ Configure your DHCP server to PXE boot your bare metal servers from `$SIDERO_END
## Backup and Recovery
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/docs/v0.11/guides/disaster-recovery/),
so that you can [recover](https://www.talos.dev/docs/v0.11/guides/disaster-recovery/) your Sidero installation in case of data loss.
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/latest/advanced/disaster-recovery/),
so that you can [recover](https://www.talos.dev/latest/advanced/disaster-recovery/) your Sidero installation in case of data loss.

4
website/content/v0.3/Guides/upgrades.md
View File

@ -6,9 +6,9 @@ weight: 5
Upgrading a running workload cluster or management plane is the same process as describe in the Talos documentation.
To upgrade the Talos OS, see [here](https://www.talos.dev/docs/v0.11/guides/upgrading-talos).
To upgrade the Talos OS, see [here](https://www.talos.dev/latest/talos-guides/upgrading-talos/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/docs/v0.11/guides/upgrading-kubernetes/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/).
## Upgrading Talos 0.8 -> 0.9

2
website/content/v0.3/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.11/reference/kernel/#commandline-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.3/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Metadata server manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.11/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration

58
website/content/v0.4/Getting Started/_index.md
View File

@ -1,4 +1,60 @@
---
title: "Getting Started"
weight: 20
---
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

61
website/content/v0.4/Getting Started/index.md
View File

@ -1,61 +0,0 @@
---
description: "Overview"
weight: 1
title: "Overview"
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

2
website/content/v0.4/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

4
website/content/v0.4/Guides/iso.md
View File

@ -12,7 +12,7 @@ For folks who are willing to take care of their management plane in other ways,
The rough outline of this process is very short and sweet, as it relies on other documentation:
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/docs/v0.13/introduction/getting-started/) docs.
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/latest/introduction/getting-started/) docs.
These docs go into heavy detail on using the ISO, so they will not be recreated here.
- With a Kubernetes cluster now in hand (and with access to it via `talosctl` and `kubectl`), you can simply pickup the Getting Started tutorial at the "Install Sidero" section [here](../../getting-started/install-clusterapi).
@ -20,4 +20,4 @@ The rough outline of this process is very short and sweet, as it relies on other
> Note: It may also be of interest to view the prerequisite guides on [CLI](../../getting-started/prereq-cli-tools) and [DHCP](../../getting-started/prereq-dhcp) setup, as they will still apply to this method.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/docs/v0.13/guides/upgrading-talos/) itself.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/latest/talos-guides/upgrading-talos/) itself.

2
website/content/v0.4/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: "Patching"
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

2
website/content/v0.4/Guides/rpi4-as-servers.md
View File

@ -30,7 +30,7 @@ We will use the EEPROM to boot into UEFI, which we will then use to PXE and iPXE
### Update EEPROM
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/#updating-the-eeprom),
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/#updating-the-eeprom),
you can either flash it with the one mentioned below, or visit [the EEPROM config docs](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md)
and change the boot order of EEPROM to `0xf21`.
Which means try booting from SD first, then try network.

6
website/content/v0.4/Guides/sidero-on-rpi4.md
View File

@ -10,7 +10,7 @@ In this guide, we are going to install Talos on Raspberry Pi4, deploy Sidero and
## Prerequisites
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/).
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/).
Download the `clusterctl` CLI from [CAPI releases](https://github.com/kubernetes-sigs/cluster-api/releases).
The minimum required version is 0.4.3.
@ -154,5 +154,5 @@ Configure your DHCP server to PXE boot your bare metal servers from `$SIDERO_END
## Backup and Recovery
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#recovery) your Sidero installation in case of data loss.
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/latest/advanced/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/latest/advanced/disaster-recovery/#recovery) your Sidero installation in case of data loss.

4
website/content/v0.4/Guides/upgrades.md
View File

@ -6,9 +6,9 @@ weight: 5
Upgrading a running workload cluster or management plane is the same process as describe in the Talos documentation.
To upgrade the Talos OS, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-talos).
To upgrade the Talos OS, see [here](https://www.talos.dev/latest/talos-guides/upgrading-talos/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/).
## Upgrading Talos 0.8 -> 0.9

2
website/content/v0.4/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.13/reference/kernel/#commandline-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.4/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Sidero controller manager manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration

58
website/content/v0.5/Getting Started/_index.md
View File

@ -1,4 +1,60 @@
---
title: "Getting Started"
weight: 20
---
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

61
website/content/v0.5/Getting Started/index.md
View File

@ -1,61 +0,0 @@
---
description: "Overview"
weight: 1
title: "Overview"
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

2
website/content/v0.5/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

4
website/content/v0.5/Guides/iso.md
View File

@ -12,7 +12,7 @@ For folks who are willing to take care of their management plane in other ways,
The rough outline of this process is very short and sweet, as it relies on other documentation:
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/docs/v0.13/introduction/getting-started/) docs.
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/latest/introduction/getting-started/) docs.
These docs go into heavy detail on using the ISO, so they will not be recreated here.
- With a Kubernetes cluster now in hand (and with access to it via `talosctl` and `kubectl`), you can simply pickup the Getting Started tutorial at the "Install Sidero" section [here](../../getting-started/install-clusterapi).
@ -20,4 +20,4 @@ The rough outline of this process is very short and sweet, as it relies on other
> Note: It may also be of interest to view the prerequisite guides on [CLI](../../getting-started/prereq-cli-tools) and [DHCP](../../getting-started/prereq-dhcp) setup, as they will still apply to this method.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/docs/v0.13/guides/upgrading-talos/) itself.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/latest/talos-guides/upgrading-talos/) itself.

2
website/content/v0.5/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: "Patching"
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

2
website/content/v0.5/Guides/rpi4-as-servers.md
View File

@ -30,7 +30,7 @@ We will use the EEPROM to boot into UEFI, which we will then use to PXE and iPXE
### Update EEPROM
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/#updating-the-eeprom),
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/#updating-the-eeprom),
you can either flash it with the one mentioned below, or visit [the EEPROM config docs](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md)
and change the boot order of EEPROM to `0xf21`.
Which means try booting from SD first, then try network.

6
website/content/v0.5/Guides/sidero-on-rpi4.md
View File

@ -10,7 +10,7 @@ In this guide, we are going to install Talos on Raspberry Pi4, deploy Sidero and
## Prerequisites
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/).
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/).
Download the `clusterctl` CLI from [CAPI releases](https://github.com/kubernetes-sigs/cluster-api/releases).
The minimum required version is 0.4.3.
@ -154,5 +154,5 @@ Configure your DHCP server to PXE boot your bare metal servers from `$SIDERO_END
## Backup and Recovery
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#recovery) your Sidero installation in case of data loss.
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/latest/advanced/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/latest/advanced/disaster-recovery/#recovery) your Sidero installation in case of data loss.

4
website/content/v0.5/Guides/upgrades.md
View File

@ -6,9 +6,9 @@ weight: 5
Upgrading a running workload cluster or management plane is the same process as describe in the Talos documentation.
To upgrade the Talos OS, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-talos).
To upgrade the Talos OS, see [here](https://www.talos.dev/latest/talos-guides/upgrading-talos/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/).
## Upgrading Talos 0.8 -> 0.9

1
website/content/v0.5/Overview/installation.md
View File

@ -14,7 +14,6 @@ Sidero supports several variables to configure the installation, these variables
variables or as variables in the `clusterctl` configuration:
- `SIDERO_CONTROLLER_MANAGER_HOST_NETWORK` (`false`): run `sidero-controller-manager` on host network
`SIDERO_CONTROLLER_MANAGER_HOST_NETWORK` is `true`
- `SIDERO_CONTROLLER_MANAGER_API_ENDPOINT` (empty): specifies the IP address controller manager API service can be reached on, defaults to the node IP (TCP)
- `SIDERO_CONTROLLER_MANAGER_API_PORT` (8081): specifies the port controller manager can be reached on
- `SIDERO_CONTROLLER_MANAGER_CONTAINER_API_PORT` (8081): specifies the controller manager internal container port

2
website/content/v0.5/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.13/reference/kernel/#commandline-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.5/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Sidero controller manager manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration

59
website/content/v0.6/Getting Started/_index.md
View File

@ -1,4 +1,61 @@
---
title: "Getting Started"
weight: 20
---
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

61
website/content/v0.6/Getting Started/index.md
View File

@ -1,61 +0,0 @@
---
description: "Overview"
weight: 1
title: "Overview"
---
This tutorial will walk you through a complete Sidero setup and the formation,
scaling, and destruction of a workload cluster.
To complete this tutorial, you will need a few things:
- ISC DHCP server.
While any DHCP server will do, we will be presenting the
configuration syntax for ISC DHCP.
This is the standard DHCP server available on most Linux distributions (NOT
dnsmasq) as well as on the Ubiquiti EdgeRouter line of products.
- Machine or Virtual Machine on which to run Sidero itself.
The requirements for this machine are very low, it can be x86 or arm64
and it should have at least 4GB of RAM.
- Machines on which to run Kubernetes clusters.
These have the same minimum specifications as the Sidero machine.
- Workstation on which `talosctl`, `kubectl`, and `clusterctl` can be run.
## Steps
1. Prerequisite: CLI tools
1. Prerequisite: DHCP server
1. Prerequisite: Kubernetes
1. Install Sidero
1. Expose services
1. Import workload machines
1. Create a workload cluster
1. Scale the workload cluster
1. Destroy the workload cluster
1. Optional: Pivot management cluster
## Useful Terms
**ClusterAPI** or **CAPI** is the common system for managing Kubernetes clusters
in a declarative fashion.
**Management Cluster** is the cluster on which Sidero itself runs.
It is generally a special-purpose Kubernetes cluster whose sole responsibility
is maintaining the CRD database of Sidero and providing the services necessary
to manage your workload Kubernetes clusters.
**Sidero** is the ClusterAPI-powered system which manages baremetal
infrastructure for Kubernetes.
**Talos** is the Kubernetes-focused Linux operating system built by the same
people who bring to you Sidero.
It is a very small, entirely API-driven OS which is meant to provide a reliable
and self-maintaining base on which Kubernetes clusters may run.
More information about Talos can be found at
[https://talos.dev](https://talos.dev).
**Workload Cluster** is a cluster, managed by Sidero, on which your Kubernetes
workloads may be run.
The workload clusters are where you run your own applications and infrastructure.
Sidero creates them from your available resources, maintains them over time as
your needs and resources change, and removes them whenever it is told to do so.

2
website/content/v0.6/Guides/bootstrapping.md
View File

@ -22,7 +22,7 @@ curl -Lo /usr/local/bin/talosctl https://github.com/talos-systems/talos/releases
chmod +x /usr/local/bin/talosctl
```
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/docs/latest).
You can read more about Talos and `talosctl` at [talos.dev](https://www.talos.dev/latest).
Next, there are two big prerequisites involved with bootstrapping Sidero: routing and DHCP setup.

4
website/content/v0.6/Guides/iso.md
View File

@ -12,7 +12,7 @@ For folks who are willing to take care of their management plane in other ways,
The rough outline of this process is very short and sweet, as it relies on other documentation:
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/docs/v0.13/introduction/getting-started/) docs.
- For each management plane node, boot the ISO and install Talos using the "apply-config" process mentioned in our Talos [Getting Started](https://www.talos.dev/latest/introduction/getting-started/) docs.
These docs go into heavy detail on using the ISO, so they will not be recreated here.
- With a Kubernetes cluster now in hand (and with access to it via `talosctl` and `kubectl`), you can simply pickup the Getting Started tutorial at the "Install Sidero" section [here](../../getting-started/install-clusterapi).
@ -20,4 +20,4 @@ The rough outline of this process is very short and sweet, as it relies on other
> Note: It may also be of interest to view the prerequisite guides on [CLI](../../getting-started/prereq-cli-tools) and [DHCP](../../getting-started/prereq-dhcp) setup, as they will still apply to this method.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/docs/v0.13/guides/upgrading-talos/) itself.
- For long-term maintenance of a management plane created in this way, refer to the Talos documentation for upgrading [Kubernetes](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/) and [Talos](https://www.talos.dev/latest/talos-guides/upgrading-talos/) itself.

2
website/content/v0.6/Guides/patching.md
View File

@ -5,7 +5,7 @@ title: "Patching"
---
Server resources can be updated by using the `configPatches` section of the custom resource.
Any field of the [Talos machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)
Any field of the [Talos machine config](https://www.talos.dev/latest/reference/configuration/)
can be overridden on a per-machine basis using this method.
The format of these patches is based on [JSON 6902](http://jsonpatch.com/) that you may be used to in tools like kustomize.

2
website/content/v0.6/Guides/rpi4-as-servers.md
View File

@ -30,7 +30,7 @@ We will use the EEPROM to boot into UEFI, which we will then use to PXE and iPXE
### Update EEPROM
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/#updating-the-eeprom),
_NOTE:_ If you've updated the EEPROM with the image that was referenced on [the talos docs](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/#updating-the-eeprom),
you can either flash it with the one mentioned below, or visit [the EEPROM config docs](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md)
and change the boot order of EEPROM to `0xf21`.
Which means try booting from SD first, then try network.

6
website/content/v0.6/Guides/sidero-on-rpi4.md
View File

@ -10,7 +10,7 @@ In this guide, we are going to install Talos on Raspberry Pi4, deploy Sidero and
## Prerequisites
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/docs/v0.13/single-board-computers/rpi_4/).
Please see Talos documentation for additional information on [installing Talos on Raspberry Pi4](https://www.talos.dev/latest/talos-guides/install/single-board-computers/rpi_4/).
Download the `clusterctl` CLI from [CAPI releases](https://github.com/kubernetes-sigs/cluster-api/releases).
The minimum required version is 0.4.3.
@ -154,5 +154,5 @@ Configure your DHCP server to PXE boot your bare metal servers from `$SIDERO_END
## Backup and Recovery
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/docs/v0.13/guides/disaster-recovery/#recovery) your Sidero installation in case of data loss.
SD cards are not very reliable, so make sure you are taking regular [etcd backups](https://www.talos.dev/latest/advanced/disaster-recovery/#backup),
so that you can [recover](https://www.talos.dev/latest/advanced/disaster-recovery/#recovery) your Sidero installation in case of data loss.

4
website/content/v0.6/Guides/upgrades.md
View File

@ -6,9 +6,9 @@ weight: 5
Upgrading a running workload cluster or management plane is the same process as describe in the Talos documentation.
To upgrade the Talos OS, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-talos).
To upgrade the Talos OS, see [here](https://www.talos.dev/latest/talos-guides/upgrading-talos/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/docs/v0.13/guides/upgrading-kubernetes/).
In order to upgrade Kubernetes itself, see [here](https://www.talos.dev/latest/kubernetes-guides/upgrading-kubernetes/).
## Upgrading Talos 0.8 -> 0.9

2
website/content/v0.6/Resource Configuration/environments.md
View File

@ -8,7 +8,7 @@ Environments are a custom resource provided by the Metal Controller Manager.
An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](https://www.talos.dev/docs/v0.13/reference/kernel/#commandline-parameters) and/or the Linux kernel supports.
From here, one can tweak the IP to the metadata server as well as various other kernel options that [Talos](hhttps://www.talos.dev/latest/reference/kernel/) and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level.
The hierarchy from most to least respected is:

2
website/content/v0.6/Resource Configuration/metadata.md
View File

@ -6,7 +6,7 @@ title: Metadata
The Sidero controller manager manages the Machine metadata.
In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the
"[machine config](https://www.talos.dev/docs/v0.13/reference/configuration/)",
"[machine config](https://www.talos.dev/latest/reference/configuration/)",
which is used during the automated installation.
## Talos Machine Configuration