mirror of
https://github.com/siderolabs/sidero.git
synced 2026-05-06 04:46:29 +02:00
docs: metadata server -> sidero
- Updates metadata server to reflect Sidero Controller Manager - Few typos and broken links Signed-off-by: Noel Georgi <git@frezbo.dev>
This commit is contained in:
Noel Georgi
parent
a82628186d
commit
0e7f8a6820
@ -139,4 +139,4 @@ We are working toward integrating as much as possible into Sidero, to provide as
|
||||
much intelligence and automation as can be had, but until then, you will likely
|
||||
need to figure out how to begin hunting down problems.
|
||||
|
||||
See the Sidero [Troubleshooting](troubleshooting) guide for more assistance.
|
||||
See the Sidero [Troubleshooting](../troubleshooting) guide for more assistance.
|
||||
|
||||
@ -11,7 +11,7 @@ reachable by the servers which it will be driving.
|
||||
|
||||
For most servers, TFTP (port 69/udp) will be needed.
|
||||
This is used for PXE booting, both BIOS and UEFI.
|
||||
Being a primitive UDP protocl, many load balancers do not support TFTP.
|
||||
Being a primitive UDP protocol, many load balancers do not support TFTP.
|
||||
Instead, solutions such as [MetalLB](https://metallb.universe.tf) may be used to expose TFTP over a known IP address.
|
||||
For servers which support UEFI HTTP Network Boot, TFTP need not be used.
|
||||
|
||||
|
||||
@ -56,6 +56,6 @@ More information about Talos can be found at
|
||||
|
||||
**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.
|
||||
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.
|
||||
|
||||
@ -16,7 +16,7 @@ The process is fairly simple with a few pieces of information.
|
||||
|
||||
- If the server is already part of a cluster (`kubectl get serverbindings` should provide this info), you can now delete the machine that corresponds with this server via `kubectl delete machine <machine_name>`.
|
||||
|
||||
- With the machine deleted, Sideo will reboot the machine and wipe its disks.
|
||||
- With the machine deleted, Sidero will reboot the machine and wipe its disks.
|
||||
|
||||
- Once the disk wiping is complete and the server is turned off, you can finally delete the server from Sidero with `kubectl delete server <server_name>` and repurpose the server for something else.
|
||||
|
||||
|
||||
@ -18,6 +18,6 @@ The rough outline of this process is very short and sweet, as it relies on other
|
||||
- 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.
|
||||
> 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.
|
||||
|
||||
@ -106,13 +106,13 @@ These can be used to compose a bank of `Servers` that are eligible for provision
|
||||
|
||||
See the [ServerClasses](../../resource-configuration/serverclasses/) section of our Configuration docs for examples and more detail.
|
||||
|
||||
### Metal Metadata Server
|
||||
### Sidero Controller Manager
|
||||
|
||||
While the metadata server does not present unique CRDs within Kubernetes, it's important to understand the metadata resources that are returned to physical servers during the boot process.
|
||||
While the controller does not present unique CRDs within Kubernetes, it's important to understand the metadata resources that are returned to physical servers during the boot process.
|
||||
|
||||
#### Metadata
|
||||
|
||||
The metadata server may be familiar to you if you have used cloud environments previously.
|
||||
Using Talos machine configurations created by the Talos Cluster API bootstrap provider, along with patches specified by editing `Server`/`ServerClass` resources or `TalosConfig`/`TalosControlPlane` resources, metadata is returned to servers who query the metadata server at boot time.
|
||||
The Sidero controller manager server may be familiar to you if you have used cloud environments previously.
|
||||
Using Talos machine configurations created by the Talos Cluster API bootstrap provider, along with patches specified by editing `Server`/`ServerClass` resources or `TalosConfig`/`TalosControlPlane` resources, metadata is returned to servers who query the controller manager at boot time.
|
||||
|
||||
See the [Metadata](../../resource-configuration/metadata/) section of our Configuration docs for examples and more detail.
|
||||
|
||||
@ -4,7 +4,7 @@ weight: 4
|
||||
title: Metadata
|
||||
---
|
||||
|
||||
The Metadata server manages the Machine 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/)",
|
||||
which is used during the automated installation.
|
||||
|
||||
@ -11,7 +11,7 @@ reachable by the servers which it will be driving.
|
||||
|
||||
For most servers, TFTP (port 69/udp) will be needed.
|
||||
This is used for PXE booting, both BIOS and UEFI.
|
||||
Being a primitive UDP protocl, many load balancers do not support TFTP.
|
||||
Being a primitive UDP protocol, many load balancers do not support TFTP.
|
||||
Instead, solutions such as [MetalLB](https://metallb.universe.tf) may be used to expose TFTP over a known IP address.
|
||||
For servers which support UEFI HTTP Network Boot, TFTP need not be used.
|
||||
|
||||
|
||||
@ -56,6 +56,6 @@ More information about Talos can be found at
|
||||
|
||||
**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.
|
||||
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.
|
||||
|
||||
@ -16,7 +16,7 @@ The process is fairly simple with a few pieces of information.
|
||||
|
||||
- If the server is already part of a cluster (`kubectl get serverbindings` should provide this info), you can now delete the machine that corresponds with this server via `kubectl delete machine <machine_name>`.
|
||||
|
||||
- With the machine deleted, Sideo will reboot the machine and wipe its disks.
|
||||
- With the machine deleted, Sidero will reboot the machine and wipe its disks.
|
||||
|
||||
- Once the disk wiping is complete and the server is turned off, you can finally delete the server from Sidero with `kubectl delete server <server_name>` and repurpose the server for something else.
|
||||
|
||||
|
||||
@ -18,6 +18,6 @@ The rough outline of this process is very short and sweet, as it relies on other
|
||||
- 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.
|
||||
> 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.
|
||||
|
||||
@ -106,13 +106,13 @@ These can be used to compose a bank of `Servers` that are eligible for provision
|
||||
|
||||
See the [ServerClasses](../../resource-configuration/serverclasses/) section of our Configuration docs for examples and more detail.
|
||||
|
||||
### Metal Metadata Server
|
||||
### Sidero Controller Manager
|
||||
|
||||
While the metadata server does not present unique CRDs within Kubernetes, it's important to understand the metadata resources that are returned to physical servers during the boot process.
|
||||
While the controller does not present unique CRDs within Kubernetes, it's important to understand the metadata resources that are returned to physical servers during the boot process.
|
||||
|
||||
#### Metadata
|
||||
|
||||
The metadata server may be familiar to you if you have used cloud environments previously.
|
||||
Using Talos machine configurations created by the Talos Cluster API bootstrap provider, along with patches specified by editing `Server`/`ServerClass` resources or `TalosConfig`/`TalosControlPlane` resources, metadata is returned to servers who query the metadata server at boot time.
|
||||
The Sidero controller manager server may be familiar to you if you have used cloud environments previously.
|
||||
Using Talos machine configurations created by the Talos Cluster API bootstrap provider, along with patches specified by editing `Server`/`ServerClass` resources or `TalosConfig`/`TalosControlPlane` resources, metadata is returned to servers who query the controller manager at boot time.
|
||||
|
||||
See the [Metadata](../../resource-configuration/metadata/) section of our Configuration docs for examples and more detail.
|
||||
|
||||
@ -4,7 +4,7 @@ weight: 4
|
||||
title: Metadata
|
||||
---
|
||||
|
||||
The Metadata server manages the Machine 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/)",
|
||||
which is used during the automated installation.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user