KubernetesIstioBaseCrds — Design Notes

Purpose

KubernetesIstioBaseCrds exists to decouple CRD installation from mesh installation for the Istio API family. The typed Istio components (DestinationRule, ServiceEntry, PeerAuthentication, RequestAuthentication, AuthorizationPolicy, Telemetry, EnvoyFilter) only need the Istio CRDs present on the cluster to be applied and server-side validated — they do not need a running control plane. Standing up full istiod per E2E run (as KubernetesIstio does) is heavy and unnecessary for validating the API surface.

This mirrors the Gateway API family's KubernetesGatewayApiCrds.

Version coupling (single source of truth)

OpenMCF ships typed Pulumi resources for the Istio kinds, generated by crd2pulumi from a pinned Istio release (pkg/kubernetes/kubernetestypes/Makefile → istio_release). The custom resources OpenMCF emits are therefore frozen to that schema version. For those CRs to apply cleanly (no silent field pruning, no server-side rejection), the CRDs installed on the cluster must be the same version.

Consequently this component has no user-facing version knob. The CRD bundle version is a build-time constant (IstioRelease in the Pulumi module, istio_release in the Terraform locals) that must be bumped in lockstep with the SDK pin. This deliberately avoids the latent inconsistency in KubernetesGatewayApiCrds, whose version field defaults to v1.2.1 while its typed SDK is generated at v1.5.1.

Relationship to KubernetesIstio (kind 825)

E2E

e2e/prerequisite.yaml is installed automatically by the harness for any of the seven consuming kinds. e2e/scenarios/minimal.yaml exercises this component standalone. The harness verifies the Istio CRDs are present on the cluster (see the kubernetes provider aa_e2e/verify crdInstallKinds entry).