Well, one possibility is that the machine with kadmind could have its own copy of the database, the master copy, and all KDCs only have replicas of it.
Both MIT Krb5 and Heimdal Kerberos have replication tools, such as kpropd, to build redundant KDC clusters. So in the simplest case, you could have three KDCs but only one of them running kadmind, with kprop being used to transfer changes. (KDCs themselves don't make permanent DB updates, aside from optionally tracking the "last login" times, so replication can be unidirectional.)
In the same way you can also have a setup similar to "stealth master" in DNS, where the primary copy is managed from a machine that's not exposed to clients, and all changes are pushed out to KDCs via kprop (or rsync, or basic dump+load via SSH).
Another possibility is that the KDC is not using the file-based BerkeleyDB storage in the first place. Both MIT Kerberos and Heimdal can actually use an LDAP server as the KDC database, and once you have that, the kadmind process can connect to the LDAP server remotely – there would be no principal file at all.
(Several LDAP servers also support multi-master replication, which can be used to make all replicas writable, e.g. you could have 3 machines running OpenLDAP + KDC + kadmind, all of them equally "primary".
Indeed if you look at Microsoft's Active Directory, it is based entirely around an LDAP directory that holds all the information – including KDC and DNS data – and all DCs replicate changes in all directions. It has no separate 'kadmin' process; instead Kerberos principals are created via LDAP as part of the overall user or mcahine account, and you can just create that entry on whichever DC you like.)
