We know techniques for cheaply computing collisions in MD2, MD4, SHA-0, and, of course, MD5.
The first cheaper-than-generic technique for computing MD5 collisions was published by Hans Dobbertin in 1996; then a collision in MD5, computed in a few hours on an IBM p690, was published by Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu in 2004, and the technique explained in a followup paper in 2005 (some details on the history); an independently developed technique was used in an international incident of industrial sabotage by the United States and Israel against Iran; and the techniques for computing MD5 collisions have since improved nearly to the point of being a parlor trick.
We also know a technique for computing collisions in SHA-1 much more cheaply than a generic collision search on a 160-bit hash function. It is nowhere near as cheap as MD5—it cost about $2^{64}$ evaluations of SHA-1, whereas a generic collision search costs $2^{80}$ evaluations of the hash function, and the current best known MD5 collision search by Tao Xie, Fanbao Liu, and Dengguo Feng costs only $2^{18}$ MD5 evaluations. But it has been executed to find SHA-1 collisions, and for Merkle–Dåmgard hash functions like MD5 and SHA-1, one collision of equal-length messages can be trivially extended into many, so knowing one SHA-1 collision is enough to get you in trouble!
We don't know any techniques for finding collisions with reasonable cost in SHA-2, SHA-3, any of the SHA-3 finalists, BLAKE2, or various hash functions of lesser import.
Many crypanalysts have tried, and failed, to figure out techniques for finding collisions in these. Any hash function widely used by many applications, especially financial or political applications, will be subjected to scrutiny because of its high value. It's possible that a spook or crook who found an attack might choose not to publish it, of course! The SHA-3 competition subjected a number of candidates to years of scrutiny by the world's top public academic cryptanalysts, compiled at the SHA-3 zoo, so that we have some confidence in them to resist collisions.
We also don't consider any hash functions with small outputs, e.g. less than (say) 192-bit, to be collision-resistant because the cost of generic collision searches, counted in number of evaluations of the hash function, is small enough to be within the realm of feasibility for humanity to execute.
To put the number in perspective, the Bitcoin network today performs about $30 \times 10^{18}$ SHA-256 computations every second, about $2^{64}$ per second or $2^{90}$ per year. A generic collision search on a 192-bit hash function would cost an expected $2^{96}$ evaluations. That's not cheap, but it's imaginable.
