An interrupt is an "unusual" event that happens which needs to be processed immediately, regardless of whatever else is going on. I say "unusual" in quotes, because they're not necessarily unexpected or bad, but "unusual" from the point of view of the CPU because they "just happen" while it's busy executing code that may be unrelated.
The CPU has some mechanism for listening to interrupts, and some way of configuring "what to do" when interrupts of various kinds occur. This allows the operating system to arrange that it will be notified when hardware devices do things (including the all-important hardware clock, which simply generates interrupts at regular intervals). Through the CPU's interrupt handling configuration, designated code in the OS will gain control whenever interrupts happen.
The computer is in a very unpleasant state (to an application programmer) when an interrupt handler starts running; the machine was busy doing something else (which could be anything) and now the OS has been notified that "something has happened". It has to gather any other information needed to actually handle the interrupt from wherever in the machine it should be lying around and do whatever processing is required without disturbing that "could be anything" that was running on the CPU. If the OS wants to switch which application process is currently running it will have to save enough of the context to be able to restore it later (again, without disturbing that context), then load some other context, and then let the CPU resume normal execution in that context.
As mentioned, interrupts are used for getting notifications from hardware devices (the only alternative would be to periodically check them), keeping track of time and getting the guaranteed opportunity to regain control from an application process (in order to switch which application is running), recovering from application processes executing invalid instructions, and also to enable applications to make requests of the OS. These last are known as system calls. To prevent the applications from messing up the machine and each other, they normally run with the machine in "user mode", which prevents the application from doing basically anything other than reading and writing (virtual) memory already allocated to it. This means that to do anything else (reading/writing files, asking for more memory, accessing devices, etc) the application has to make a system call; it does so basically by leaving some information about what it wants to do somewhere it knows the OS will look for it, then executing a CPU instruction that causes an interrupt of the right kind. The OS can then see what the application was trying to do and determine whether it should carry out that request. This guarantee that the OS will be involved in any process' attempt to do anything that affects anything outside the process is the only way that access policies can be enforced.
So essentially, yes, the OS is driven by interrupts. An "abstract" OS bootstraps the machine into a "normal operation" state and at some point hands off control to a "normal" process. Under normal circumstances, the OS will then only regain control by handling interrupts; but since pretty much nothing interesting happens without an interrupt, the OS basically has control of everything all the time.
