A few etcd v3 commands to list keys are documented here: https://github.com/coreos/etcd/issues/6904
E.g.: ETCDCTL_API=3 ./etcdctl get / --prefix --keys-only On Wed, Jun 28, 2017 at 10:13 AM, Daniel Smith <dbsm...@google.com> wrote: > This is an etcd question-- you need to understand whether your cluster is > using etcd2 format or etcd3 format. In your case, the cluster is probably > using etcd3 format. To make etcdctl work, you'll have to set an env var. > > Try running `ETCDCTL_API=3 etcdctl --help`. You will find that the > available commands have changed (`ls` is gone > <https://github.com/coreos/etcd/issues/6904>). > > Additionally, depending on the flags passed to apiserver, you may find > that your objects are being stored as protobufs instead of json, in which > case there is actually no good way to view them (we are working on > providing a tool for this, which may directly read the boltdb database etcd > writes, for use in emergencies). > > TPRs have no proto representation and aren't affected, if that's all you > want to view you'll be OK. > > > > On Wed, Jun 28, 2017 at 3:16 AM, 'mrpanigale' via Kubernetes user > discussion and Q&A <kubernetes-users@googlegroups.com> wrote: > >> With etcd 2+ with the following command I was able to inspect the >> apiserver state. >> >> $etcdctl ls --recursive /registry >> /registry/clusterroles >> /registry/clusterroles/system:controller:daemon-set-controller >> ... >> /registry/daemonsets >> /registry/daemonsets/default >> /registry/daemonsets/kube-system >> /registry/daemonsets/kube-system/keepalived >> /registry/daemonsets/kube-system/nghttpx-ingress-lb >> /registry/minions >> /registry/minions/10.10.2.102 >> /registry/minions/10.10.3.101 >> /registry/minions/10.10.3.102 >> /registry/minions/10.10.3.103 >> /registry/minions/10.10.3.104 >> ... >> >> With etcd 3+ i am struggling to find the apiserver state. The same >> command delivers empty output. This was useful when viewing raw state like >> TPRs if you did not have the TPR locally. >> >> kind regards, >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-users+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
