https://rancher.com/ logo
Join Slack
Powered by
What upgrade cadence does everyone follow for Ranc...
# general
w
What upgrade cadence does everyone follow for Rancher CE? When setting up a new cluster (Rancher 2.14.2 with fleet 0.15 and helm 4) I'm running face first into fleet and helm bugs. The helm bug https://github.com/rancher/fleet/issues/5076 is going to require wiping the cluster to downgrade to Rancher 2.13.3. The fixes won't be introduced until Rancher 2.15 which seems to make the entire 2.14 branch unusable. Is this typical? Is it best practice to lag minor versions behind for stability?
b
We're not bit with this, but we're also not using complex fleet/helm things.
Typically I lag behind for a 2.x.1 or 2.x.2 release before upgrading. As long as the minor version you're on is getting security patches it is pretty typical. But every business has their own drivers and plans for what's important. That being said I've know of large companies with thousands of employees that are still running EOL versions of software because they don't want to upgrade. That sadly, IS also typical.
w
Is the 2.13.x branch still getting security updates? To me, it looked like the project had moved on to 2.14. The only updates to 2.13 I could find were for Rancher Prime.
b
Yep, prime, but this is a helm issue not really a Rancher one. You could also use Jenkins or Argo or something else to do the helm installs if you need to.
w
The file encountering the helm issue is a Rancher template post-delete-hook-config-map.yaml I honestly don't know how people are using the 2.14 branch without encountering this problem.
b
That sounds like a potential rancher bug that can be fixed
Is there a github issue for the template/configmap issue?
w
b
at least there's a workaround.
w
It seems the workaround is to unpack it locally and patch it but then I'd be maintaining a fork right?
b
Only for this version
Just unpack, and patch. Upgrade to 2.15.x and there's nothing to patch again
You'll only have to apply the patch again if you upgrade to another 2.14.x version
Not worth packaging and maintaining imho.
c
Yeah this is a helm bug, not fleet or rancher. https://github.com/helm/helm/pull/31941 Look for the version of helm to be bumped, and the fix pulled through to fleet and rancher via backports.
b
rancher via backports
Into 2.14? I didn't see any mention of backports in the ticket you referenced.
c
Well this isn’t a Rancher issue
As per https://github.com/rancher/rancher/issues/54997 this is only seen when deploying a standalone k3s/rke2 cluster, THEN deploying a standalone instance of fleet that is affected by the helm issue, THEN using fleet to deploy Rancher
• Setup cluster with 
v1.35.2+k3s1
• install rancher fleet helm chart version 0.15.1.
• add a repo containing a bundle to install rancher version 2.14.1
I don’t think we test or support that. I would probably recommend just using the HelmChart resource built in to K3s/RKE2 to deploy rancher. Otherwise you’ll see all kinds of weird stuff when the fleet deployed by rancher conflicts with the fleet that was deployed standalone to bootstrap rancher.
tl;dr @wonderful-bear-52465 don’t do that
w
Hi. My current deployment strategy is creating the standalone rke2 cluster then using 
helm upgrade --install rancher rancher-stable/rancher
then from within Rancher, I'm configuring fleet (not a manual fleet install). I have a rancher bundle in my fleet repo which then configures tls with cert-manager.
b
Yeah, just do a three node cluster
Don't do a standalone.
w
sorry, bad terms on my end. by standalone, i meant that it's just a rancher management cluster (3 rke2 nodes) to run rancher and cert-manager.
b
3 nodes clusters are typical for prod environments and are a much stronger best practice than anything to do with lagging behind versions.
w
I'm hitting the bug when the fleet bundle for rancher tries to apply after cert-manager comes up.
I think I've found where I went wrong. As brandon said, I need to use a HelmChart resource for install instead of 
helm upgrade --install ...
. Then use a HelmChartConfig in fleet to configure TLS after cert-manager is configured and running. Let me test and I'll update in a bit.
c
You should be able to do everything with HelmChart
Copy code
apiVersion: <http://helm.cattle.io/v1|helm.cattle.io/v1>
kind: HelmChart
metadata:
  namespace: kube-system
  name: cert-manager
spec:
  targetNamespace: cert-manager
  createNamespace: true
  version: v1.19.1
  chart: cert-manager
  repo: <https://charts.jetstack.io>
  set:
    crds.enabled: "true"
---
apiVersion: <http://helm.cattle.io/v1|helm.cattle.io/v1>
kind: HelmChart
metadata:
  name: rancher
  namespace: kube-system
spec:
  targetNamespace: cattle-system
  createNamespace: true
  version: v2.14.0
  chart: rancher
  repo: <https://releases.rancher.com/server-charts/latest>
  set:
    ingress.tls.source: "letsEncrypt"
    letsEncrypt.ingress.class: "traefik"
    letsEncrypt.email: "<mailto:user@example.com|user@example.com>"
    hostname: "<http://rancher.example.com|rancher.example.com>"
    replicas: 1
The issue you linked to was a bug in Helm v4, if you are using rancher 2.14 then nothing should be using helm v4 yet. Are you sure you don’t just have a typo somewhere, and have misidentified the root cause of your issue?
w
I was able to get it up and working. Thanks for the resource suggestion @creamy-pencil-82913 FYI, Rancher 2.14 bundles Fleet 0.15.3-rc2 and Fleet is using helm 4.1.4... unless I'm reading the source wrong. https://github.com/rancher/rancher/blob/release/v2.14/build.yaml https://github.com/rancher/fleet/blob/release/v0.15/go.mod#L85
15 Views
Open in Slack
PreviousNext
Powered by