As PBKDF2 is a key derivation function, its primary purpose is to turn a secret, low-entropy value into a higher entropy secret key.
In your use-case, if the key is expected to be secret (I assume it is), then using only publicly known data associated with the user will result in a key that anyone with access to the PBKDF2 parameters can generate.
That said, depending on how you intend to use the keys, if you intend to store them or generate them on the fly, etc. things could potentially change, but you would need to be careful of the fact that the output of PBKDF2 is effectively non-secret if you're solely using non-secret inputs.
The inputs don't necessarily have to be random (most passwords aren't, strictly speaking, random) but it should be secret. Remember that in general with key derivation functions you are trying to trade off the time you spend generating the key with the time it would take for someone to brute-force all possible candidate inputs for that key. So if the value is public, and even something directly associated like the username, they're not going to spend much more time figuring it out then you spent generating it. But if they have to guess every allowable password, the time taken to guess the input (and therefore be able to recreate the key) should hopefully be increased to the point that the resources required of the attacker would make the attack cost-prohibitive for what you're protecting with these keys.
How that cost-benefit analysis works out for your case is up to your risk assessment which should lead into your choice of PBKDF2 parameters, or even decision to use that algorithm at all, and your requirements of what is used as an input (e.g. what types of passwords are allowed to be used).