Etcd 3.2 now with massive watch scaling and easy locks

Every little bit helps, but no, etcd has not been an issue for Kube since 3.1. We already have a watch cache in the apiserver that supports large number of watches.

The issues right now are about optimizing how nodes communicate with the master for the tens of related resources used for pods (config maps, secrets, PVCs, etc). That's more classic optimization of how we batch that data.

I will say etcd 3.2 is fantastic because it removes the snapshot size limit for etcd2 - we've got Kubernetes clusters with 1-2Gb of etcd data and when the write rate gets high enough we are snapshotting so fast that if a member drops out you can't rsync the snapshot to the remote system fast enough to do a restore before the next snapshot hits. So this is a big win for us - thanks to the etcd team for getting that in at the last moment!