docs: fix links and getting started overview

Fixes #825 Signed-off-by: Andrey Smirnov <[email protected]>
siderolabs · Apr 18, 2022 · 835d5cf · 835d5cf
1 parent 7c7a377
commit 835d5cf
Show file tree

Hide file tree

Showing 53 changed files with 346 additions and 371 deletions.
diff --git a/website/content/v0.1/Guides/bootstrapping.md b/website/content/v0.1/Guides/bootstrapping.md
@@ -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.
 

diff --git a/website/content/v0.1/Guides/patching.md b/website/content/v0.1/Guides/patching.md
@@ -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.
 

diff --git a/website/content/v0.1/Resource Configuration/environments.md b/website/content/v0.1/Resource Configuration/environments.md
@@ -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:

diff --git a/website/content/v0.1/Resource Configuration/metadata.md b/website/content/v0.1/Resource Configuration/metadata.md
@@ -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

diff --git a/website/content/v0.2/Getting Started/_index.md b/website/content/v0.2/Getting Started/_index.md
@@ -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.
diff --git a/website/content/v0.2/Getting Started/index.md b/website/content/v0.2/Getting Started/index.md
diff --git a/website/content/v0.2/Guides/bootstrapping.md b/website/content/v0.2/Guides/bootstrapping.md
@@ -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.
 

diff --git a/website/content/v0.2/Guides/iso.md b/website/content/v0.2/Guides/iso.md
@@ -12,12 +12,12 @@ 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).
   Keep in mind, however, that you will be unable to do the "pivoting" section of the tutorial, so just skip that step when you reach the end of the tutorial.
 
 > 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.
diff --git a/website/content/v0.2/Guides/patching.md b/website/content/v0.2/Guides/patching.md
@@ -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.
 

diff --git a/website/content/v0.2/Guides/upgrades.md b/website/content/v0.2/Guides/upgrades.md
@@ -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
 

diff --git a/website/content/v0.2/Resource Configuration/environments.md b/website/content/v0.2/Resource Configuration/environments.md
@@ -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:

diff --git a/website/content/v0.2/Resource Configuration/metadata.md b/website/content/v0.2/Resource Configuration/metadata.md
@@ -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

diff --git a/website/content/v0.3/Getting Started/_index.md b/website/content/v0.3/Getting Started/_index.md
@@ -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.
diff --git a/website/content/v0.3/Getting Started/index.md b/website/content/v0.3/Getting Started/index.md
diff --git a/website/content/v0.3/Guides/bootstrapping.md b/website/content/v0.3/Guides/bootstrapping.md
@@ -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.
 

diff --git a/website/content/v0.3/Guides/iso.md b/website/content/v0.3/Guides/iso.md
@@ -12,12 +12,12 @@ 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).
   Keep in mind, however, that you will be unable to do the "pivoting" section of the tutorial, so just skip that step when you reach the end of the tutorial.
 
 > 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.
diff --git a/website/content/v0.3/Guides/patching.md b/website/content/v0.3/Guides/patching.md
@@ -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.
 

diff --git a/website/content/v0.3/Guides/rpi4-as-servers.md b/website/content/v0.3/Guides/rpi4-as-servers.md
@@ -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.