-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] instantiation of resource(s) and CRD Kind of resource #3502
Comments
@monopole Can you take a look at this? |
I have run into this too. I think it's due to the way in which CRDs get applied to the cluster. The CRD is applied, then the cluster accepts the kinds and makes them available. But there is a lag in that happening. So your other resource that requires the kind provided by the CRD can't be applied at the time. If you apply the CRD and the sealed secret in two steps - the process will work - not sure how to make this work in one go right now. |
based on @mikee's comment this sounds like an issue with kubectl/kubernetes and not kustomize? |
@TheAggressive @johscheuer can you please try just the build step here? This may be a |
I think the problem might be that the CRD is being created AND used in the same call to
You can tell this is the case because if you just wait a few seconds and run it again, it will succeed. You need to create the CRD in one step, wait for it to exist, then use the CRD in a second step. |
that is what I've experienced in testing. |
sorry @mikee I didn’t see your previous comment before I commented. Yes, I agree with your assessment of what is happening. |
@TheAggressive @mikee What if you remove the remote controller.yaml from the kustomization resources and do something like this instead:
This should create the crd, wait for it, then apply the kustomize output |
That works - what I've done is just split my kustomize into two overlays (using fluxcd). The "second" layer that depends on the CRD may fail the first time, but will eventually reconcile once the CRDs are accepted |
This is related to #3794 / #3913 in that it involves sequencing resources for deploy purposes. As discussed there and above, it is possible for Kustomize users to manually ensure that a given CRD appears before a related CR in the resource list output (using FIFO ordering), but Kustomize is not involved in the apply operation and cannot prevent the race between the cluster-side acceptance of the CRD and the attempted creation of the CR. As @brianpursley has suggested, the deploy must be separated into two phases to prevent this, although @mikee is also correct that simply retrying will eventually work. /close |
@KnVerey: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
For anyone landing here, MY issue (using helm/helmfile) was to add: ``--include-crds` explicitly to the template/upgrade/apply commands I use in our CD pipeline. For ArgoCD + helmfile, it looks like this now:
|
Thank you @armenr!
|
I'm not sure how to go about instantiation of a resource and then applying a CRD(?) of that resource in a fresh cluster to setup the cluster.
Example:
But once the kustomize build is ran and applied
kustomize build . | kubectl apply -f -
I see that thesealed-secret.yaml
wasn't applied and no secret was generated from the sealed-secret based on the followingkustomize build . | kubectl apply -f -
output:unable to recognize "STDIN": no matches for kind "SealedSecret" in version "bitnami.com/v1alpha1"
So is there a proper way to get this working? I was looking into
nameReference
in aconfigurations:
section of thekustomization.yaml
but not sure if that will give the desired result?Thank you!
The text was updated successfully, but these errors were encountered: