The release cadence is public. If you run upstream be ready to do frequent updates. If you are a cloud provider you should also be ready to do frequent upgrades.
I tend to agree with you. Move Fast and Break Things has broken our industry in many fundamental ways. Just moving from 1.10 to 1.13 will result in broken integrations due to changed/deprecated APIs, no matter that it's a minor version change.
How can I know if a version is no longer supported? I found their docs talking about the four previous versions, but that seems to just be about the documentation and I can't find a statement about the software itself. Does the Kubernetes project do anything like Ubuntu or Node.js with the LTS concept, or is it a situation where you need to be running a version within the last x releases?
You often find some confusing statements about supported versions because sometimes they're talking about version skew between different components. More about that here: https://github.com/kubernetes/website/issues/7103
What does that even mean to support it? It's not like you can't ask questions the general community to get answers. You also don't have a support contract with it since it's open source software. And if they did release a patch for it, you might as well upgrade anyways since there are tons of new fixes.
Specifically, a supported release is one which will receive patch updates (e.g. for security flaws or other issues).
If you do not use a "supported version", you'll have to scramble to update or backport patches yourself if you're hit by a serious issue that is fixed upstream.
Yes, we're waiting till 1.11.6 lands - some important fixes for clouds in there. We've debated releasing at the same time as Kubernetes, but the feedback we've got is that users prefer that a kops release is ready to run, but we also need to do a better job of releasing alphas & betas earlier.
Obviously the current delay is not great - I'd much prefer for us to be on 1.12 (which actually has fixed the main issue already). I'm hoping we can catch up once we're (finally) done with the etcd3 migration.
C'mon, Amazon.