Page MenuHomePhabricator

Decide on upgrade policy for Kubernetes
Closed, ResolvedPublic

Description

Kubernetes has fairly quick release cycles - they're trying to put out a major release every 2-3 months, and minor bugfix releses are far more frequent. We need to figure out our policy for upgrading. They provide fairly strong API guarantees, so upgrading quick and often should be the most painless process.

Based on ideas from @chasemp about how Phab updates are done, I suggest:

  1. We have a set 2h window every two weeks.
  2. In this window, we upgrade to the latest version of k8s that we expect to work for us. This includes both minor point releases and major releases that don't break api compat. Since APIs are versioned independently of k8s versions, this should be mostly fine.
  3. We don't *have* to use the window.

We'd also have differnet people do the deploys, so that we'll have it super automated, documented and simplified :)

Thoughts?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Since there are no objections, I'm going to setup a recurring window every two weeks for the k8s upgrade, preferably on Tuesdays.

@Bstorm Another task from the Kubernetes graveyard to consider. I like the idea of us having a rough lifecycle plan including cadence ideas. I'm not sure that standing deploy windows are the right way to go about this however.

dcaro claimed this task.
dcaro subscribed.

We decided not to decide, and keep the upgrades "best effort", trying to keep up with the 4-months cadence of the major releases, but falling back to <14 months major version deprecation time (as in upgrading to the latest version at the point when we get close to getting the current version in the deprecated window).