k3s
The k3s lightweight CNCF-certified Kubernetes distribution shipped as a single binary that bundles containerd, flannel, CoreDNS, Traefik, ServiceLB (Klipper), local-path-provisioner, and metrics-server. Use when installing or running a lightweight Kubernetes cluster, bootstrapping a single-node or HA k3s control plane, joining agent (worker) nodes, choosing embedded etcd vs an external SQL datastore, managing cluster/agent tokens, rotating certificates, taking or restoring etcd snapshots, enabling secrets encryption, doing airgap or private-registry installs, disabling bundled components (Traefik/ServiceLB/CoreDNS), or upgrading k3s. Triggers on mentions of k3s, `k3s server`, `k3s agent`, the `curl -sfL https://get.k3s.io | sh -` installer, `/etc/rancher/k3s/`, or Rancher's lightweight Kubernetes. This is the k3s CLI/distribution, NOT generic Kubernetes/kubectl.
What this skill does
# k3s - Lightweight Kubernetes Distribution
## Overview
k3s is a fully CNCF-certified Kubernetes distribution packaged as a **single self-contained binary** (≈70 MB). One executable is the control plane, the kubelet, the container runtime supervisor, and a multicall wrapper for `kubectl`/`crictl`/`ctr`. You run `k3s server` to start a control-plane node and `k3s agent` to start a worker; everything else (etcd or SQLite, networking, DNS, ingress, load balancing, storage) is bundled and started for you.
**What k3s bundles (and manages for you):**
- **containerd** — the embedded CRI runtime (no Docker needed; `--docker` to opt into cri-dockerd is deprecated)
- **flannel** — the default CNI (`--flannel-backend`: `vxlan` default, `host-gw`, `wireguard-native`, or `none`)
- **CoreDNS** — cluster DNS (deployed component `coredns`)
- **Traefik** — ingress controller (deployed component `traefik`)
- **ServiceLB / Klipper** — a built-in `LoadBalancer` service implementation (component `servicelb`)
- **local-path-provisioner** — default `local-path` StorageClass (component `local-storage`)
- **metrics-server** — resource metrics (component `metrics-server`)
- **SQLite by default**, with **embedded etcd** (for HA) or an **external datastore** (MySQL/Postgres/etcd/NATS) as alternatives
**Key characteristics:**
- **Single binary, single process tree** — `k3s server`/`k3s agent` supervise all components
- **Batteries-included** — a working cluster (ingress, LB, DNS, storage) right after install
- **Config in one place** — `/etc/rancher/k3s/`: `config.yaml`, `k3s.yaml` (kubeconfig), `registries.yaml`
- **Easy to slim down** — `--disable` any bundled component to bring your own
> **Disambiguation:** This skill is about the **k3s distribution and its `k3s` CLI** — installation, the `server`/`agent` lifecycle, bundled components, tokens, etcd snapshots, certs. It does **not** teach generic Kubernetes or `kubectl` usage; for that, use Kubernetes documentation. Anything k3s-specific (what it adds, bundles, or changes) belongs here.
## When to Use This Skill
Use this skill when:
- **Installing k3s**: the `curl -sfL https://get.k3s.io | sh -` installer and `INSTALL_K3S_*` env vars
- **Bootstrapping a cluster**: single-server, HA with embedded etcd, or an external datastore
- **Joining nodes**: agents (workers) or additional servers via `K3S_URL` + `K3S_TOKEN`
- **Slimming the stack**: `--disable traefik`, `--disable servicelb`, `--flannel-backend=none`, etc.
- **Day-2 operations**: etcd snapshots, certificate rotation, secrets encryption, token rotation
- **Restricted environments**: airgap installs, private/mirror registries (`registries.yaml`)
- **Remote API access**: adding SANs (`--tls-san`) and a readable kubeconfig (`--write-kubeconfig-mode`)
- **Upgrading / uninstalling**: re-running the installer, channels, the bundled uninstall scripts
## Prerequisites
**CRITICAL**: Before proceeding, verify k3s is installed and check the version:
```bash
k3s --version # prints e.g. "k3s version v1.32.1+k3s1 (…)"
```
**Version note:** This skill is documented against the k3s source at **v1.35.0+k3s1**. Long-standing flags and paths work on any recent k3s; features added in a specific release are annotated inline as `(k3s vX.Y+)`. The "Since" marker is the **first minor cycle** a feature shipped in (k3s backports features to all supported minor lines, so an older patch release may also have it). Always confirm flags on the running version with `k3s server --help` / `k3s agent --help`.
**If k3s is not installed:** do **NOT** silently auto-install on someone's machine. k3s installs a systemd service and modifies the host — confirm intent first, then use the official installer (see [Install](#install)). The canonical install is:
```bash
curl -sfL https://get.k3s.io | sh -
```
**Where things live (memorize these):**
| Path | What |
|------|------|
| `/etc/rancher/k3s/k3s.yaml` | Admin kubeconfig written by the server (root-owned `0600` by default) |
| `/etc/rancher/k3s/config.yaml` | Server/agent config file (see [Configuration File](#configuration-file)) |
| `/etc/rancher/k3s/registries.yaml` | Private/mirror registry config |
| `/var/lib/rancher/k3s` | Data dir (`--data-dir`/`-d`); `${HOME}/.rancher/k3s` when run non-root |
| `/var/lib/rancher/k3s/server/db/` | Datastore (SQLite/etcd) |
| `/var/lib/rancher/k3s/server/db/snapshots/` | Default etcd snapshot directory |
| `/var/lib/rancher/k3s/server/node-token` | Token agents use to join (read on the first server) |
## Install
The installer script detects systemd/openrc, installs the binary, writes a service, and starts it. Configure it entirely through **environment variables** (set them before the pipe):
```bash
# Latest stable, server (control-plane) node — default behavior
curl -sfL https://get.k3s.io | sh -
# Pin a channel or exact version
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest sh -
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.32.1+k3s1 sh -
# Pass server flags through INSTALL_K3S_EXEC
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik --tls-san k8s.example.com" sh -
# Install an AGENT and join an existing server
curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=<node-token> sh -
```
**Key installer variables** (all verified in `install.sh`):
| Variable | Purpose |
|----------|---------|
| `INSTALL_K3S_EXEC` | Args/subcommand passed to the k3s service (e.g. `server --disable traefik`) |
| `INSTALL_K3S_CHANNEL` | Release channel: `stable` (default), `latest`, `testing` |
| `INSTALL_K3S_VERSION` | Exact version to install (e.g. `v1.32.1+k3s1`) |
| `INSTALL_K3S_SKIP_DOWNLOAD` | `true` = don't fetch the binary (airgap — you stage it yourself) |
| `INSTALL_K3S_SKIP_START` | `true` = install but don't start the service |
| `INSTALL_K3S_SKIP_ENABLE` | `true` = don't enable the service at boot |
| `INSTALL_K3S_BIN_DIR` | Install dir for the binary, links, and uninstall script |
| `INSTALL_K3S_SYMLINK` | `skip` to avoid the `kubectl`/`crictl`/`ctr` symlinks |
| `INSTALL_K3S_NAME` | Suffix for the service name (run multiple k3s instances) |
`K3S_URL` + `K3S_TOKEN` make the installer set up an **agent** by default; without `K3S_URL` it installs a **server**.
> The installer also creates uninstall scripts: **`/usr/local/bin/k3s-uninstall.sh`** (server) and **`/usr/local/bin/k3s-agent-uninstall.sh`** (agent). See [recipes.md](references/recipes.md#uninstall) for upgrade and uninstall flows.
## The `k3s` Binary: Subcommand Map
`k3s` is a multicall binary — symlinks named `kubectl`/`crictl`/`ctr` invoke those passthroughs directly.
| Subcommand | Purpose |
|------------|---------|
| `k3s server` | Run a control-plane node (also runs an agent unless `--disable-agent`) |
| `k3s agent` | Run a worker node; needs `K3S_URL` + a token |
| `k3s kubectl` | Bundled kubectl (args forwarded verbatim) |
| `k3s crictl` | Bundled crictl (CRI debugging) |
| `k3s ctr` | Bundled containerd `ctr` |
| `k3s token` | Manage join tokens: `create`, `delete`, `generate`, `list`, `rotate` |
| `k3s etcd-snapshot` | Manage embedded-etcd snapshots: `save`, `ls`, `delete`, `prune` |
| `k3s secrets-encrypt` | Secrets-at-rest encryption: `status`, `enable`, `disable`, `prepare`, `rotate`, `reencrypt`, `rotate-keys` |
| `k3s certificate` | Component certs: `check`, `rotate`, `rotate-ca` |
| `k3s check-config` | Validate the host's kernel/config for k3s |
| `k3s completion` | Shell completion (`bash`/`zsh`, `-i` to install) |
Global flags on the root app: `--debug` (env `K3S_DEBUG`) and `--data-dir`/`-d` (env `K3S_DATA_DIR`).
## Core Workflows
### 1. Single-server cluster + get the kubeconfig
```bash
# Start a server (the installer does this; here's the equivalent direct invocation)
k3s server
# The admin kubeconfig is written here:
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
k3s kubectl get nodes
```
The kubeconfig is root-owned `0600` by default. To make it readable byRelated in Backend & APIs
jfrog
IncludedInteract with the JFrog Platform via the JFrog CLI and REST/GraphQL APIs. Use this skill when the user wants to manage Artifactory repositories, upload or download artifacts, manage builds, configure permissions, manage users and groups, work with access tokens, configure JFrog CLI servers, search artifacts, manage properties, set up replication, manage JFrog Projects, run security audits or scans, look up CVE details, query exposures scan results from JFrog Advanced Security, manage release bundles and lifecycle operations, aggregate or export platform data, or perform any JFrog Platform administration task. Also use when the user mentions jf, jfrog, artifactory, xray, distribution, evidence, apptrust, onemodel, graphql, workers, mission control, curation, advanced security, exposures, or any JFrog product name.
cupynumeric-migration-readiness
IncludedPre-migration readiness assessor for porting NumPy to cuPyNumeric. Use BEFORE substantial porting work begins when the user asks whether code will scale on GPU, whether they should migrate to cuPyNumeric, which NumPy patterns transfer cleanly, what must be refactored before porting, or mentions pre-port assessment, scaling analysis, or refactor planning. Inspect the user's source code, look up NumPy usage, cross-reference the cuPyNumeric API support manifest, and distinguish distributed-scaling-friendly patterns from blockers such as unsupported APIs, scalar synchronization, host round-trips, Python/object-heavy control flow, shape/data-dependent branching, and in-place mutation hazards. Produce a verdict of READY, LIGHT REFACTOR, SIGNIFICANT REFACTOR, or NOT RECOMMENDED, with concrete refactor pointers.
alibabacloud-data-agent-skill
IncludedInvoke Alibaba Cloud Apsara Data Agent for Analytics via CLI to perform natural language-driven data analysis on enterprise databases. Data Agent for Analytics is an intelligent data analysis agent developed by Alibaba Cloud Database team for enterprise users. It automatically completes requirement analysis, data understanding, analysis insights, and report generation based on natural language descriptions. This tool supports: discovering data resources (instances/databases/tables) managed in DMS, initiating query or deep analysis sessions, real-time progress tracking, and retrieving analysis conclusions and generated reports. Use this Skill when users need to query databases, analyze data trends, generate data reports, ask questions in natural language, or mention "Data Agent", "data analysis", "database query", "SQL analysis", "data insights".
token-optimizer
IncludedReduce OpenClaw token usage and API costs through smart model routing, heartbeat optimization, budget tracking, and native 2026.2.15 features (session pruning, bootstrap size limits, cache TTL alignment). Use when token costs are high, API rate limits are being hit, or hosting multiple agents at scale. The 4 executable scripts (context_optimizer, model_router, heartbeat_optimizer, token_tracker) are local-only — no network requests, no subprocess calls, no system modifications. Reference files (PROVIDERS.md, config-patches.json) document optional multi-provider strategies that require external API keys and network access if you choose to use them. See SECURITY.md for full breakdown.
resend-cli
IncludedUse this skill when the task is specifically about operating Resend from an AI agent, terminal session, or CI job via the official resend CLI: installing/authenticating the CLI, sending/listing/updating/cancelling emails, batch sends, domains and DNS, webhooks and local listeners, inbound receiving, contacts, topics, segments, broadcasts, templates, API keys, profiles, or debugging Resend CLI/API failures. Trigger on mentions of Resend CLI, `resend`, `resend doctor`, `resend emails send`, `resend domains`, `resend webhooks listen`, `resend emails receiving`, or agent-friendly terminal automation.
alibabacloud-odps-maxframe-coding
IncludedUse this skill for MaxFrame SDK development and documentation navigation on Alibaba Cloud MaxCompute (ODPS). Helps answer MaxFrame API, concept, official example, and supported pandas API questions; create data processing programs; read/write MaxCompute tables; debug jobs (remote or local); and build custom DPE runtime images. Trigger when users mention MaxFrame, MaxCompute with MaxFrame, ODPS table processing, DPE runtime, MaxFrame docs/examples, DataFrame/Tensor operations, or GPU runtime setup. Works for both English and Chinese queries about Alibaba Cloud data processing with MaxFrame.