What happened?

Not really a bug, but maybe unexpected behavior. Since etcdctl del accepts an optional second parameter which deletes all keys in a range, these are very easy mistakes to make:

# Oh no, there was a space in the key I copied!
etcdctl del /registry/persistentvolumes/pvc-eef4ec4b-326d-47e6- f11c-6474a5fd4d89
# <deletes thousands of keys>

etcdctl put 'key space' somevalue
# Oh no! I forgot to quote my key that intentionally contains a space!
etcdctl del key space
# <deletes thousands of keys>

# Oh no! I forgot to add -- to my flag!
etcdctl del a-key cacert=/some/file
# <deletes hundreds of keys>

What did you expect to happen?

Of course we could just tell people to pay super close attention when they run etcdctl del, but there's lots of advice scattered around the internet for fixing broken Kubernetes clusters that involves etcdctl del. Here's one example: kubernetes/kubernetes#90585 (comment)

Here's more: https://www.google.com/search?q=etcdctl+del+site%3Agithub.com%2Fkubernetes

As a result, I think having that optional parameter to delete a range of keys might constitute a footgun. Perhaps we should require an extra flag like --range or something so that there's never an implicit deletion of more than 1 key. Other options include placing a warning/confirmation if the command would result in more than one key being deleted (may be performance-intensive).

How can we reproduce it (as minimally and precisely as possible)?

docker run -d --name etcd quay.io/coreos/etcd:v3.5.0
docker exec -it etcd sh
<run etcdctl put and del commands from example>

Anything else we need to know?

No response

Etcd version (please run commands below)

v3.5.0

Etcd configuration (command line flags or environment variables)

Etcd debug information (please run commands blow, feel free to obfuscate the IP address or FQDN in the output)

Relevant log output

No response