Does the Kerberos KDC know the users' plaintext passwords?

The short answer is: no.

It knows a secret key that may be derived from the user password. The specification RFC 1510 says in the introduction of section 6:

It is desirable for the string to key function to be one-way, and for the mapping to be different in different realms. This is important because users who are registered in more than one realm will often use the same password in each, and it is desirable that an attacker compromising the Kerberos server in one realm not obtain or derive the user's key in another.

Note that there is no random salt unique for every account, just the realm name which is shared among all users of the same realm.

The updated version RFC 4120 allows other way to derive the key:

The user key might be stored on a smart-card, or otherwise obtained independently of a password.

The answer is both yes and no, depending on what you mean. In the basic Kerberos model, ordinarily each principal in a realm shares a secret with the Kerberos authentication servers (Key Distribution Centers, or KDCs). (I say “ordinarily” because principals which will act only as clients can avoid sharing a secret and instead use other methods to authenticate to the KDC, e.g. an RSA key pair via PKINIT, or one-time passwords, which avoids the password-guessing issue discussed here entirely.) For a software component like a web server, this is a set of randomly generated keys; there is a set rather than just one, to accommodate clients with support for various cryptographic ciphers. For a user, it is a set of keys derived from the user’s password. So the KDC holds all the secrets: if it is compromised, an attacker can impersonate any principal in the KDC’s realm.

However, the KDC does not actually have the user’s password, only a set of keys derived from the password. This distinction is not important as far as Kerberos itself is concerned: the keys are the actual Kerberos secret. However, people often reuse passwords for various systems; so, if a KDC is compromised, the attacker will not immediately have the user’s password with which to try to access their GMail account, for example (though he can now mount a dictionary attack to try to discover the password).

Doesn't that mean that this is an Achilles' heel of Kerberos since if the KDC is compromised, the attacker will know all users' plaintext passwords (as opposed to getting /etc/shadow of a Linux system which will only provide the attacker with the hashed and salted passwords)?

It is a property of Kerberos; I wouldn’t call it an “Achilles’ heel.” The Unix password-hash scheme allows it to do one thing: verify plaintext passwords, which must be handed to the server. Systems like Kerberos and PKI can do far more than that, and they have more secrets to protect, distributed in various ways determined by the respective technologies. PKI doesn’t have a single store with all user keys — but it does have the highly sensitive keys of certification authorities (CAs), which must be protected with just as much vigilance as the Kerberos principal database, since stealing a CA private key similarly allows an attacker to impersonate many principals in the system. It may be easier to protect a CA private key than the KDC database since the latter must be online for KDC operation, whereas the former need only be available for relatively infrequent signing operations (though that depends on the nature and use of the CA in question). On the other hand, Kerberos password-based authentication does not require a secondary store or extra equipment (such as a smartcard) to hold the user’s private key and trusted CA certificates, and its symmetric cryptography is much faster than the public-key operations of PKI. And so on… there are many comparisons and tradeoffs.