Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.