Upgrade to Latest Version ASAP — No Thanks
By: Tiexin Guo
Tags: Version Control, Software Engineering, Kubernetes, Software Development, Security

Background

At the moment k8s 1.16, 1.17, 1.18 are officially supported; the support for 1.15 has ended. But in AWS EKS, the latest version is still 1.16, and at the writing of the twitter above, even 1.16 in EKS hasn’t been released yet.

Do Not Upgrade To Latest Version ASAP

Photo by Michael Dziedzic on Unsplash

This may seem controversial, but while I do think we should move to 1.16 at least, when we are talking about security and stability, I am with Mozilla: not “upgrading to latest version asap”.

I think many people are like me. Take a very simple example: I guess not all software engineers have already upgraded their MacOS to 10.15.4 (I did).

You might say that this is only because you are lazy and don’t want to be interrupted by the download and restart, but there are actually very good reasons for “not always upgrade to the latest version as soon as possible”. The most important one is:

Bugs Diminishing Model

Photo by Markus Spiske on Unsplash

The number of bugs discovered for a given version, given software is diminishing over time.

Thus, by a “delayed” upgrading strategy, you have much less trouble and potential security issues in production and reduce your maintenance in production.

Of course, like everything else, there is exception. For example, if there is a major security issue that can’t be patched, instead, must release a new version, you should definitely upgrade ASAP. But the norm would be to NOT upgrade ASAP so that you expose less potential security issues and bugs and stability issues in production environment.

Example — K8s 1.15

Taking k8s 1.15 as an example:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md

If you have a detailed look at the release notes, you will find out that, the number of bugs/issues fixed in each version is much less in the end than in the beginning.

It is universal for literally any piece of software.

Example — Firefox ESR 52

Take another example from Firefox ESR:

https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/

In the beginning month of Firefox 52, there are 31 bugs (can you believe that, a major release by a major company, one bug per day).

But only Half a year later, the number dropped to 7 per month, and it maintained that level ever since (some months even much lower).

Apparently, Mozilla also although about this “bug diminishing model” when they provide enterprise edition of Firefox (extended support release, ESR, or Firefox for enterprise). The ESR major version is always 3 less than (or one year behind) latest version. At the moment, latest version of Firefox is 71, ESR is only 68. Which one am I using? 68. I believe the bug diminishing model also works here, and I also believe the developers of the software know what they are doing when they are talking about enterprise security.

Conclusion

As of today, since EKS 1.16 has been released, I would upgrade to k8s 1.16 immediately (already did both in my work project and personal project), since 1.15 support ended. This makes perfect sense.

In a not-so-perfect real world (like literally 1 month ago when 1.16 EKS hadn’t been released), given the two choices:

A), using 1.15 for a few weeks/months before upgrading, and

B), using 1.18 immediately;

I’d definitely choose the former one for production, latter one for development env.