I have a lot of mixed feelings about the way we deprecate things in Kubernetes. A thread: /1

In general, we tend to deprecate things too quickly without enough consideration for what's next.

For example, we deprecated cloud providers in v1.7 and 13 releases later we're still chipping away at replacing them. This really dilutes the meaning of "deprecation" for users. /2

In v1.20 we are deprecating kubelet's support for docker, even though we know there are A LOT of users still using docker. The intent is to make some noise which is good, but only if there are clear expectations for when it will actually be removed. /3

There are actually two forms of "deprecations" in Kubernetes:

1. We're going to remove this thing soon, you were warned.
2. We don't want you to use this thing, but we will keep it forever and not break you.

We should do 2. as often as we want, but do 1. very carefully. /4

On the other hand, Kubernetes is a massive and complex system. Maintainability is a real struggle and we need to trim off dead code and unwanted dependencies to maintain project health. Some technical debt clearly needs to be removed, even if it causes some pain for users. /5

Sometimes I wonder if Kubernetes should adopt similar compatibility guarantees as Linux where we NEVER break users. No breaking of APIs, command line flags, config options, or anything really. /6

This would force us to think really carefully about GAing features and possibly cut new versions of APIs as opposed to building on top of existing ones. /7

Wishful thinking: we should create a bucket list of everything we want/need to remove today. And aside from those, ensure we never break users going forward. We can deprecate, but never remove. Maybe we can rip the band-aid off in a single release . Again, wishful thinking. /8