Again, I'm not a cryptographer, and PBKDF2 is just an example. I would try to consult someone with a heavier background in the field. I've used PBKDF2 and Scrypt before, Argon2 is the newest, but also therefor least battle-tested.
Doesn't look like the Go API[1] allows you to specify an output key material length, so you'd just truncate or iterate until you get however much material you need (The HKDF Wiki implementation does this[2]).
You don't want to generate key material from a password with hkdf. From the RFC:
On the other hand, it is anticipated that some applications will not be able to use HKDF "as-is" due to specific operational requirements, or will be able to use it but without the full benefits of the scheme. One significant example is the derivation of cryptographic keys from a source of low entropy, such as a user's password. The extract step in HKDF can concentrate existing entropy but cannot amplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value,and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF.
I had another question regarding encryption of secrets. The reason you've mentioned is to prevent secrets from remaining in plain-text either during transmission to/from etcd or within etcd at rest.
Again, I'm not a cryptographer, and PBKDF2 is just an example. I would try to consult someone with a heavier background in the field. I've used PBKDF2 and Scrypt before, Argon2 is the newest, but also therefor least battle-tested.
https://godoc.org/golang.org/x/crypto/pbkdf2
https://godoc.org/golang.org/x/crypto/argon2
https://godoc.org/golang.org/x/crypto/scrypt