Let's say I encrypt my passwords with PBKDF2 and store it somewhere.
It's not clear here whether you literally mean to encrypt some passwords with a key derived from a master password (as a password manager does), or whether you've hashed a password and stored the salt and hash as a verification token.
Does a knowledge of number of iterations make it easier to brute force the password?
Not really. The reason is that PBKDF2, at its guts, has this structure:
$$
F(\mathrm{Password}, \mathrm{Salt}, c, i) = U_1 \oplus \dots \oplus U_c
$$
...where $c$ is the iteration count, $i$ the output block, and:
$$
\begin{align}
U_1 &= PRF(\mathrm{Password}, \mathrm{Salt}\, \|\, \mathrm{INT\_32\_BE}(i)) \\
U_2 &= PRF(\mathrm{Password}, U_1) \\
& \vdots \\
U_c &= PRF(\mathrm{Password}, U_{c-1})
\end{align}
$$
Since the sequence of PRF outputs $U_i$ and their XORs share prefixes for any two values of $c$, this means that between each iteration the attacker is able to interleave a test to see whether their current password guess + trial iteration count succeeds. If it doesn't, they can resume the PBKDF2 computation without paying the cost of the earlier iterations. So the attacker is only slowed down by:
- How much they overestimate the upper bound of the true iteration count;
- The cost of the test decryptions at each iteration.
These are only going to make the attacker's cost incrementally larger.