K3s

The k3s lexicon declares the files k3s itself consumes: config.yaml for k3s server / k3s agent, and registries.yaml for the embedded containerd. The emitted files are exactly what the native tool accepts — drop them at /etc/rancher/k3s/ (or pass --config) and chant is nowhere in sight. That walk-away property is the reason this is a lexicon at all.

npm install --save-dev @intentius/chant @intentius/chant-lexicon-k3s

chant.config.ts

export default {
  lexicons: ["k3s"],
};

A two-node cluster

import { Agent, Server } from "@intentius/chant-lexicon-k3s";

export const controlPlane = new Server({
  "cluster-init": true,
  "tls-san": ["10.0.0.10", "cp.example.internal"],
  "write-kubeconfig-mode": "0600",
});

export const worker = new Agent({
  server: "https://cp.example.internal:6443",
  "token-file": "/etc/rancher/k3s/agent-token",
});

The token boundary

There is no token property, on purpose. The join secret reaches a node as a file (token-file, agent-token-file) or as K3S_TOKEN / K3S_TOKEN_FILE in the installer’s environment — never as a value in source. A literal that arrives through raw props anyway fails K3S001 at lint and K3S101 at build; the same wall covers the etcd S3 snapshot credentials (etcd-s3-config-secret is the reference form upstream provides).

Relationship to k3d

The k3d lexicon declares a k3d-managed cluster — k3s wrapped in Docker, config consumed by the k3d CLI. This lexicon declares k3s on real hosts: Lima VMs, bare metal, cloud instances. The acceptance test for both is the same idea — the native tool consuming the emitted file is the proof.

At a Glance

Metric	Count
Resources	3
Property types	4
Services	3
Intrinsic functions	0
Pseudo-parameters	0
Lint rules	8

Lexicon version: 0.57.0
Namespace: K3s

• All Rules — 8 rules
• Serialization — output format details