v1.14.0-beta.0 #13868
smira
announced in
Announcements
v1.14.0-beta.0
#13868
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Talos 1.14.0-beta.0 (2026-07-23)
Welcome to the v1.14.0-beta.0 release of Talos!
This is a pre-release of Talos
Please try out the release binaries and report any issues at
https://github.com/siderolabs/talos/issues.
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-name server basis in the
ResolverConfigdocument, allowing for flexible configuration of DNS resolution.noexec on EPHEMERAL (/var)
Talos 1.14 clusters now default the EPHEMERAL volume (
/var) tonoexecin addition to the existingnosuidandnodevmount options through generated machine configuration.
Existing machines are not affected on upgrades.
Note: Workloads that execute binaries placed under
/varcan break on new machines.Longhorn v1 and vCluster are known to be affected.
For example, Longhorn v1's
instance-managerexecutes engine binaries that theengine-imageDaemonSet places under/var/lib/longhorn/engine-binaries/, which now fails withpermission denied.Affected users can opt out via a
VolumeConfigdocument:Longhorn v2 (SPDK data engine) runs the data plane inside the instance manager process and is not affected.
Apply Configuration Modes
The '--mode=reboot' option has been removed from the
talosctl apply-configcommand; by default, configuration is applied without a reboot.Most configuration changes don't require a reboot; the documentation lists the changes that do.
Native BGP
Talos now supports running a native BGP speaker on the host via an embedded GoBGP, configured with the new
BGPPeerConfigdocument.This removes the need to ship FRR as a system extension for the common fabric-facing use case.
List of changes:
BGPPeerConfigdocument to configure the local ASN, router-id, advertised interfaces (loopbacks originated as host routes), neighbors, and per-route preferred source (routeSource).BGPPeerStatusresource (talosctl get bgppeerstatus).RouteSpec/RouteStatusnow carry a multipath next-hop list to support ECMP and cross-family (RFC 8950) next-hops.Btrfs Support
Talos now supports mounting and provisioning
btrfsfilesystem for user volumes and existing volumes.Support for
btrfsis enabled by installingbtrfssystem extension.CRI Base Runtime Specification Configuration
Talos now supports overriding the default OCI runtime specification for CRI containers with a
CRIBaseRuntimeSpecConfigdocument:The
.machine.baseRuntimeSpecOverridesfield is deprecated and remains supported during the deprecationperiod. 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.
CRI Customization Configuration
Talos now supports customizing the CRI containerd configuration with named
CRICustomizationConfigdocuments. 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.partmachine-file configuration remains supported during thedeprecation period and is exposed under the reserved name
customization. ACRICustomizationConfigdocumentcannot use that name.
NOTE: a machine reboot is no longer required to apply changes to CRI configuration.
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 disabled by default, add the following machine configuration document:
Default Installer Image
The default installer image has been updated to use the Image Factory.
The
ghcr.io/siderolabs/installerimage is no longer published with releases; use the Image Factory installer image instead.DHCP
DHCPv4 search domains are now applied to the resolver configuration.
DHCPv4 configuration now supports
ignoreRoutesoption to ignore routes provided by DHCPv4 servers.Cluster Discovery
Talos introduces support for configuring multiple discovery service endpoints.
Talos introduces new document for configuring the cluster discovery identity.
List of changes:
.cluster.discoveryin the v1alpha1 config; use theDiscoveryServiceConfigdocument for discovery service configuration. The v1alpha1 config andDiscoveryServiceConfigare mutually exclusive..cluster.secretandcluster.idin the v1alpha1 config; use theDiscoveryIdentityConfigdocument for discovery identity configuration. The v1alpha1 config andDiscoveryIdentityConfigare mutually exclusive.base64.URLEncodingtobase64.StdEncoding. This aligns the encoding with the rest of Talos.Encryption Discards
Volume encryption now supports an
allowDiscardsoption (disabled by default) which passes TRIM/discard requeststhrough 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.
etcd
Talos is now compatible with etcd v3.6.x only (the default etcd version was 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 dedicatedlistener on port
2383, while the client port2379serves gRPC only. This keeps gRPC off Go'snet/httpHTTP/2 server, avoiding watch-stream starvation under TLS (see etcd-io/etcd#15402, golang/go#58804,
etcd-io/etcd#21605).
Upgrade note: etcd metrics and the HTTP health endpoint are no longer reachable on
2379; scrape them onport
2383instead (same client mTLS as before). etcd gRPC clients and the Talos health check are unaffected.Firewall might need to be adjusted to block the port
2383if previously2379was blocked.If
--listen-metrics-urlswas customized, the metrics should not move.EtcFileConfig
Talos now supports managing user-owned files under
/etcwith the newEtcFileConfigmulti-documentconfiguration kind. The document
nameis the path relative to/etc, and each document owns the completefile contents and mode.
This can be used to configure files such as
/etc/nfsmount.confor/etc/multipath.conf. Talos-managedpaths, including
resolv.conf,hosts,machine-id, CRI and Kubernetes configuration, trust bundles, andidentity files, are rejected to prevent overriding files owned by Talos.
Filesystem Trim
Talos can now periodically trim (the equivalent of the
fstrimcommand) mounted filesystems which support trimming,discarding unused blocks. This is useful for SSDs and thin-provisioned storage.
Trimming is opt-in via a new
FilesystemTrimConfigdocument which sets the global trim interval:The default machine configuration for Talos 1.14+ includes a
FilesystemTrimConfigdocument with a default trim interval of one week,so trimming is enabled by default for eligible filesystems. For cluster which were upgraded from older versions, the
FilesystemTrimConfigdocument will be missing,so trimming will be disabled by default until the document is added.
When the document is present, Talos builds a stable schedule (hashed by node ID and volume ID, so 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
allowDiscardsis set).The trim interval can be overridden or disabled per-volume via a
trimblock on the volume documents(
VolumeConfig,UserVolumeConfig,ExistingVolumeConfig,ExternalVolumeConfig):Flannel CNI
Talos now configures Flannel with the
EnableNFTablesoption enabled, which uses nftables native backend instead ofiptables-nftcompatibility layer.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/kubeletare unaffected.Host DNS Configuration
HostDNS configuration was moved from the v1alpha1 config
.machine.features.hostDNSfield to the newhostDNSin theResolverConfigdocument.HTTP Probe Support
Talos now supports HTTP network probes, allowing for monitoring of HTTP endpoints.
HTTP responses with status 200-399 are considered successful, while connection and transport errors are treated as failures.
Image Cache Configuration
Talos now supports a new
ImageCacheConfigdocument for configuring the Image Cache feature, replacing the oldmachine.features.imageCachefield in the v1alpha1 config.Old configuration is still supported for backwards compatibility.
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:
.machine.sysctlsin the v1alpha1 config; use theSysctlConfigdocument for kernel sysctl configuration..machine.sysfsin the v1alpha1 config; use theSysfsConfigdocument for sysfs configuration..machine.kernelin the v1alpha1 config; use theKernelModuleConfigdocument for kernel module configuration.Kernel Module Status
Talos now reports the status of both dynamically loaded, and built-in kernel modules.
The
LoadedKernelModuleresource has been deprecated and superseded by the newKernelModuleStatusresource.In-tree Volume Plugins Deprecated
Because the kubelet now runs inside the sandbox namespace (see the workload isolation note), the in-tree
Kubernetes volume plugins that require the kubelet to reach host-level daemons no longer work. In particular
the in-tree
iscsivolume plugin, which drives the kubelet'siscsiadmwrapper to talk to the hostiscsid,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(ordemocratic-csi) consumes atarget 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.
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-proxyis now using configuration to manage its settings instead of command line arguments (with newKubeProxyConfigdocument).List of changes:
.cluster.secretboxEncryptionSecretin the v1alpha1 config; use theKubeEtcdEncryptionConfigdocument for full etcd encryption configuration..cluster.apiServerin the v1alpha1 config; use theKubeAPIServerConfig,KubeAdmissionControlConfig,KubeAuditPolicyConfig,KubeAuthenticationConfigandKubeAuthorizerConfigdocuments for kube-apiserver configuration..cluster.ca,.cluster.acceptedCAsand.cluster.aggregatorCAin the v1alpha1 config; use theKubeAPIServerCAConfig,KubeAggregatorCAConfigdocuments..cluster.controllerManagerin the v1alpha1 config; use theKubeControllerManagerConfigdocument for kube-controller-manager configuration..cluster.schedulerin the v1alpha1 config; use theKubeSchedulerConfigdocument for kube-scheduler configuration..cluster.proxyin the v1alpha1 config; use theKubeProxyConfigdocument for kube-proxy configuration..cluster.networkin the v1alpha1 config; use theKubeNetworkConfigdocument for Kubernetes network configuration; Flannel can be configured using theKubeFlannelCNIConfigdocument..cluster.coreDNSin the v1alpha1 config; use theKubeCoreDNSConfigdocument for CoreDNS configuration..cluster.nameand.cluster.controlPlane.endpoint in the v1alpha1 config; use theKubeClusterConfig` document for cluster name and control plane endpoint configuration..cluster.allowSchedulingOnControlPlanes.machine.kubelet.skipNodeRegistration.machine.kubelet.registerWithFQDN.machine.kubelet.nodeIP.machine.nodeLabels.machine.nodeAnnotations.machine.nodeTaintsNoScheduletaint for controlplane and label are now explicitly listed inKubeNodeConfig..machine.kubeletfields in the v1alpha1 config; use theKubeNodeConfigandKubeCredentialProviderConfigdocuments for kubelet configuration..machine.podsin the v1alpha1 config; use theKubeStaticPodConfigdocument for static pod configuration..machine.filesin the v1alpha1 config; use dedicated configuration documents such asEtcFileConfigandCRICustomizationConfiginstead..machine.baseRuntimeSpecOverridesin the v1alpha1 config; use theCRIBaseRuntimeSpecConfigdocument for base runtimespec overrides..cluster.inlineManifestsin the v1alpha1 config; use theKubeInlineManifestConfigdocument for inline manifests..cluster.extraManifestsand.cluster.extraManifestHeadersin the v1alpha1 config; use theKubeExternalManifestConfigdocument for external manifests..machine.features.kubePrism; use theKubePrismConfigdocument for KubePrism configuration (or remove it to disable KubePrism).nodeCIDRMaskSizeIPv4(default24) andnodeCIDRMaskSizeIPv6(default64) settings to theKubeNetworkConfigdocument to control the per-node pod CIDR mask size and validate the pod and service subnet sizes.LVM Logical Volume Creation
Logical volumes can now be declared with a new
LVMLogicalVolumeConfigmulti-doc config kind. Each documentnames a logical volume, its parent
volumeGroup, atype(linear,raid0,raid1orraid10) and amaxSize(absolute, e.g.50GiB, or a percentage of the volume group, e.g.80%). RAID layouts acceptoptional
mirrors(raid1/raid10, default 1) andstripes(raid0/raid10, default: all available physicalvolumes) fields. Once the volume group is assembled the logical volume is created via
lvcreate.Raising
maxSizegrows an existing logical volume vialvextend; percentage-sized volumes also grow whentheir volume group is extended. Shrinking is never performed (it risks data loss) - a request to reduce the
size surfaces an
LVMValidationErrorinstead. Removal stays an explicit operation via the LVMService LVremove RPC (
talosctl wipe lv).LVM Status
Talos now provides detailed LVM status information, allowing for better monitoring and management of LVM volumes.
New resources
LVMPhysicalVolumeStatus,LVMVolumeGroupStatus, andLVMLogicalVolumeStatusexpose PV, VG, and LV details.DiscoveredVolumeresources for logical volumes are listed by their kernel name (e.g.dm-0). To resolve the<vg>/<lv>for a given device, use theDisksorBlockSymlinksresources, which carry the udev-managed symlinks (e.g./dev/disk/by-id/dm-name-<vg>-<lv>).LVM Volume Group Creation
Talos can now create and grow LVM Volume Groups declaratively through a new
LVMVolumeGroupConfigmulti-docconfig kind. Each document names a Volume Group and a CEL
volumeSelectorover the disk inventory; matcheddisks are initialised 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 Wipe
Talos now provides the ability to securely wipe LVM metadata from logical volumes, volume groups, and physical volumes.
This feature allows for selective wiping of logical volumes, volume groups, and physical volumes.
With
talosctl wipe lv/vg/pv <name>, users can wipe LVM metadata from a specific logical volume, volume group, or physical volume.NTS for Time Synchronization
Talos now supports Network Time Security (NTS) for secure time synchronization.
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.comtime serverNTS can be enabled for custom time servers via the new
useNTSfield in theTimeServerConfigdocument.RAID Array Creation
Talos can now create and grow Linux MD (software RAID) arrays declaratively through a new
RAIDArrayConfigmulti-doc config kind. Each document names an array, its
level(raid1) and a CELvolumeSelectoroverthe disk inventory; matched disks are assembled into the requested array with
mdadmand exposed at the stable/dev/disk/by-id/md-name-<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 <device>. The newMDArrayStatusresource reports theassembled 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
RAIDArrayConfigfor thearray and point the install disk selector (
UnattendedInstallConfig) at the resulting/dev/disk/by-id/md-name-<name>device.
Only
raid1arrays withmetadata: "1.0"can be used for booting: the 1.0 format keeps its superblock at the end ofeach 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.
metadatadefaults to1.0; other levels and metadata formats are not bootable.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
sandboxdservice, instead of sharingmachined's namespaces.sandboxdruns in its own least-privilege SELinux domain (sandboxd_t). if it dies the kernel tears down thenamespace 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
workloadIsolationfield of the newSecurityProfileConfigdocument.talosctl gen configemits it withworkloadIsolation: truefor Talos 1.14+, so new clusters are isolated bydefault. 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 on an existing
cluster, add the document:
ICMP send_redirects Disabled by Default
Talos now sets
net.ipv4.conf.all.send_redirects=0andnet.ipv4.conf.default.send_redirects=0by default,preventing the node from emitting ICMP redirect messages. This aligns with CIS Benchmark recommendations and
does not affect normal Kubernetes pod or service traffic. Nodes that deliberately act as L3 gateways relying
on ICMP redirects can override this via
machine.sysctls.Support Bundle Encryption
The
talosctl supportcommand 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.
Dedicated System Volumes
The
ETCD,CRI,KUBELETandLOGsystem volumes (/var/lib/etcd,/var/lib/containerd,/var/lib/kubeletand/var/log) can now be placed on dedicated partitions via aVolumeConfigdocument withprovisioningset (optionally encrypted). By default they remain directories under theEPHEMERALvolume.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.secureoption (nosuid/noexec/nodev, enabled by default) can be set per volume; directory-backed volumes inherit theEPHEMERALmount options.Note that with
ETCDon a dedicated partition, etcd data no longer lives underEPHEMERAL. Resetting a control plane node with only theEPHEMERALpartition wiped will not clear etcd data; wipe theETCDvolume to reset etcd.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.
Udev Rules Multi-document Configuration
Talos introduces new multi-document configuration
UdevRulesConfigdocument for configuring custom udev rules.The old v1alpha1
.machine.udev.rulesfield is still supported for backwards compatibility, but new deployments should use the new document.If both old and new configuration sources are used,
UdevRulesConfigtakes precedence.List of changes:
.machine.udev.rulesin the v1alpha1 config; use theUdevRulesConfigdocument for custom udev rules.Unattended Install Configuration
Talos introduces a new
UnattendedInstallmulti-document config kind which replaces the deprecated.machine.installsection of the v1alpha1 config. The document carries the installer
imageand aprovisioningsection with a CELvolumeSelectorto match the install disk, plus awipeoption.When the
UnattendedInstalldocument is present, the install is driven by the newUnattendedInstallController(exposing an
UnattendedInstallStatusresource) instead of the legacy install sequence.talosctl gen configandtalosctl cluster createnow generate theUnattendedInstalldocument by default.The
.machine.installfield remains supported for backwards compatibility and is still used for older version contracts.Component Updates
Linux: 6.18.39
Kubernetes: 1.37.0-beta.0
containerd: 2.3.3
etcd: v3.7.0
Flannel: 0.28.8
runc: 1.5.1
CoreDNS: 1.14.6
Talos is built with Go 1.26.5.
XFS Allocation Group Geometry
On non-rotational devices
mkfs.xfssizes the allocation group count to the number of CPUs, bounding theallocation 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
ENOSPCon reflink-heavy workloads while the filesystem still has plenty of free space) and inflates thejournal 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.xfsbehavior:The same
filesystem.xfs.minAllocationGroupSizesetting is available forUserVolumeConfig.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).Contributors
Changes
448 commits
KubeletConfigKubeNodeConfignoexecfor EPHEMERAL only for new machinesworkflow_runChanges since v1.14.0-alpha.2
116 commits
KubeletConfigKubeNodeConfignoexecfor EPHEMERAL only for new machinesChanges from siderolabs/gen
1 commit
Changes from siderolabs/go-adv
2 commits
Changes from siderolabs/go-cmd
2 commits
Changes from siderolabs/go-kmsg
1 commit
Changes from siderolabs/go-kubeconfig
2 commits
Changes from siderolabs/go-kubernetes
7 commits
Changes from siderolabs/go-smbios
1 commit
Changes from siderolabs/go-talos-support
2 commits
Changes from siderolabs/grpc-proxy
3 commits
Changes from siderolabs/pkgs
115 commits
Changes from siderolabs/proto-codec
1 commit
Changes from siderolabs/siderolink
1 commit
Changes from siderolabs/tools
27 commits
Dependency Changes
Previous release can be found at v1.13.0
Images
This discussion was created from the release v1.14.0-beta.0.
All reactions