https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# general
a
This message was deleted.
a
probably remove in cluster management in rancher, but you won't have control over it
a
my Main rancher Instance is in a invalid state. i need to be absolutely safe, that rancher don't redeploy / delete any resources via fleet or otherwise. So i figured, i stop fleet-agent and cluster-agent, reinstall rancher and enable git repo after git repo. the last time i had such a problem, i tried to restore the rancher backup. this ended in a nightware, where production clusters suddenly began to remove the deployments. i don't want this to happen again. so i can scale down fleet. but i can't scale down cluster-agent. and i don't understand what scales the deployment up. it should behave like any other deployment, right?
a
ugh yes
what if you remove it? but I'm not good with this either, do you have single node for control plane?
a
its a 3 node rke cluster only for rancher. i'm planing on upgrading this installation (rancher 2.5.8 on k8s 1.19) to a current version of fleet.
i'm trying to replicate the scenario as we speak
a
Good luck
a
thx.
hm, on my newly deployed cluster i can downscale the cluster-agent deployment ....
should really switch to argo 😞
so if i remove the member cluster via UI, everything fleet managed gets deleted
a
yeah..
Not something you want I assume
a
so, if i stop fleet agent in advance, then delete the cluster, the deployments survive. but sometimes funny things happen after i rejon the cluster
a
Yeah, drift, or if you don't have the exact matching ids, it will redeploy as a totally new cluster, understandable in a way
a
yeah. i can't find any 'clean' way to rejoin a cluster with workload. which would no be that big of a problem, if the workload were stateless. but it isn't
a
well, I guess ideal would be to just use plain yaml files, all these tools have some convenience, but it fails sometimes for bad reasons 😄
a
yeah. best way would be building a new cluster and transfer the load i guess
a
yup, experienced everything, and some exotic cases with fleet, but still using it
a
my only reason was that it handelt everything as helm. i thought that to be an advantage. but it is not. the reconciling of fleet is not very good
a
I used more of kustomize
lately helm more
a
but as i'm using a complicated helm chart with post and pre hooks, it was the best way to do it
a
Something I might look into in the future
a
should take time to convert it to an operator 🙂
a
helm dependencies
a
fleet sucks on this because it can not handle helm umbrella charts
also using more than one values.yaml files would sometimes produce funny outputs .
a
I used gitlab agent a little for bootstraping clusters with apps (helmfile)
a
but overall it works. but as i have used argo cd in my last project, i really regret strarting with fleet
i build terraform modules to boot rke clusters including some helm charts like cert-manager, external-dns and so on.
a
cool
a
turns out, there is a ready to use eks module there now, that does the same thing 🙂
a
Sometimes technology catches up to you
a
yeah, i think i'll leave rke cluster in aws behind and use eks clusters in the future. it was a bad idea anyway to create custom cluster
a
Under the hood everything is the same 😄
a
the thing i miss most is the ability to create node pools. for that i'd need rke2
do you have some kind of notification after a new deployment?
a
oh, I do use rke2, but not really a cloud user 😅
I found this gem which might come handy if you ever use rancher in fleet.yaml you can define keepResources to true that if you "delete" the GitRepo, that it doesn't delete your resources
a
thx!
i'll test it
a
not sure what happens when you re-introduced another cluster
a
yeah, about to find out later tonight :)
👍 1
so, if i enable keepResources, delete the member cluster and add it again, it keeps the deployments. so this is very good thing to have.
👍 1
i think it should work this way. I've created a test member server. rolled out gitrepos without keepResources, than scaled down fleet-agent and removed cluster. this keeps the deployed applications. after that i changed the gitrepo to keepResources: true and rejoined the member cluster. All deployments were kept (where i had sometimes problems with recreating some workload in earlier tests): so should be all good
Open in Slack
PreviousNext
Powered by