Can anyone help me understand how the below scenario looks in a cluster? Im havi . . .

Joe:
Can anyone help me understand how the below scenario looks in a cluster? Im having trouble understanding how this would be applicable.

If you want to take a backup of the ETCD service running on a different machine, you wil have to provide the correct endpoint to that server (which is the IP Address and port of the etcd server with the --endpoint argument)

Does this translate to … if you are on a worker node and and want to take a backup of your etcd cluster that is on your controlplane/master node?

Rocky:
You could be anywhere with etcdctl client installed as ETCD is independent tool (not tried myself outside cluster).

Joe:
But how will this translate in the test since Ill inevitably be on one either the master node or worker node?

Joe:
Does this mean, that since Im likely already on a node in the cluster I wont need to add the endpoints?

Joe:
and if Im on a worker node- should I ssh to the master node and do the back up from there?

Joe:
Also… is etcd ever NOT stored on the master node?

Fernando Jimenez:
The etcd can been running in a different machine. In fact, in production like, it is running in its own machine as a member, along side other etcd machines that form their own cluster. You still communicate the same way: via a client.
A common client is the etcdctl program. That can run from any machine as long as you pass it the proper url location of the etcd server or cluster. And as long as you have the proper certificates for authentication and authorization.

Fernando Jimenez:
In order to use etdctl, it must be installed or available in the machine where you are issuing the command from.

Fernando Jimenez:

Does this mean, that since Im likely already on a node in the cluster I wont need to add the endpoints?

If the client etdctl is in the same machine where the etcd db lives, you still have to give it all four arguments:
–endpoints
–cert
–cacert
–key
The difference might be that the --endpoints could be a local url ip, instead of the external one.

Fernando Jimenez:

and if Im on a worker node- should I ssh to the master node and do the back up from there?

You should ssh into the machine that has the etcdctl program installed and the proper certificates and key.

Joe:
OK, super helpful - thanks @Fernando Jimenez.

OK Last question…How do I determine which machine that has the etcdctl program installed and the proper certificates and key?

Fernando Jimenez:
You have to be informed of it. Unless you are who needs to set it all up.

Joe:
So I guess in terms of the test. How would I know any of that? Would it have to be stated in the question - is that right?

Fernando Jimenez:
The information will be provided. You do not need to guess where the etcdctl utility resides.

Joe:
Awesome - many thanks @Fernando Jimenez - been struggling to understand that for a while.

Fernando Jimenez:
Perhaps this video might give you more insight. https://www.youtube.com/watch?v=rixtQBWvXNA

Rocky:
hey @Fernando Jimenez - do you have any url/doc to restore using back up. The steps in the tutorial does not seem to work every time.

Fernando Jimenez:
Hi @Rocky Yeah, that’s only for backup. Restoring requires a few extra steps. Perhaps this might help.
https://discuss.kubernetes.io/t/etcd-backup-and-restore-management/11019/5

SaidBen:
You cannt take a backup of etcd from a worker node; the only component that can talk to etcd is the api server which runs on control planes only.

Rocky:
hi @Fernando Jimenez - restore steps suggested by the lecturer is diff than as suggested in the lab; though lab’s steps works some times.