;
};
For critical changes, refer to the [upgrade notes](../configure-your-talos-cluster/lifecycle-management/upgrading-talos).
## Important changes
These changes may affect existing clusters, and should be reviewed before upgrading.
### Workload isolation (`sandboxd`)
The container runtime plane — CRI containerd, the kubelet, and all pods — now runs inside a dedicated PID and mount namespace
anchored by a new `sandboxd` service, instead of sharing `machined`'s namespaces.
`sandboxd` runs in its own least-privilege SELinux domain (`sandboxd_t`).
If it dies, the kernel tears down the namespace and Talos recreates it — relaunching CRI, the kubelet, and pods — without rebooting the node.
Its logs are available via `talosctl logs sandboxd`.
Workload isolation is controlled by the `workloadIsolation` field of the new [`SecurityProfileConfig`](../reference/configuration/runtime/securityprofileconfig) document.
`talosctl gen config` emits it with `workloadIsolation: true` for Talos 1.14+, so **new clusters are isolated by default**.
Clusters **upgraded** from older versions do not have this document, and therefore keep the previous (non-isolated) behavior until it is added — upgrades change nothing on their own.
To enable workload isolation on an existing cluster, add the following document:
```yaml theme={null}
apiVersion: v1alpha1
kind: SecurityProfileConfig
workloadIsolation: true
```
> Note: with workload isolation enabled, the deprecated in-tree Kubernetes iSCSI volume plugin does not work
> (the kubelet cannot reach the host `iscsid` across the sandbox); use a CSI driver instead.
### In-tree volume plugins deprecated
Because the kubelet now runs inside the sandbox namespace (see the workload isolation note above), the in-tree Kubernetes volume plugins
which require the kubelet to reach host-level daemons no longer work.
In particular, the in-tree `iscsi` volume plugin, which drives the kubelet's `iscsiadm` wrapper to talk to the host `iscsid`,
can no longer locate it across the sandbox PID namespace boundary.
Use CSI drivers instead: a CSI node plugin performs the attach/mount itself in its own privileged pod, and is unaffected by the sandbox.
For iSCSI, `kubernetes-csi/csi-driver-iscsi` (or `democratic-csi`) consumes a target the same way.
All in-tree (non-CSI) volume plugins are deprecated for the kubelet, and support for them may be removed in a later release.
### `noexec` on `EPHEMERAL` (`/var`)
New Talos 1.14 clusters default the `EPHEMERAL` volume (`/var`) to `noexec`, in addition to the existing `nosuid` and `nodev` mount options,
through the generated machine configuration.
Existing machines are not affected on upgrades.
> Note: workloads which execute binaries placed under `/var` can break on new machines.
> Longhorn v1 and [vCluster](https://www.vcluster.com/docs/vcluster/troubleshoot/noexec-emptydir-volumes) are known to be affected.
> For example, Longhorn v1's `instance-manager` executes engine binaries which the `engine-image` DaemonSet places under
> `/var/lib/longhorn/engine-binaries/`, which now fails with `permission denied`.
Affected users can opt out via a [`VolumeConfig`](../reference/configuration/block/volumeconfig) document:
```yaml theme={null}
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
mount:
secure: false
```
> Note: setting `secure: false` also disables `nosuid` and `nodev`, which may have security implications. Use with caution.
Longhorn v2 (SPDK data engine) runs the data plane inside the instance manager process, and is not affected.
### Unattended install configuration
Talos introduces a new [`UnattendedInstallConfig`](../reference/configuration/runtime/unattendedinstallconfig) multi-document configuration kind,
which replaces the deprecated `.machine.install` section of the v1alpha1 config.
The document carries the installer `image` and a `provisioning` section with a CEL `volumeSelector` to match the install disk, plus a `wipe` option.
When the `UnattendedInstallConfig` document is present, the install is driven by the new `UnattendedInstallController`
(exposing an `UnattendedInstallStatus` resource) instead of the legacy install sequence.
`talosctl gen config` and `talosctl cluster create` now generate the `UnattendedInstallConfig` document by default.
The `.machine.install` field remains supported for backwards compatibility, and is still used for older version contracts.
### Default installer image
The default installer image has been updated to use the [Image Factory](../learn-more/image-factory).
The `ghcr.io/siderolabs/installer` image is no longer published with releases; use the Image Factory installer image instead.
### Native BGP
Talos Linux now supports multiple named native BGP routing instances in the default routing domain or a Linux VRF.
Instances support numbered and unnumbered peers, ECMP, BFD, optional Linux route installation, and selective route imports between instances.
See [Native BGP](../networking/bgp/overview) for configuration and Kubernetes workload-speaker examples.
### Apply configuration modes
The `--mode=reboot` option has been removed from the `talosctl apply-config` command; by default, configuration is applied without a reboot.
Reboot the node explicitly with `talosctl reboot` when it is needed, which allows the reboot to be sequenced with cordoning and draining the node.
See [Changes which might need a reboot](../configure-your-talos-cluster/system-configuration/editing-machine-configuration#changes-which-might-need-a-reboot) for the changes which are not fully picked up by a running node.
## Machine configuration
Talos 1.14 continues splitting the monolithic `v1alpha1` document into focused multi-document configuration kinds.
The `v1alpha1` fields listed below are deprecated, but remain supported for backwards compatibility.
See the [configuration document map](../reference/configuration/document-map) for which document now owns each `v1alpha1` field, and when each one arrived.
### Kubernetes multi-document configuration
Talos introduces new multi-document Kubernetes configuration, which allows for more flexible and modular configuration of Kubernetes components.
Talos still supports the old v1alpha1 config for backwards compatibility, but new features and fields will only be available in the new multi-document format.
The `kube-proxy` is now managed via a configuration file instead of command line arguments (with the new [`KubeProxyConfig`](../reference/configuration/kubernetes/kubeproxyconfig) document).
List of changes:
* Deprecated `.cluster.secretboxEncryptionSecret`; use the [`KubeEtcdEncryptionConfig`](../reference/configuration/kubernetes/kubeetcdencryptionconfig) document for full etcd encryption configuration.
* Deprecated `.cluster.apiServer`; use the [`KubeAPIServerConfig`](../reference/configuration/kubernetes/kubeapiserverconfig), [`KubeAdmissionControlConfig`](../reference/configuration/kubernetes/kubeadmissioncontrolconfig), [`KubeAuditPolicyConfig`](../reference/configuration/kubernetes/kubeauditpolicyconfig), [`KubeAuthenticationConfig`](../reference/configuration/kubernetes/kubeauthenticationconfig) and [`KubeAuthorizerConfig`](../reference/configuration/kubernetes/kubeauthorizerconfig) documents.
* Deprecated `.cluster.ca`, `.cluster.acceptedCAs` and `.cluster.aggregatorCA`; use the [`KubeAPIServerCAConfig`](../reference/configuration/kubernetes/kubeapiservercaconfig) and [`KubeAggregatorCAConfig`](../reference/configuration/kubernetes/kubeaggregatorcaconfig) documents.
* Deprecated `.cluster.controllerManager`; use the [`KubeControllerManagerConfig`](../reference/configuration/kubernetes/kubecontrollermanagerconfig) document.
* Deprecated `.cluster.scheduler`; use the [`KubeSchedulerConfig`](../reference/configuration/kubernetes/kubeschedulerconfig) document.
* Deprecated `.cluster.proxy`; use the [`KubeProxyConfig`](../reference/configuration/kubernetes/kubeproxyconfig) document.
* Deprecated `.cluster.network`; use the [`KubeNetworkConfig`](../reference/configuration/kubernetes/kubenetworkconfig) document; Flannel can be configured using the [`KubeFlannelCNIConfig`](../reference/configuration/kubernetes/kubeflannelcniconfig) document.
* Deprecated `.cluster.coreDNS`; use the [`KubeCoreDNSConfig`](../reference/configuration/kubernetes/kubecorednsconfig) document.
* Deprecated `.cluster.name` and `.cluster.controlPlane.endpoint`; use the [`KubeClusterConfig`](../reference/configuration/kubernetes/kubeclusterconfig) document.
* Deprecated the following fields, all of which moved into [`KubeNodeConfig`](../reference/configuration/kubernetes/kubenodeconfig):
* `.cluster.allowSchedulingOnControlPlanes`
* `.machine.kubelet.skipNodeRegistration`
* `.machine.kubelet.registerWithFQDN`
* `.machine.kubelet.nodeIP`
* `.machine.nodeLabels`
* `.machine.nodeAnnotations`
* `.machine.nodeTaints`
* The default `NoSchedule` taint and label for controlplane nodes are now listed explicitly in `KubeNodeConfig`.
* Deprecated the rest of the `.machine.kubelet` fields; use the [`KubeletConfig`](../reference/configuration/kubernetes/kubeletconfig) and [`KubeCredentialProviderConfig`](../reference/configuration/kubernetes/kubecredentialproviderconfig) documents.
* Deprecated `.machine.pods`; use the [`KubeStaticPodConfig`](../reference/configuration/kubernetes/kubestaticpodconfig) document.
* Deprecated `.machine.files`; use dedicated configuration documents such as [`EtcFileConfig`](../reference/configuration/runtime/etcfileconfig) and [`CRICustomizationConfig`](../reference/configuration/cri/cricustomizationconfig) instead.
* Deprecated `.machine.baseRuntimeSpecOverrides`; use the [`CRIBaseRuntimeSpecConfig`](../reference/configuration/cri/cribaseruntimespecconfig) document.
* Deprecated `.cluster.inlineManifests`; use the [`KubeInlineManifestConfig`](../reference/configuration/kubernetes/kubeinlinemanifestconfig) document.
* Deprecated `.cluster.extraManifests` and `.cluster.extraManifestHeaders`; use the [`KubeExternalManifestConfig`](../reference/configuration/kubernetes/kubeexternalmanifestconfig) document.
* Deprecated `.machine.features.kubePrism`; use the [`KubePrismConfig`](../reference/configuration/kubernetes/kubeprismconfig) document (or remove it to disable KubePrism).
* Added `nodeCIDRMaskSizeIPv4` (default `24`) and `nodeCIDRMaskSizeIPv6` (default `64`) settings to the `KubeNetworkConfig` document to control the per-node pod CIDR mask size, and to validate the pod and service subnet sizes.
### Kernel multi-document configuration
Talos introduces new multi-document configuration for kernel parameters (sysctl and sysfs settings), replacing the old v1alpha1 config fields.
The old configuration is still supported for backwards compatibility, but new deployments should use the new documents.
If both old and new configuration sources are used, the new multi-document configuration takes precedence over the old v1alpha1 config on conflicting fields.
List of changes:
* Deprecated `.machine.sysctls`; use the [`SysctlConfig`](../reference/configuration/runtime/sysctlconfig) document.
* Deprecated `.machine.sysfs`; use the [`SysfsConfig`](../reference/configuration/runtime/sysfsconfig) document.
* Deprecated `.machine.kernel`; use the [`KernelModuleConfig`](../reference/configuration/runtime/kernelmoduleconfig) document.
### Udev rules multi-document configuration
Talos introduces the new [`UdevRulesConfig`](../reference/configuration/runtime/udevrulesconfig) document for configuring custom udev rules.
The old v1alpha1 `.machine.udev.rules` field is still supported for backwards compatibility, but new deployments should use the new document.
If both old and new configuration sources are used, `UdevRulesConfig` takes precedence.
### Cluster discovery
Talos now supports configuring multiple [discovery service](../configure-your-talos-cluster/system-configuration/discovery) endpoints,
and introduces a new document for configuring the cluster discovery identity.
List of changes:
* Deprecated `.cluster.discovery`; use the [`DiscoveryServiceConfig`](../reference/configuration/cluster/discoveryserviceconfig) document.
The v1alpha1 config and `DiscoveryServiceConfig` are mutually exclusive.
* Deprecated `.cluster.secret` and `.cluster.id`; use the [`DiscoveryIdentityConfig`](../reference/configuration/cluster/discoveryidentityconfig) document.
The v1alpha1 config and `DiscoveryIdentityConfig` are mutually exclusive.
* Changed the cluster ID encoding in the generated secret bundle from `base64.URLEncoding` to `base64.StdEncoding`, which aligns the encoding with the rest of Talos.
### User-managed files under `/etc`
Talos now supports managing user-owned files under `/etc` with the new [`EtcFileConfig`](../reference/configuration/runtime/etcfileconfig) multi-document
configuration kind.
The document `name` is the path relative to `/etc`, and each document owns the complete file contents and mode.
This can be used to configure files such as `/etc/nfsmount.conf` or `/etc/multipath.conf`.
Talos-managed paths, including `resolv.conf`, `hosts`, `machine-id`, CRI and Kubernetes configuration, trust bundles and identity files, are rejected
to prevent overriding files owned by Talos.
### Image cache configuration
Talos now supports the new [`ImageCacheConfig`](../reference/configuration/cri/imagecacheconfig) document for configuring the
[Image Cache](../configure-your-talos-cluster/images-container-runtime/image-cache) feature, replacing the `.machine.features.imageCache` field in the v1alpha1 config:
```yaml theme={null}
apiVersion: v1alpha1
kind: ImageCacheConfig
local:
enabled: true
```
The `localEnabled` field is now `local.enabled`.
The old configuration is still supported for backwards compatibility, but the two are mutually exclusive: the document is rejected if `.machine.features.imageCache` is also set.
## Container runtime
The CRI containerd configuration can now be customized with dedicated configuration documents, and applied without a reboot.
### CRI customization configuration
Talos now supports customizing the [CRI containerd configuration](../configure-your-talos-cluster/images-container-runtime/containerd) with named
[`CRICustomizationConfig`](../reference/configuration/cri/cricustomizationconfig) documents.
Each document contains a TOML fragment; fragments are merged in lexicographical order by name.
Applying, updating or removing these documents updates the generated CRI configuration and restarts CRI automatically.
The legacy `/etc/cri/conf.d/20-customization.part` machine-file configuration remains supported during the deprecation period,
and is exposed under the reserved name `customization`.
A `CRICustomizationConfig` document cannot use that name.
> Note: a machine reboot is no longer required to apply changes to the CRI configuration.
### CRI base runtime specification configuration
Talos now supports overriding the default OCI runtime specification for CRI containers with a
[`CRIBaseRuntimeSpecConfig`](../reference/configuration/cri/cribaseruntimespecconfig) document:
```yaml theme={null}
apiVersion: v1alpha1
kind: CRIBaseRuntimeSpecConfig
overrides:
process:
rlimits:
- type: RLIMIT_NOFILE
hard: 1024
soft: 1024
```
The `.machine.baseRuntimeSpecOverrides` field is deprecated, and remains supported during the deprecation period.
It is mutually exclusive with `CRIBaseRuntimeSpecConfig`; configurations containing both are rejected.
Applying, updating or removing either source regenerates the base runtime specification and restarts CRI automatically.
A machine reboot is no longer required.
### Containerd NRI
Talos no longer disables NRI (Node Resource Interface) for the CRI containerd instance by default, so NRI is available to use without any machine config patches.
To bring back the old behavior of NRI being disabled by default, add the following machine configuration document:
```yaml theme={null}
apiVersion: v1alpha1
kind: CRICustomizationConfig
name: disable-nri
content: |
[plugins]
[plugins."io.containerd.nri.v1.nri"]
disable = true
```
## Storage subsystem
Talos gains declarative software RAID and LVM provisioning, periodic filesystem trimming, and a number of volume-level options.
### RAID array creation
Talos can now create and grow Linux MD (software RAID) arrays declaratively through the new
[`RAIDArrayConfig`](../reference/configuration/storage/raidarrayconfig) multi-document configuration kind.
Each document names an array, its `level` (`raid1`) and a CEL `volumeSelector` over the disk inventory; matched disks are assembled into the requested array
with `mdadm` and exposed at the stable `/dev/disk/by-id/md-name-` path.
New matching disks added to an existing array are attached automatically.
Reconciliation is strictly additive and safe by default: arrays are never destroyed by removing the config;
removal stays an explicit operation via `talosctl wipe md `.
The new `MDArrayStatus` resource reports the assembled array, level, device path and members.
### Booting from a RAID array
Talos can now be installed onto and boot from a Linux MD (software RAID) array.
Define a `RAIDArrayConfig` for the array, and point the install disk selector
([`UnattendedInstallConfig`](../reference/configuration/runtime/unattendedinstallconfig)) at the resulting `/dev/disk/by-id/md-name-` device.
Only `raid1` arrays with `metadata: "1.0"` can be used for booting: the 1.0 format keeps its superblock at the end of each member,
so the partition table written to the array stays visible at the start of every disk, allowing the firmware to boot from any member.
`metadata` defaults to `1.0`; other levels and metadata formats are not bootable.
### LVM volume group creation
Talos can now create and grow [LVM](../configure-your-talos-cluster/storage-and-disk-management/lvm) Volume Groups declaratively through the new
[`LVMVolumeGroupConfig`](../reference/configuration/storage/lvmvolumegroupconfig) multi-document configuration kind.
Each document names a Volume Group and a CEL `volumeSelector` over the disk inventory; matched disks are initialized as Physical Volumes (`pvcreate`)
and aggregated into the requested VG (`vgcreate`).
Newly matched disks added to an existing VG are attached via `vgextend`.
Reconciliation is strictly additive and safe by default.
### LVM logical volume creation
Logical volumes can now be declared with the new [`LVMLogicalVolumeConfig`](../reference/configuration/storage/lvmlogicalvolumeconfig) multi-document
configuration kind.
Each document names a logical volume, its parent `volumeGroup`, a `type` (`linear`, `raid0`, `raid1` or `raid10`) and a `maxSize`
(absolute, e.g. `50GiB`, or a percentage of the volume group, e.g. `80%`).
RAID layouts accept optional `mirrors` (raid1/raid10, default 1) and `stripes` (raid0/raid10, default: all available physical volumes) fields.
Once the volume group is assembled, the logical volume is created via `lvcreate`.
Raising `maxSize` grows an existing logical volume via `lvextend`; percentage-sized volumes also grow when their volume group is extended.
Shrinking is never performed (it risks data loss) — a request to reduce the size surfaces an `LVMValidationError` instead.
Removal stays an explicit operation via the `LVMService` LV remove RPC (`talosctl wipe lv`).
### LVM status
Talos now provides detailed LVM status information, allowing for better monitoring and management of LVM volumes.
The new `LVMPhysicalVolumeStatus`, `LVMVolumeGroupStatus` and `LVMLogicalVolumeStatus` resources expose PV, VG and LV details.
`DiscoveredVolume` resources for logical volumes are listed by their kernel name (e.g. `dm-0`).
To resolve the `/` for a given device, use the `Disks` or `BlockSymlinks` resources, which carry the udev-managed symlinks
(e.g. `/dev/disk/by-id/dm-name--`).
### LVM wipe
Talos now provides the ability to securely wipe LVM metadata from logical volumes, volume groups and physical volumes.
With `talosctl wipe lv/vg/pv `, users can wipe LVM metadata from a specific logical volume, volume group or physical volume.
### Filesystem trim
Talos can now periodically trim (the equivalent of the `fstrim` command) mounted filesystems which support trimming, discarding unused blocks.
This is useful for SSDs and thin-provisioned storage.
The global trim interval is set by the new [`FilesystemTrimConfig`](../reference/configuration/block/filesystemtrimconfig) document:
```yaml theme={null}
apiVersion: v1alpha1
kind: FilesystemTrimConfig
interval: 168h0m0s # one week
```
`talosctl gen config` emits this document with a trim interval of one week for Talos 1.14+, so **new clusters trim eligible filesystems by default**.
Clusters **upgraded** from older versions do not have this document, so trimming stays disabled until it is added — upgrades change nothing on their own.
When the document is present, Talos builds a stable schedule (hashed by node ID and volume ID, so that trims are spread out across volumes and across nodes
in a cluster) and trims eligible volumes (ready disk/partition volumes with a trim-capable filesystem; for encrypted volumes, only when `allowDiscards` is set).
The trim interval can be overridden or disabled per volume via a `trim` block on the volume documents
([`VolumeConfig`](../reference/configuration/block/volumeconfig), [`UserVolumeConfig`](../reference/configuration/block/uservolumeconfig),
[`ExistingVolumeConfig`](../reference/configuration/block/existingvolumeconfig)):
```yaml theme={null}
trim:
enabled: true
interval: 24h0m0s
```
See [Filesystem Trim](../configure-your-talos-cluster/storage-and-disk-management/filesystem-trim) for the schedule details and for the resources reporting the trim status.
### Filesystem scrub
Talos can now periodically run background online filesystem maintenance, checking mounted filesystems for metadata errors.
Currently only XFS is supported, via the `xfs_scrub` tool.
Scrubbing is disabled by default, and is enabled globally with the new
[`FilesystemScrubConfig`](../reference/configuration/block/filesystemscrubconfig) document, which sets the scrub interval:
```yaml theme={null}
apiVersion: v1alpha1
kind: FilesystemScrubConfig
interval: 168h0m0s # one week
```
As with filesystem trim, Talos builds a stable schedule (hashed by node ID and volume ID) so that scrubs are spread out across volumes and across nodes
in a cluster.
Volumes which are not mounted, or mounted read-only or detached, are skipped.
The scrub runs at the lowest CPU and I/O priority, and its progress is reported by the new `FSScrubStatus` resource.
The scrub interval can be overridden or disabled per volume via a `scrub` block on the volume documents
([`VolumeConfig`](../reference/configuration/block/volumeconfig), [`UserVolumeConfig`](../reference/configuration/block/uservolumeconfig),
[`ExistingVolumeConfig`](../reference/configuration/block/existingvolumeconfig)):
```yaml theme={null}
scrub:
enabled: true
interval: 24h0m0s
```
A `scrub` block enables scrubbing for the volume even when the global document is absent (defaulting to a one week interval),
unless `enabled: false` is set explicitly.
See [Filesystem Scrub](../configure-your-talos-cluster/storage-and-disk-management/filesystem-scrub) for the schedule details and for the resources reporting the scrub status.
### Dedicated system volumes
The `ETCD`, `CRI`, `KUBELET` and `LOG` [system volumes](../configure-your-talos-cluster/storage-and-disk-management/disk-management/system)
(`/var/lib/etcd`, `/var/lib/containerd`, `/var/lib/kubelet` and `/var/log`) can now be placed on dedicated partitions via a
[`VolumeConfig`](../reference/configuration/block/volumeconfig) document with `provisioning` set (optionally encrypted).
By default they remain directories under the `EPHEMERAL` volume.
```yaml theme={null}
apiVersion: v1alpha1
kind: VolumeConfig
name: ETCD
provisioning:
minSize: 1GB
maxSize: 2GB
```
The backing (directory vs. dedicated partition) is fixed at cluster creation: switching an already provisioned node between the two is rejected.
A dedicated partition has its own mount, so the `mount.secure` option (`nosuid`/`noexec`/`nodev`, enabled by default) can be set per volume;
directory-backed volumes inherit the `EPHEMERAL` mount options.
> Note: with `ETCD` on a dedicated partition, etcd data no longer lives under `EPHEMERAL`.
> Resetting a control plane node with only the `EPHEMERAL` partition wiped will not clear etcd data; wipe the `ETCD` volume to reset etcd.
### Btrfs support
Talos now supports mounting and provisioning the `btrfs` filesystem for [user volumes](../configure-your-talos-cluster/storage-and-disk-management/disk-management/user)
and existing volumes.
Support for `btrfs` is enabled by installing the `btrfs` [system extension](../build-and-extend-talos/custom-images-and-development/system-extensions).
### Encryption discards
[Volume encryption](../configure-your-talos-cluster/storage-and-disk-management/disk-encryption) now supports an `allowDiscards` option (disabled by default),
which passes TRIM/discard requests through to the underlying device when the encrypted volume is opened.
This only enables passing discards through to the underlying device; Talos does not perform any `fstrim`/discard operation by itself.
### XFS allocation group geometry
On non-rotational devices `mkfs.xfs` sizes the allocation group count to the number of CPUs, bounding the allocation group size from below at 4 GiB only.
On machines with many cores and a modest disk this produces hundreds of tiny allocation groups, which squeezes the AG-local reflink/rmap metadata
(leading to spurious `ENOSPC` on reflink-heavy workloads while the filesystem still has plenty of free space) and inflates the journal at the same time.
Talos now keeps XFS allocation groups at 64 GiB or above when it formats a volume.
The bound can be changed per volume, and setting it to zero restores the stock `mkfs.xfs` behavior:
```yaml theme={null}
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
filesystem:
xfs:
minAllocationGroupSize: 128GiB
```
The same `filesystem.xfs.minAllocationGroupSize` setting is available for [`UserVolumeConfig`](../reference/configuration/block/uservolumeconfig).
> Note: allocation group geometry is fixed when the filesystem is created, so this only affects volumes formatted by Talos 1.14 or later.
> Existing volumes keep their current geometry until they are wiped and re-created (e.g. `talosctl reset --system-labels-to-wipe=EPHEMERAL`).
## Network subsystem
Talos gains a native BGP speaker, encrypted DNS, authenticated time synchronization and HTTP probes.
### Native BGP
Talos now supports running native BGP routing instances on the host via embedded GoBGP servers, configured with the new
[`BGPInstanceConfig`](../reference/configuration/network/bgpinstanceconfig) document.
This removes the need to ship FRR as a system extension for the common fabric-facing use case.
List of changes:
* Added repeatable, named `BGPInstanceConfig` documents to configure the local ASN, router ID, optional Linux VRF,
advertised interfaces (loopbacks originated as host routes), neighbors, and per-route preferred source (`routeSource`).
* Peer hold-time and BFD behavior are configured inline on each neighbor, which selects either an address or a link.
* Numbered and unnumbered (IPv6 link-local, RFC 8950 extended next-hop) peering are supported, including IPv4 prefixes learned over an IPv6 link-local next-hop.
* Neighbor-local ASN overrides and passive sessions are supported.
ECMP (multipath) and BFD (fast failure detection) are supported for fabric peering.
* BFD is currently supported only by the instance in the default routing domain; GoBGP's embedded BFD listener is not VRF-aware.
* Each instance owns an isolated BGP RIB and, by default, installs learned routes into its default or VRF routing table through the existing route controllers.
Set `installRoutes: false` to keep learned routes in the BGP RIB without installing them into the Linux routing table.
* Instances can selectively import best neighbor-learned routes from other named instances with `importRoutes` prefix selectors.
Imports are one-way, preserve path attributes, and do not recursively import locally originated or previously imported paths.
* Peer state is observable via instance-qualified `BGPPeerStatus` resources (`talosctl get bgppeerstatus`).
* `RouteSpec`/`RouteStatus` now carry a multipath next-hop list to support ECMP and cross-family (RFC 8950) next-hops.
### DNS over TLS (DoT) and DNS over HTTPS (DoH) support
Talos now supports DNS over TLS (DoT) and DNS over HTTPS (DoH) for secure DNS resolution.
These features allow Talos to encrypt DNS queries and responses, enhancing privacy and security for DNS traffic.
The DNS protocol can be configured on a per-nameserver basis in the [`ResolverConfig`](../reference/configuration/network/resolverconfig) document,
allowing for flexible configuration of [DNS resolution](../networking/configuration/resolvers).
> Note: encrypted DNS protocols require a correct system clock to validate certificates.
> If NTP servers are configured with hostnames which need to be resolved over DoT/DoH, the boot may stall: NTP needs DNS, and TLS needs valid time.
> Either rely on the hardware clock, configure NTP servers by IP address, or keep at least one plain DNS fallback nameserver.
### Host DNS configuration
[Host DNS](../networking/host-dns) configuration has been moved from the v1alpha1 config `.machine.features.hostDNS` field to the new `hostDNS` section
of the [`ResolverConfig`](../reference/configuration/network/resolverconfig) document.
### NTS for time synchronization
Talos now supports Network Time Security (NTS) for secure [time synchronization](../networking/configuration/time).
This feature enhances the security of NTP by providing cryptographic authentication of time sources.
NTS is enabled by default (without any configuration sources) for the default `time.cloudflare.com` time server.
NTS can be enabled for custom time servers via the new `useNTS` field in the [`TimeSyncConfig`](../reference/configuration/network/timesyncconfig) document.
### DHCP
DHCPv4 search domains are now applied to the resolver configuration.
Setting `searchDomains.domains` in the [`ResolverConfig`](../reference/configuration/network/resolverconfig) document overrides them,
and an empty list (`domains: []`) clears them; leaving the field unset inherits the DHCP and platform search domains.
The [DHCPv4 configuration](../reference/configuration/network/dhcpv4config) now supports the `ignoreRoutes` option to ignore routes provided by DHCPv4 servers.
### HTTP probe support
Talos now supports HTTP network probes via the [`HTTPProbeConfig`](../reference/configuration/network/httpprobeconfig) document, allowing for monitoring of HTTP endpoints.
HTTP responses with status 200-399 are considered successful, while connection and transport errors are treated as failures.
### Flannel CNI
Talos now configures Flannel with the `EnableNFTables` option enabled, which uses the nftables native backend instead of the `iptables-nft` compatibility layer.
## Kubernetes
The following changes affect the Kubernetes control plane components managed by Talos.
### etcd
Talos is now compatible with etcd v3.6.x and later only (the default etcd version has been 3.6.x since Talos v1.11).
The default version is 3.7.0+ now.
etcd now serves its HTTP-only endpoints (`/metrics`, `/health`, the gRPC-gateway JSON API) on a dedicated listener on port `2383`,
while the client port `2379` serves gRPC only.
This keeps gRPC off Go's `net/http` HTTP/2 server, avoiding watch-stream starvation under TLS
(see [etcd-io/etcd#15402](https://github.com/etcd-io/etcd/issues/15402), [golang/go#58804](https://github.com/golang/go/issues/58804),
[etcd-io/etcd#21605](https://github.com/etcd-io/etcd/issues/21605)).
> Upgrade note: etcd metrics and the HTTP health endpoint are no longer reachable on `2379`; scrape them on port `2383` instead (with the same client mTLS as before).
> etcd gRPC clients and the Talos health check are unaffected.
> The firewall might need to be adjusted to block port `2383` if `2379` was previously blocked.
> If `--listen-metrics-urls` was customized, the metrics do not move.
### FlexVolume host path removed
Talos no longer provisions the deprecated FlexVolume executable host path at `/usr/libexec/kubernetes`.
FlexVolume has been deprecated since Kubernetes 1.23.
Modern CSI plugin paths under `/var/lib/kubelet` are unaffected.
## Security
Talos tightens a number of defaults, and protects the contents of support bundles.
### TLS 1.3 minimum version
Talos now runs etcd and kube-apiserver with a minimum TLS version of 1.3, improving security by leveraging the latest TLS features and cipher suites.
Custom settings for cipher suites have been removed, as they are ignored when TLS 1.3 is used, which simplifies configuration and ensures the use of modern, secure defaults.
### ICMP `send_redirects` disabled by default
Talos now sets `net.ipv4.conf.all.send_redirects=0` and `net.ipv4.conf.default.send_redirects=0` by default, preventing the node from emitting ICMP redirect messages.
This aligns with [CIS Benchmark recommendations](../security/talos-default-hardening-and-cis-compliance), and does not affect normal Kubernetes pod or service traffic.
Nodes which deliberately act as L3 gateways relying on ICMP redirects can override this via a [`SysctlConfig`](../reference/configuration/runtime/sysctlconfig) document.
### Support bundle encryption
The [`talosctl support`](../troubleshooting/support-bundle) command now encrypts support bundles using the `age` encryption tool, enhancing the security of support data.
The default set of recipients includes the `siderolabs` GitHub organization members, but it can be overridden with custom recipients.
## Miscellaneous
Other user-visible changes in this release.
### Kernel module status
Talos now reports the status of both dynamically loaded and built-in kernel modules.
The `LoadedKernelModule` resource has been deprecated, and superseded by the new `KernelModuleStatus` resource.
## Component updates
* Linux: 6.18.40
* Kubernetes: 1.37.0
* containerd: 2.3.3
* runc: 1.5.1
* etcd: 3.7.0
* CoreDNS: 1.14.6
* Flannel: 0.28.8
Talos is built with Go 1.26.5.
## Contributors
* Andrey Smirnov
* Noel Georgi
* Mateusz Urbanek
* Maja Bojarska
* Orzelius
* Erwan Leboucher
* Utku Ozdemir
* Kevin Tijssen
* Lukasz Raczylo
* Mickaël Canévet
* Oguz Kilcan
* Dmitrii Sharshakov
* Dmitriy Matrenichev
* Rokoucha
* buckaroo
* immanuwell
* Aleksei Sviridkin
* Ansgar Dahlen
* Artem Chernyshev
* Benoît Knecht
* Calin
* Christian Korneck
* Dario Emerson
* David Orman
* Dharsan Baskar
* Edward Sammut Alessi
* Filip Boye-Kofi
* Fritz Schaal
* Immanuel Tikhonov
* Jaakko Sirén
* Jonny
* Justin Garrison
* Konstantin Nesterov
* Mario Cole
* Mark Glants
* Nico Berlee
* Pranav Patil
* YANG JOO WOONG
* Zadkiel AHARONIAN
* appkins
* kastakhov