The nonce k
is supposed to be an unpredictable number in the range 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336, inclusive - one for each point on the curve except the point at infinity (note: not the size of the field, which is very slightly larger than the number of points on the curve).
One way of doing that is picking a uniformly random number in that range. This works, but makes your security crucially depend on having a good random number generator. This is a simple problem in theory, but in practice lots of problems do occur. Notable examples are the Playstation 3 codesigning system (which used a fixed constant as nonce), or a bug in Android that in some cases resulted in applications generating the same sequence of "random" numbers.
The most common (and recommended) way today is using RFC 6979. It essentially prescribes not using randomness at all at signing time, but computing the nonce using a (specific) hash function that takes the message and private key as input. Under reasonable assumptions, this is just as unpredictable to attackers (who don't know the private key) as using actual randomness, but avoids the engineering challenges with having access to a good RNG.
One word of warning: unpredictability is a very wide concept, and has lots of pitfalls. There are actual attacks against picking a nonce that is taken from a much smaller range, or against nonces that are picked in some related way. Don't try to be "smart" about it.