Client and server keys live in different worlds -- the client key is verified by the server, the server key is verified by the client. Your problem at hand is about having many servers and one client, and key sharing between servers. What you do with the other world (the client key and the
authorized_keys file) is irrelevant; it has no impact on that question.
I am tempted to say that the biggest problem with this key sharing is not that the key is shared; it is why you want to share the key. You want to share the key because you don't know to which of the servers you are going to connect. And that is the problem: you are doing a SSH through a load balancer that will send you to one of the servers, but with no control on which one you end up. This is not what you want. You want to be able to do a SSH to all servers, not just a randomly chosen one. You cannot have that if you load-balance the SSH connections.
If you want (as I believe) to be able to control all your cluster machines individually, then you must have a way to connect to any of them specifically, and possibly (probably) several at the same time. This means using their non-shared specific IP addresses, or, as @Iserni suggests, distinct ports (if you must SSH "from the outside" and have only one IP address available). At that point, the key sharing is less important. You may still want to share the key for other reasons (e.g. creating all machines from an already configured image; or automatically creating an already populated
.ssh/known_hosts for your client). Key sharing between servers implies moving the private key around, which is, in all generality, a not very good idea; but machines from a cluster are probably close together and one may assume (or at least hope) that they can talk together without being spied upon by outsiders.
You may also want to investigate the tools linked from that answer.