Install a CRD and use it in the same kustomization

[akhayyat]

I have a kustomization directory containing the following three files:

1. kustomization.yaml

   resources:
     - cert-manager.yaml
     - cluster-issuer.yaml

2. cert-manager.yaml

   apiVersion: helm.cattle.io/v1
   kind: HelmChart
   metadata:
     name: cert-manager
     namespace: kube-system
   spec:
     chart: oci://quay.io/jetstack/charts/cert-manager
     version: v1.18.2
     targetNamespace: cert-manager
     createNamespace: true
     set:
       crds.enabled: "true"

3. cluster-issuer.yaml

   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt
   spec:
     acme:
       email: email@domain.tld
       profile: tlsserver
       server: https://acme-v02.api.letsencrypt.org/directory
       privateKeySecretRef:
         name: cert-issuer-account-key
       solvers:
         - http01:
             ingress:
               ingressClassName: traefik

When I try to apply this kustomization, I get the following error:

Failed to find exact match for cert-manager.io/v1.ClusterIssuer by [kind, name, singularName, shortNames]

How can I get this kustomization to work?

[mg1986jp]

This is a common chicken-and-egg problem with kustomize. When you include both a HelmChart (which installs cert-manager and its CRDs) and a ClusterIssuer (which depends on those CRDs) in the same kustomization, kustomize tries to validate the ClusterIssuer against the CRD schema at build time — but the CRD doesn't exist yet.

The simplest fix is to split them into two separate kustomization directories and apply them in order. Or if you're using something like ArgoCD or Flux, use sync waves / dependencies to control the ordering.

If you want to keep them together, you can tell kustomize to skip validation for unknown resources by using the --load-restrictor=LoadRestrictionsNone flag, or add a configurations section to define the ClusterIssuer as a "known" resource type.

Another approach: wrap the ClusterIssuer in its own HelmChart that depends on cert-manager being ready, using a simple Helm chart with a templates/ directory that contains the ClusterIssuer YAML and a dependency on cert-manager.

[akhayyat]

Thank you for your response.

What I learned after I posted this question is that a HelmChart resource does not install the CRD itself, but rather starts a helm install on the cluster, and that helm install ends up creating the CRDs. So, kustomize has no way of knowing that the CRD installation is included in this run.

So, I abandoned the HelmChart approach and switched to having kustomize install everything itself. For helm charts, I ended up using the kustomize HelmChartInflationGenerator resource, since it allows my to "kustomize" the chart values using environment overlays. Now, I'm not running into the error reported in my original post anymore, since the Kubernetes API sees the CRD installation, and therefore accepts its usage even in the same kustomize run.