mirror of
https://github.com/siderolabs/talos.git
synced 2026-01-09 18:51:17 +01:00
docs: update the kubespan docs
add info on kubespan's relationship with discovery service, when unavailable Signed-off-by: Amarachi Iheanacho <amarachi.iheanacho@siderolabs.com>
This commit is contained in:
Amarachi Iheanacho
parent
8b041a72ca
commit
dfbece56bd
@ -125,6 +125,12 @@ cluster:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
## Discovery Service Availability
|
||||
|
||||
KubeSpan depends on the Discovery Service for peer discovery and key exchange. Once all nodes in a cluster have established their KubeSpan connections, the cluster can continue operating normally even if the Discovery Service becomes temporarily unavailable. When the cluster is already running and all peers are connected, node-to-node communication remains seamless because the existing WireGuard sessions persist, allowing operations to continue uninterrupted.
|
||||
|
||||
However, if the Discovery Service is unavailable and you reboot a node or attempt to add new ones, those nodes will be unable to join or rejoin the mesh until the service becomes reachable again. This is because new key exchanges and peer discovery require an active connection to the Discovery Service.
|
||||
|
||||
## Configuration
|
||||
|
||||
KubeSpan will automatically discover all cluster members, exchange Wireguard public keys and establish a full mesh network.
|
||||
|
||||
@ -121,30 +121,6 @@ Version numbers for Talos, etcd, Kubernetes components, and add-ons change frequ
|
||||
|
||||
See the [Reproducible Machine Configuration]({{< relref "../talos-guides/configuration/reproducible-machine-config.md" >}}) guide for full instructions on handling machine configurations after version bumps.
|
||||
|
||||
#### Recommended Workflow
|
||||
|
||||
Instead of storing full machine configs, keep only the following:
|
||||
|
||||
* `secrets.yaml` (cluster secrets generated once at cluster creation)
|
||||
* Patch files (YAML/JSON patches that describe the differences you want from the defaults — e.g. custom networking, node labels, additional arguments)
|
||||
|
||||
When you need machine configs:
|
||||
|
||||
1. Generate fresh base machine configs with your `secrets.yaml`:
|
||||
|
||||
```bash
|
||||
talosctl gen config <cluster-name> <cluster-endpoint> \
|
||||
--with-secrets secrets.yaml
|
||||
```
|
||||
|
||||
1. [Apply your stored patches]({{< relref "../talos-guides/configuration/patching.md#configuration-patching-with-talosctl-cli" >}}) on top of the generated configs.
|
||||
|
||||
1. Use the patched configs when creating or updating nodes.
|
||||
|
||||
1. Discard the generated base configs.
|
||||
|
||||
This workflow ensures that upgrades via `talosctl upgrade-k8s` do not create drift between the live and declared state, since version bumps are handled automatically in regenerated configs.
|
||||
|
||||
## Manual Kubernetes Upgrade
|
||||
|
||||
Kubernetes can be upgraded manually by following the steps outlined below.
|
||||
|
||||
@ -125,6 +125,12 @@ cluster:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
## Discovery Service Availability
|
||||
|
||||
KubeSpan depends on the Discovery Service for peer discovery and key exchange. Once all nodes in a cluster have established their KubeSpan connections, the cluster can continue operating normally even if the Discovery Service becomes temporarily unavailable. When the cluster is already running and all peers are connected, node-to-node communication remains seamless because the existing WireGuard sessions persist, allowing operations to continue uninterrupted.
|
||||
|
||||
However, if the Discovery Service is unavailable and you reboot a node or attempt to add new ones, those nodes will be unable to join or rejoin the mesh until the service becomes reachable again. This is because new key exchanges and peer discovery require an active connection to the Discovery Service.
|
||||
|
||||
## Configuration
|
||||
|
||||
KubeSpan will automatically discover all cluster members, exchange Wireguard public keys and establish a full mesh network.
|
||||
|
||||
@ -121,30 +121,6 @@ Version numbers for Talos, etcd, Kubernetes components, and add-ons change frequ
|
||||
|
||||
See the [Reproducible Machine Configuration]({{< relref "../talos-guides/configuration/reproducible-machine-config.md" >}}) guide for full instructions on handling machine configurations after version bumps.
|
||||
|
||||
#### Recommended Workflow
|
||||
|
||||
Instead of storing full machine configs, keep only the following:
|
||||
|
||||
* `secrets.yaml` (cluster secrets generated once at cluster creation)
|
||||
* Patch files (YAML/JSON patches that describe the differences you want from the defaults — e.g. custom networking, node labels, additional arguments)
|
||||
|
||||
When you need machine configs:
|
||||
|
||||
1. Generate fresh base machine configs with your `secrets.yaml`:
|
||||
|
||||
```bash
|
||||
talosctl gen config <cluster-name> <cluster-endpoint> \
|
||||
--with-secrets secrets.yaml
|
||||
```
|
||||
|
||||
1. [Apply your stored patches]({{< relref "../talos-guides/configuration/patching.md#configuration-patching-with-talosctl-cli" >}}) on top of the generated configs.
|
||||
|
||||
1. Use the patched configs when creating or updating nodes.
|
||||
|
||||
1. Discard the generated base configs.
|
||||
|
||||
This workflow ensures that upgrades via `talosctl upgrade-k8s` do not create drift between the live and declared state, since version bumps are handled automatically in regenerated configs.
|
||||
|
||||
## Manual Kubernetes Upgrade
|
||||
|
||||
Kubernetes can be upgraded manually by following the steps outlined below.
|
||||
|
||||
@ -125,6 +125,12 @@ cluster:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
## Discovery Service Availability
|
||||
|
||||
KubeSpan depends on the Discovery Service for peer discovery and key exchange. Once all nodes in a cluster have established their KubeSpan connections, the cluster can continue operating normally even if the Discovery Service becomes temporarily unavailable. When the cluster is already running and all peers are connected, node-to-node communication remains seamless because the existing WireGuard sessions persist, allowing operations to continue uninterrupted.
|
||||
|
||||
However, if the Discovery Service is unavailable and you reboot a node or attempt to add new ones, those nodes will be unable to join or rejoin the mesh until the service becomes reachable again. This is because new key exchanges and peer discovery require an active connection to the Discovery Service.
|
||||
|
||||
## Configuration
|
||||
|
||||
KubeSpan will automatically discover all cluster members, exchange Wireguard public keys and establish a full mesh network.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user