From Talos v1.14 the Kubernetes settings live in documents of their own: KubeletConfig, KubeAPIServerConfig, KubeClusterConfig and siblings. The shipped charts still write the v1alpha1 shape (machine.kubelet, machine.nodeLabels, cluster.clusterName), and machinery rejects a config that carries both. So a render against a v1.14 contract cannot succeed, and both presets are pinned at or below v1.13:
templateOptions:
talosVersion: "v1.13" # generic
talosVersion: "v1.12" # cozystack
checkSupersededFields stops such a render with a hint naming the fields, which is the right behaviour for now, but it means talm tracks v1.14 machinery while nothing can target the v1.14 contract.
Teaching the charts to emit the typed documents lifts that ceiling. It is not a mechanical rename: a chart-emitted KubeletConfig replaces the bundle's rather than merging with it, and the bundle's copy is the one carrying image, so a chart that emits the document without the image produces a config machinery rejects at apply time rather than at render time.
From Talos v1.14 the Kubernetes settings live in documents of their own:
KubeletConfig,KubeAPIServerConfig,KubeClusterConfigand siblings. The shipped charts still write the v1alpha1 shape (machine.kubelet,machine.nodeLabels,cluster.clusterName), and machinery rejects a config that carries both. So a render against a v1.14 contract cannot succeed, and both presets are pinned at or belowv1.13:checkSupersededFieldsstops such a render with a hint naming the fields, which is the right behaviour for now, but it means talm tracks v1.14 machinery while nothing can target the v1.14 contract.Teaching the charts to emit the typed documents lifts that ceiling. It is not a mechanical rename: a chart-emitted
KubeletConfigreplaces the bundle's rather than merging with it, and the bundle's copy is the one carryingimage, so a chart that emits the document without the image produces a config machinery rejects at apply time rather than at render time.