Function kube_api_version_is 

pub fn kube_api_version_is(value: &Value, api_version: &str) -> bool

Predicate: does the K8s custom resource YAML document at value declare its top-level apiVersion: CRD-group/version axis as exactly api_version? The pinned predicate peer of the kube_api_version (cf97d0a) accessor on the CRD-group/version half of the canonical top-level (apiVersion, kind) per-CR- registration coordinate pair, and the structural mirror on the CRD-group/version axis of the kube_kind_is (2902d9d) predicate on the peer CRD-kind half. Composes as kube_api_version(value) == Some(api_version) — same one-hop readback + equality-wrap shape the sibling predicate carries on the kind: half, differing only in which of the two canonical top-level CRD-registration coordinates it pins.

The KUBE_KEY_API_VERSION axis is pinned inside the helper (unlike the parametric field axis of the underlying kube_root_str_field) because the “does this CR document declare CRD-group/version X” question is a semantically-distinct CRD-group/version predicate, not a generic scalar-readback: the K8s API-machinery pins apiVersion as the load-bearing per-CR CRD-group/version discriminator on every CustomResource across every group (paired with kind for CRD-registration disambiguation), so this predicate lives one abstraction step above the generic readback. Peer predicates for other top-level discriminators (a hypothetical kube_group_is on the pre-/- slash CRD-group prefix of the same apiVersion: scalar, a kube_version_is on the post-/-slash version suffix on a multi-version migration harness) land as sibling helpers with their own pinned axis, not as re-parameterizations of this one.

Structural peer to kube_kind_is (2902d9d) on the sibling top-level kind: half of the same canonical (apiVersion, kind) coordinate pair: kube_kind_is answers “does this document match CRD-kind X” (the CR shape coordinate); kube_api_version_is answers “does this document match CRD-group/version X” (the CR registration coordinate). Same one-hop readback + equality-wrap shape, different pinned scalar- key on the same navigation depth (root) — together they bracket the two canonical top-level CRD-registration coordinates every K8s CR readback at controller / API-server admission time keys off. Same three-arity closure discipline the sibling sub-metadata.{name, namespace} per-CR coordinate pair already carries — the accessor (kube_api_version) reads, the predicate (kube_api_version_is) tests, the navigator (find_by_api_version) locates — each pinned to KUBE_KEY_API_VERSION inside the helper so the axis-key drift class is closed across every consumer surface.

Sites lifted:

• caixa-flux’s four per-emitted-file top-level apiVersion: lifted-uses pins across the cluster_bundle multi-file sequence — cluster_bundle_helmrelease_uses_lifted_flux_api_version (helmrelease.yaml), cluster_bundle_kustomization_health_check_uses_lifted_flux_api_version (per-entry kustomization.yaml spec.healthChecks[].apiVersion loop), cluster_bundle_gitrepository_uses_lifted_flux_api_version (gitrepository.yaml), cluster_bundle_kustomization_uses_lifted_flux_api_version (kustomization.yaml) — each per-file assert_eq!( kube_api_version(&parsed), Some(FLUX_<CRD>_API_VERSION)) equality-wrap on the Flux v2 controller-triplet CRD-group/ version axis;
• caixa-mesh’s per-CNP + per-Gateway + per-HTTPRoute top-level apiVersion: equality-wraps across the six test bodies cilium_network_policies_use_lifted_cilium_api_version (per- CNP loop), cilium_policy_carries_canonical_kube_skeleton (per-CNP loop), gateway_carries_canonical_kube_skeleton_without_labels (Gateway), httproute_carries_canonical_kube_skeleton_without_labels (HTTPRoute), gateway_routes_gateway_uses_lifted_gateway_api_api_version (Gateway), gateway_routes_httproute_uses_lifted_gateway_api_api_version (HTTPRoute) — each assert_eq!(kube_api_version(v), Some(<AXIS>)) equality-wrap over the paired-Gateway/HTTPRoute
  • fan-in CNP emission.

Every future per-CR CRD-group/version-filter site (the future per-:politicas CiliumClusterwideEnvoyConfig per-CR CRD-group/ version equality gate, MESH-COMPOSITION §III.2 #3; the future app-operator’s per-Aplicacao mesh.pleme.io/v1alpha1/Aplicacao CR CRD-group/version equality join over emitted status docs, §III.2 #5; the future M4 cross-cluster fan-out’s per-cluster Flux-triplet CRD-group/ version equality gate across the .toolkit.fluxcd.io root) reaches this same predicate by construction, with no inline kube_api_version(v) == Some(...) equality wrap and no re-parameterization on the pinned KUBE_KEY_API_VERSION axis-key.