A full Ethereum node is two programs rather than one. The split between execution and consensus clients is a structural feature with consequences for upgrades, diversity and operations.
Two distinct jobs
The execution client processes transactions, maintains account state and runs contract code. It answers the question of what the chain's state becomes given a set of transactions.
The consensus client tracks validators, handles attestations and determines which chain is canonical. It answers the question of which set of transactions counts.
Before the move to proof of stake, both functions lived in one program, because block ordering was decided by mining and required no separate validator accounting.
They communicate over a defined interface
The two programs exchange information through a specified engine interface, which lets the consensus client hand blocks to the execution client and receive validity responses.
Because the interface is specified rather than internal, any consensus client can pair with any execution client, and operators choose each independently.
The connection is authenticated with a shared secret, since anything able to reach that interface could otherwise instruct the execution client about which chain to follow.
Why the separation was retained
Merging both roles into a single program would have required rewriting mature execution software that had processed years of history correctly.
Keeping them separate allowed consensus development to proceed in parallel with execution clients continuing to operate largely as before.
It also isolates faults. A crash in one program does not necessarily corrupt the other, and each can be updated on its own schedule when upgrades permit.
Diversity has to exist in both layers
Several independent implementations exist for each role, and the health of the network depends on stake being spread across them in both layers rather than one.
An operator running a minority consensus client paired with a dominant execution client is exposed to bugs in the dominant one regardless of the other choice.
This is why distribution is tracked and published separately for each layer, and why staking services increasingly disclose their combination rather than a single client name.
Operational consequences for stakers
Running a validator means maintaining two pieces of software with separate release cycles, separate configuration and separate resource requirements.
Network upgrades often require both to be updated before a specified block, and updating only one can leave the node unable to follow the chain.
Validator keys are handled by a third component, the validator client, which is deliberately kept separate again so that signing material can be isolated from the software exposed to the network.