K3s — Dependencies#

Module info#

• Module: github.com/k3s-io/k3s
• Go version: 1.25.7
• Direct dependencies: ~100 (first require block, lines 77–176)
• Indirect dependencies: ~347 (two additional require blocks marked // indirect)
• go.sum entries: ~966 unique module+version pairs (1,933 lines / 2)
• replace directives: 73 — the most architecturally distinctive feature of this go.mod

Dependency categories#

Core infrastructure#

Kubernetes / CNCF ecosystem#

This is the dominant category by count. All k8s.io/* packages are redirected via replace to github.com/k3s-io/kubernetes/staging/src/k8s.io/* at v1.35.3-k3s1.

Container runtime / OCI#

Networking / HTTP#

Data / Storage#

Rancher ecosystem#

K3s carries a strong dependency on the Rancher controller framework. These packages form K3s’s “controller layer”.

P2P image distribution (Spegel)#

Observability#

Testing#

Other notable#

Stdlib reliance#

K3s uses the stdlib heavily and directly — it is not a pure library project. The most-used stdlib packages, evidenced across key source files:

• context — pervasive; every significant operation is context-aware for cancellation
• net, net/http, net/url — direct HTTP/TCP server and client code throughout
• crypto/tls, crypto/x509, crypto/rand — PKI operations for mTLS everywhere (certificates managed by dynamiclistener)
• os, path/filepath — extensive filesystem operations for config, certs, data dirs
• sync — sync.WaitGroup, sync.Mutex used directly; not hidden behind frameworks
• encoding/json, encoding/pem, encoding/hex — serialization at API and cert boundaries
• fmt, strings, strconv — standard string/format utilities
• io, bufio — streaming I/O for config reading and HTTP responses
• time — timeouts, intervals, retries throughout

Third-party packages are used where the stdlib is insufficient: gRPC (not in stdlib), Flannel (CNI), etcd (distributed storage), libp2p (P2P networking). The pattern is: stdlib for control flow and I/O, third-party for protocol-level heavy lifting.

Shared dependencies#

Dependencies shared with other projects in the 50-project analysis set, creating cross-project connection points:

Vendoring#

K3s does not vendor. There is no vendor/ directory in the repository. All dependencies are resolved via the Go module proxy and Go toolchain at build time.

The trade-off is managed differently: instead of vendoring, K3s uses an extensive set of replace directives (73 total) to pin all critical dependencies to specific forks maintained under github.com/k3s-io/*. This achieves reproducibility and patch control without the storage overhead of vendoring — particularly important given the scale of the k8s dependency tree (hundreds of packages).

The build system uses go build with Go modules and likely a GOFLAGS or -mod=mod equivalent to ensure reproducible builds from the module cache.

Notable dependency decisions#

1. replace directives as the patching mechanism — K3s’s entire downstream maintenance strategy is encoded in go.mod. All 28 k8s.io/* packages are redirected to github.com/k3s-io/kubernetes/staging/src/k8s.io/* at v1.35.3-k3s1. Similarly, etcd (7 packages), containerd (1), klog (2), and several other critical libraries point to K3s-maintained forks. This is the canonical example of “distribution engineering” in the Go module system: maintaining a large upstream dependency tree with surgical patches.

2. Kine over etcd — Rather than depending on the full etcd distribution, K3s developed github.com/k3s-io/kine as a compatibility shim. This enables SQLite (default), MySQL, MariaDB, Postgres, and NATS as alternative backends via a single dependency that speaks the etcd gRPC protocol. The actual etcd is still available for HA deployments and is also embedded, making K3s dual-mode: Kine for single-node, real etcd for multi-node HA.

3. libp2p for image distribution — The inclusion of github.com/libp2p/go-libp2p (and its ~10 transitive sub-packages) for Spegel is architecturally unusual. This brings a substantial P2P networking stack into what is otherwise a traditional client-server system, purely to enable cluster-local OCI registry mirroring without a central service.

4. Rancher controller framework instead of controller-runtime — K3s uses rancher/wrangler/v3 and rancher/lasso rather than sigs.k8s.io/controller-runtime (the standard controller framework used by most operators). This is a significant divergence: Wrangler is Rancher-internal and generates typed informers and appliers rather than using the unstructured client approach of controller-runtime. It reflects K3s’s Rancher heritage.

5. Two logging frameworks in parallel — github.com/sirupsen/logrus (K3s’s own code) coexists with go.uber.org/zap (required by embedded etcd). This is a common artifact of bundling upstream components with different logging preferences.

6. Prometheus client pinned via replace — Unlike most projects which simply use the latest Prometheus client, K3s pins prometheus/client_golang and prometheus/common via replace directives. This is likely because the embedded Kubernetes components have version conflicts that require a specific pinned version across the entire binary.

7. Pion WebRTC as transitive dep — The pion/* packages (datachannel, dtls, ice, webrtc, stun, etc.) appear as indirect deps, pulled in by libp2p’s QUIC/WebTransport transports for NAT traversal in Spegel’s P2P networking. This is an example of a relatively exotic dependency appearing from a single architectural choice (Spegel integration).