Clustered indexes store the records in the table in key sequence. That means that if your index is in an identity column, new rows will be added at the end of the table space. However, if the index is on a user-created field, records are added where they would logically fall in sequence. In order to do this, the database engine must retreive the physical record that will hold the new record and reorder the existing records so the new one is added in its correct location. The updated physical record is then written back to the tablespace. If there is not enough free space in the physical record, two records will be created, each containing some free space. Here is a very rudimentary example it is not intended to show the precise logic of row insertion but is a high-level concept example. In the example, physical records (used to be called blocks in mainframe file systems) are separated by semi-colons and records (rows) are separated by comas.
rec10, rec20, r3c30, rec35, rec40; rec60, rec70, freespace; rec80, rec100, rec110,freespace;
you want to add rec25. The new physical record will be
rec10, rec20, rec25 r3c30, rec35, rec40;
If there is no free space to add the new row, then two physical records are created.
rec10, rec20, rec25, freespace; r3c30, rec35, rec40,freespace;
So to summarize, clustered indexes work best when the index is on an identity column so that all inserts happen at the end of the tablespace which minimizes the block splitting activity and most searches are done using that same identity column. It is a trade-off of physical database design whether to add a clustered index to optimize row retrieval or not and I haven't begun to cover the considerations.
As you can see, it is only possible to have a single clustered index on any table since the table rows can only be in one physical sequence at a time.