This message was deleted.
# kubernetes
a
This message was deleted.
p
In my opinion there are many factors 1. are you or your team going to make use of the newly added features, in other words what is the motivation behind upgrading to latest version 2. N-2 in Prod and N-1 in DEV could be a good idea, where N could be the latest version, given that the release cycle is that of 3 months , (But you might want to have the parity between your pre-prod and prod)
g
@purple-pharmacist-31177 Thanks for the good feedback, I try to follow the good practices recommended by OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#kubernetes-version) to reduce security risks. The primary consideration is to guarantee business continuity (running apps), if for some reason I can't switch, I'll stay with the old version. I would upgrade to the maximum patch level to reduce security issues.
đź‘Ť 1
m
Generally speaking: the bleeding edge causes you to bleed. I’m just now getting on to K8s v1.20. Been running v1.18 for almost a couple of years now.
f
That's, uh, fairly extreme on the other end of the spectrum… <=1.22 have no upstream support or patching for CVEs
m
I agree it’s not ideal @full-painter-23916 - but considering we self-host, and how much of our underlying infrastructure is interwoven with Rancher/K8s, we can’t afford to just continually upgrade and hope nothing breaks, or that none of the other infra doesn’t need to be upgraded first.
We just got on vSphere 7, with the proper Netapp plugin upgrades, and are in the process of upgrading our Netapp storage heads and cluster next. That finally allowed me to get on a newer version of Rancher/K8s - because eventually I want to go with the out-of-tree storage provider. Though, we had issues with the in-tree provider post-upgrade to Rancher v2.5.16/K8s v1.20.15 - but I think @square-orange-60123 just helped me to solve those.