feat(k8s): index Kubernetes manifests and Kustomize overlays as graph nodes

[halindrome]

Summary

Add first-class indexing support for Kubernetes manifests and Kustomize overlay files, so that teams managing infrastructure-as-code with Kustomize can navigate their cluster configuration the same way they navigate application source code.

The Problem

Kubernetes-heavy repositories contain hundreds of YAML manifests and Kustomize overlays that encode meaningful relationships — a kustomization.yaml references base layers, patches, and resource files; each manifest declares a kind/metadata.name resource. Today, codebase-memory-mcp indexes those files as opaque YAML blobs with no structural knowledge of what they declare or depend on. A developer asking "what does this overlay include?" or "which manifests define a Deployment?" gets no graph signal.

Why Kustomize Specifically

Kustomize is deeply embedded in the Kubernetes ecosystem:

• 332,000 kustomization.yaml files indexed on GitHub (code search, March 2026) — a direct measure of files this feature would unlock.
• Built into kubectl since v1.14 (March 2019) — every cluster operator has had it available for 7 years without installing anything extra.
• ~12,000 GitHub stars, 2,400+ forks, 280+ releases on kubernetes-sigs/kustomize, with the latest release (v5.8.1) in February 2026.
• 2,475+ repositories use the setup-kustomize GitHub Action in CI — a conservative floor for active pipeline adoption.
• Argo CD (the leading GitOps tool, ~22k stars, ~60% GitOps market share) lists Kustomize as a first-class application source alongside Helm.
• Flux v2's entire reconciliation engine (fluxcd/kustomize-controller) is built on Kustomize — every Flux-managed cluster uses it.
• Kubeflow (CNCF incubating) uses Kustomize as its sole installation mechanism.
• CNCF Annual Survey 2023/2024: Kustomize consistently places second behind Helm as the preferred Kubernetes configuration management tool (15–14% as primary, but widely used alongside Helm in practice — the survey is single-select and undercounts combined usage).

Teams using GitOps patterns typically have repositories where Kustomize overlays are the dependency graph of their infrastructure. Indexing those relationships makes codebase-memory-mcp useful for the cluster configuration layer, not just the application layer.

Proposed Graph Model

File type	Node label	Name format	Edges
kustomization.yaml	Module	file path	IMPORTS → each entry in resources:, bases:, patches:, components:
K8s manifest (any .yaml with apiVersion:)	Resource	Kind/metadata.name	DEFINES ← containing file

Detection uses name-based matching for Kustomize (kustomization.yaml / kustomization.yml) and a content heuristic (apiVersion: in the first 4 KB) for generic K8s manifests — the same infra-pass pattern already used for Dockerfile and docker-compose.

Implementation Notes

Follows the existing infra-pass pattern (no new tree-sitter grammar needed — reuses the vendored YAML grammar). Four components: detection helpers, a custom extractor, a pipeline pass, and tests. Documentation updates to README and CONTRIBUTING would be included.

Acceptance Criteria

• search_graph(label="Resource") returns all K8s resources in the indexed repo
• search_graph(label="Module") includes Kustomize overlay files
• A kustomization.yaml with resources: [deploy.yaml, svc.yaml] produces two IMPORTS edges
• All existing tests continue to pass; new tests cover detection, extraction, and graph emission