Limits of Enabling NodeLocalTimeZone by Default in k3s

Question

The goal is to decide whether k3s should enable the NodeLocalTimeZone feature gate by default, allowing pods to inherit the host’s time zone settings.

As of k3s v1.23.0+k3s1 the feature gate exists but is disabled, leaving containers in UTC unless explicitly turned on. Enabling it simplifies time‑sensitive workloads but raises concerns about security, multi‑tenancy, and the need to restart pods when the host time zone changes.

What trade‑offs should guide the default setting, how can potential risks be mitigated, and what communication strategy would best inform users of any change?

Tasadduq Burney · Answer

AnswerKeep the NodeLocalTimeZone feature gate disabled by default unless you can confirm that your cluster meets the safety conditions outlined below.Confirmed factsThe NodeLocalTimeZone gate exists in k3s v1.23.0+k3s1 and later; it is stable in Kubernetes v1.23.When enabled, k3s mounts the host’s /etc/localtime and /etc/timezone into pods via hostPath (read‑only).The mount works only on Linux nodes; on Windows worker nodes the gate is ignored and pods remain in UTC.Pods do not automatically pick up host timezone changes; they must be restarted to see new /etc/localtime contents.Pods with restrictive security contexts (e.g., readOnlyRootFilesystem: true, dropping all capabilities, or PodSecurity policies that forbid hostPath) cannot access the mounted files and will fall back to UTC or crash.Likely explanation of trade‑offsEnabling the gate by default removes the need for users to manually set feature-gates=NodeLocalTimeZone=true and simplifies deployment of time‑sensitive workloads (e.g., cron jobs, logging agents) because containers inherit the host’s zone automatically. However, it also widens the attack surface (hostPath access), can break applications that assume UTC timestamps, creates multi‑tenant surprises when one node’s zone differs from another, and requires pod restarts whenever the host zone changes.Steps to enable safely (if you decide to change the default)Verify that all worker nodes are Linux and that no PodSecurity Standard or admission controller blocks hostPath for the two specific files.Start the k3s server (and agents) with the feature gate enabled:k3s server --feature-gates=NodeLocalTimeZone=true\Optionally restrict the hostPath mount further via a PodSecurityPolicy or PodSecurity standard that allows hostPath only for /etc/localtime and /etc/timezone.Deploy a daemon (e.g., a node‑level systemd service) that watches /etc/localtime and rolls out a rolling restart of affected pods when the file changes, to avoid stale timezone data.Document the change in release notes and upgrade guides, emphasizing the need to restart pods after a zone change and the Windows‑node limitation.Missing diagnostic detailBefore flipping the default, confirm: Are there any Windows worker nodes or PodSecurity policies that prohibit hostPath mounts? If the answer is yes, keeping the gate disabled by default remains the safer choice.

Limits of Enabling NodeLocalTimeZone by Default in k3s

1 answer

0 question comments

Answer

Confirmed facts

Likely explanation of trade‑offs

Steps to enable safely (if you decide to change the default)

Missing diagnostic detail

Your perspective belongs here.