Skip to content

docs: add documentation about ssa behaviour in talos v1.13 #280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Orzelius wants to merge 1 commit into
base: main
Choose a base branch
from
+15 −12
Open

docs: add documentation about ssa behaviour in talos v1.13 #280

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 5 additions & 10 deletions public/kubernetes-guides/advanced-guides/inlinemanifests.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,16 +124,11 @@ Here’s a quick overview of the key differences between `inlineManifests` and `

## How Talos Handles Manifest Resources

Talos continuously reconciles manifests on every boot, on every failure to apply, and on every change to the manifests in the machine config.
Talos reconciles manifests on every boot, on every failure to apply, and on every change to the manifests in the machine config.
When processing your `inlineManifests` and `extraManifests`, Talos follows a conservative, additive-only approach.

Here's what that means in practice:
This means that Talos automatically only creates new resources.
Once created Talos never edits or deletes resources even if they are modified or removed from the machine configuration.

* **Creates missing resources**: If a resource defined in your manifests doesn't exist in the cluster, Talos will create it.

* **Preserves existing resources**: Resources that already exist in the cluster are left completely unchanged, regardless of any differences between the current state and the manifest definition.

* **Never deletes resources**: Talos will not remove resources from the cluster, even if they're no longer present in your manifest configuration.

If you need to reapply or update these manifests after the cluster has been created, use the [Kubernetes upgrade](./upgrading-kubernetes) process.
Specify the same Kubernetes version that’s currently running in your cluster to ensure that only the manifests are reapplied, without performing a version upgrade.
If you need to prune unwanted resources or update the resources, use the [Kubernetes upgrade](./upgrading-kubernetes) process.
Copy link
Member

@smira smira Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and probably here, starting with Talos 1.13+

Specify the same Kubernetes version that’s currently running in your cluster to skip performing a kubernetes version upgrade and only synchronize manifests.
12 changes: 10 additions & 2 deletions public/kubernetes-guides/advanced-guides/upgrading-kubernetes.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,13 +107,21 @@ This command runs in several phases:
The update is verified by checking the `Node` resource state.
5. Kubernetes bootstrap manifests are re-applied to the cluster.
Updated bootstrap manifests might come with a new Talos version (e.g. CoreDNS version update), or might be the result of machine configuration change.

> Note: The `upgrade-k8s` command never deletes any resources from the cluster: they should be deleted manually.
6. Unneeded resources are pruned from the cluster.
Copy link
Member

@smira smira Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put a note here that this applies to Talos 1.13+


If the command fails for any reason, it can be safely restarted to continue the upgrade process from the moment of the failure.

> Note: When using custom/overridden Kubernetes component images, use flags `--*-image` to override the default image names.

### Pruning

> Note: Pruning is supported from Talos and talosctl v1.13 onwards.

Pruning of resources from the cluster occurs when any services were deleted or disabled.
For example if [kube-proxy](../../talos/v1.12/reference/configuration/v1alpha1/config.mdx#proxy) was disabled in the machine configuration the resources associated with it would be deleted at this stage.
Copy link
Member Author

@Orzelius Orzelius Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to create a link that automatically takes to the latest reference version here?

Copy link
Member

@Iheanacho-ai Iheanacho-ai Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, you'd have to use the latest variable


Pruning can be disabled by passing the `--manifests-no-prune` flag.

### Synchronize Declared and Deployed Configurations

When Kubernetes is upgraded with `talosctl upgrade-k8s`, the live machine configuration on your nodes is updated with new component image versions (API server, controller manager, scheduler, kube-proxy, etc.).
Expand Down
Loading