It depends on two things: 1. the frequency of inserts to the table, and 2. whether queries typically access several adjacent rows in the ordering you choose to place on the 8 columns.

If inserts are frequent (but perhaps not if they are extremely frequent), it's a good thing to cluster on something that increases or decreases with time, since otherwise inserts are going to cause fragmentation. However, if queries access multiple rows it's a good idea (if possible) to cluster on something that will bring together rows that will be accessed together.

Usually when confronted with something like 8 varchar(50) fields as the primary key it turns out that none of the key columns is helpful in bringing together on disc rows that are accessed together and none of the key columns is monotonically increasing or monitonically decreasing, so clustering on the primary key helps neither in avoiding fragmentaton nor in improving perfornace by bringing together on disc storage rows that are accessed together, so usually it is best not to cluster on the primary key, but on some column that will help with one or other of these two things; there may already be some column that will help if clustered on, but often there isn't and it may then be necessary to introduce a rather meaningless column (such as an identity column) that will help avoid fragmentation. But the real primary key should still be declared as the primary key (unclustered) - an identity column should certainly not be made the primary key in cases like yours when all access is by the natural key and the originators of the accesses can't reasonably be aware of the identity values.