A CPU clock is a signal which is used for two related purposes:
Devices that are synchronous to a common clock agree that they will only look at signals from other such devices within a very short window after the clock changes.
Devices which are synchronous to a common clock agree that within that window they will never change any signals that are of interest to other such devices.
A very important feature of such systems is that there is never any ambiguity over which of two things happens first. Instead, either one will happen on an earlier clock than the other, or they will happen on the same clock in which cases they are unambiguously tied.
If computers would always process all operations in a fixed sequence that is decided in advance, it could have the circuitry that performs each operation wait until all preceding operations are done, without any need for a clock. Some parts of systems are sometimes designed that way, but in many cases some resources will be required to perform several operations, and it may be desirable to allocate the resource immediately to whichever operation is ready to use it first, and then have any later operation that needs the resource wait until the first operation is done with it. In systems that don't use clocks, however, this will create a problem.
If two operations that would need a resource become ready simultaneously, it is necessary that the circuits that would perform the operations both agree on which one should go first, before either proceeds. If each tasks thinks it should go first, the tasks will grab the resource simultaneously (oops). If each task thinks it should defer to the other, the tasks will deadlock waiting for each other to complete.
There are ways of resolving such situations in asynchronous systems by having both tasks recognize a window in which the other task might have beaten them, and will back off for an amount of time based upon how far they think were from the edge of that window, and then see if that results or one side or the other winning unambiguously (backing off again if it doesn't). Unfortunately, while the probability of a tie lasting for more than t microseconds would decrease exponentially with t, it's often difficult to parameterize how fast that will occur.
Having devices operate synchronously fixes this, since it makes it possible to design two circuits so that X will take a resource as soon as it becomes ready unless Y had been ready for it during the previous observation window, and Y will take the resource as soon as it's ready unless either X was ready for it in the previous window, or has become ready in the current window. While the likelihood that X and Y become ready "simultaneously" would be much greater than in the asynchronous system, such occurrences wouldn't cause problems.
While there are a variety of ways that a computer can generate the clock signal which is used to coordinate communication among the many components, an understanding of the purpose of the clock is far more important, especially from a computer-science perspective, than knowledge of the particular means used to generate it, and the principles involved are very similar to those involving long-range networking.