Files
home-network-k3s-impl/platform-config/kustomization.yaml
T
jakman85andClaude Opus 4.8 dbffb8fab8 Phase 5: KubeVirt + CDI IaaS proof (R-PLAT-03/04, R-STATE-01, R-NET-01)
- platform/kubevirt: pinned KubeVirt v1.9.0 + CDI v1.66.0 operators (remote bases);
  KubeVirt/CDI CRs tuned for Longhorn; useEmulation=true (prefer real KVM, emulate fallback).
- Controllers/configs split (F-MON1): CRs + ServiceMonitors + alerts via platform-config.
- Observability: ServiceMonitors, KubeVirt platform-health alerts (R-OBS-04), VM dashboard.
- catalog/vm-demo.yaml (kind: vm) + rendered VirtualMachine/DataVolume fixture.
- Conformance: vm-lifecycle (R-PLAT-03/04), vm-data-survival (R-STATE-01, L3),
  vm-default-deny (R-NET-01) — self-skipping until KubeVirt+longhorn exist.
- ci/SPEC_PIN: adopt accepted spec b633b7f (ADR-0015 egress work already merged).
- conformance/run.sh: document R-ENV-02/R-GITOPS-01 coverage gaps (WS-GITOPS/INFRA-owned).

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-08-24 19:51:30 -05:00

43 lines
2.6 KiB
YAML

---
# platform-config — the CONFIGS half of the controllers/configs split (flux2 idiomatic).
#
# WHY: the `platform` Flux Kustomization installs the CONTROLLERS (HelmReleases) that register CRDs
# (cert-manager.io, kyverno.io, …). The custom resources BELOW use those CRDs, so applying them in
# the SAME pass fails atomically ("no matches for kind ClusterIssuer") and blocks the whole platform
# apply. This Kustomization carries the CRs and is gated `dependsOn: platform` (wait) so the CRDs
# exist first. See clusters/base/platform-config.yaml + DECISIONS-LOG.
#
# Files are referenced IN PLACE via ../platform/... (Flux builds with LoadRestrictionsNone, and the
# Kyverno policies must stay under platform/kyverno/ for the CI L0 `kyverno test` gate). Build/verify
# locally with: kubectl kustomize --load-restrictor LoadRestrictionsNone platform-config
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
# cert-manager: DNS-01 issuers (need cert-manager.io CRDs from the cert-manager HelmRelease)
- ../platform/cert-manager/clusterissuers.yaml
# gateway: the Gateway + wildcard Certificate (Certificate needs cert-manager.io; Gateway needs the
# GatewayClass, which stays in platform/gateway as a controller resource)
- ../platform/gateway/gateway.yaml
- ../platform/gateway/wildcard-certificate.yaml
# kyverno: ClusterPolicies (need kyverno.io CRDs from the Kyverno HelmRelease)
- ../platform/kyverno/policies/require-default-deny-baseline.yaml
- ../platform/kyverno/policies/validate-default-deny-shape.yaml
- ../platform/kyverno/policies/restrict-host-namespaces.yaml
- ../platform/kyverno/policies/require-egress-class-label.yaml
- ../platform/kyverno/policies/require-auth-mode-label.yaml
- ../platform/kyverno/admission/secret-provenance.yaml
# cilium: L2 LB IP pool + announcement policy (cilium.io CRDs already registered by Cilium)
- cilium/l2-ip-pool.yaml
- cilium/l2-announcement-policy.yaml
# monitoring: PrometheusRule alert rules (need monitoring.coreos.com CRDs from kube-prometheus-stack)
- ../platform/monitoring/alerts.yaml
# kubevirt/cdi (Phase 5): the KubeVirt + CDI CRs consume the kubevirt.io / cdi.kubevirt.io CRDs the
# operators register; the ServiceMonitors/alerts consume monitoring.coreos.com. All CRs of platform-
# installed CRDs -> applied here, gated dependsOn platform (F-MON1). The dashboard is a plain
# ConfigMap kept beside them for locality.
- ../platform/kubevirt/kubevirt-cr.yaml
- ../platform/kubevirt/cdi-cr.yaml
- ../platform/kubevirt/servicemonitor.yaml
- ../platform/kubevirt/alerts.yaml
- ../platform/kubevirt/dashboard.yaml