A 911 cluster node has significant clock skew and begins failing TLS authentication to the API server. What should administrators suspect?
Select an answer to reveal the explanation.
Short Explanation
Certificates are sticklers for the clock. If the node’s watch is hours off, TLS handshakes to the API server fall apart.
Full Explanation
When a 911 cluster node has significant clock skew and begins failing TLS authentication to the API server, administrators should suspect that time sync problems can invalidate certificate validity windows and produce TLS/auth errors. Certificates are sticklers for the clock—if the node’s watch is hours off, handshakes to apiserver fall apart for emergency workloads.
Clock skew does not only affect horizontal pod autoscaler math and never TLS. It does not always delete ServiceAccounts in the default namespace. It does not only change ContainerRuntimeVersion labels.
Exam caveat: NotBefore/NotAfter failures in kubelet logs are classic skew symptoms. Fix chrony/NTP before rotating certificates unnecessarily, and verify both node and control-plane clocks.
Operational check: compare node time to control-plane time, repair NTP/chrony, restart kubelet if needed, and confirm TLS authentication to apiserver succeeds for the 911 node. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.