flux-system kustomizations deleted #5472
-
|
Hey guys, We were using flux version 2.5.0 What we're doing is telling flux via a kustomization to look into the another repository for the Here's what it looks like. # controller.yaml
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: descheduler
namespace: descheduler
spec:
interval: 1m
path: ./descheduler/
prune: true
sourceRef:
kind: GitRepository
name: centralised-services
namespace: flux-system
targetNamespace: deschedulerThis is the ---
apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
name: descheduler
namespace: descheduler
spec:
interval: 1m
url: oci://123456789012.dkr.ecr.eu-central-1.amazonaws.com/descheduler
provider: aws
ref:
tag: 1.0.0
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: descheduler
namespace: descheduler
spec:
interval: 1m
chartRef:
kind: OCIRepository
name: descheduler
namespace: descheduler
install:
remediation:
retries: 10
remediateLastFailure: true
upgrade:
remediation:
retries: 10
remediateLastFailure: true
valuesFrom:
- kind: ConfigMap
name: descheduler
valuesKey: descheduler-values
optional: trueHere is a brief summary of the commits we did.
If need be I can provide the specific commits but anyone knows what the issue could be? Edit: Added the kustomize event |
Beta Was this translation helpful? Give feedback.
Answered by
stefanprodan
Aug 6, 2025
Replies: 2 comments 22 replies
-
|
If you changed anything in the I suggest migrating to Flux Operator which automatically generates the |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
So I tried setting Here's what I did.
# flux-capacitor/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
name: flux-capacitor
resources:
- controller.yaml
- configmap.yaml# flux-capacitor/controller.yaml
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: flux-capacitor
namespace: flux-system
spec:
interval: 1m
path: ./flux-capacitor/
prune: true
sourceRef:
kind: GitRepository
name: centralised-services
namespace: flux-system
targetNamespace: flux-system
apiVersion: v1
kind: ConfigMap
metadata:
name: flux-capacitor
namespace: flux-system
data:
capacitor-values: |
namespace: flux-system---
apiVersion: v1
kind: Namespace
metadata:
name: flux-capacitor
Am I missing something here? |
Beta Was this translation helpful? Give feedback.
-
|
It really depends on how fast Flux Operator reacts to changes of his managed resources. If you changed the targetNamespace after the operator reconciled the instance, then your Kustomization has lost ownership and it skipped deleting the namespace. I suggest suspending the FluxInstance when doing this test. With this PR controlplaneio-fluxcd/flux-operator#391 the race condition will never happen as a Kustomization is no longer allowed to delete the namespace. |
Beta Was this translation helpful? Give feedback.
-
|
Also the namespace should be applied by the Kustomization where you set targetNamespace: apiVersion: kustomize.config.k8s.io/v1beta1
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the long delay. I went on a week long vacation. I think we can close this one now. Just one followup question. What steps should we take to migrate existing kustomizations, gitrepo, ocirepo etc. out of the |
Beta Was this translation helpful? Give feedback.
-
|
See the FAQ here https://fluxcd.io/flux/faq/#how-can-i-safely-rename-a-flux-kustomization |
Beta Was this translation helpful? Give feedback.
Answer selected by
UzairQamarxyz
-
|
@stefanprodan sorry to bother you again but we hit the issue once again. Here is our setup. Here is a patch file maybe this helps a bit. |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
Huh! ok I didn't know that. The engineer before me implemented this and we just went along with it.
Is there a difference between this kustomization and what we created? Edit: I read it wrong |
Beta Was this translation helpful? Give feedback.
-
|
There is, the Kustomization is generated by Flux Operator and it's not stored in Git, there is no way to delete it via a Git mistake. If you delete the FluxInstance from Git, no actual workloads get removed, only Flux. |
Beta Was this translation helpful? Give feedback.
-
|
Ahhh ok got it. What should the process be to move to that kustomization? Thanks again. |
Beta Was this translation helpful? Give feedback.
-
Suspend the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I think we can close this one for sure this time. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you changed anything in the
clusters/<cluster>dir, that could have catastrophic consequences, like creating a kustomization.yaml in there, deploying things in the flux-system namespace, or having the flux-system namespace is any other kustomization.yaml in Git. You should think of the flux-system ns as kube-system, nothing should go in the there besides Flux.I suggest migrating to Flux Operator which automatically generates the
flux-systemKustomization that you can't delete via Git operations. Migrating an existing repo/cluster can be done without downtime, see https://fluxcd.control-plane.io/operator/flux-bootstrap-migration