If you are using ssh public key to authenticate, you are only authenticating to your ssh daemon, not to the system. SSH daemon would claim that it performed authentication and then log you in into the shell. While this process might be utilizing PAM stack to set up your login session, it, however, does not handle authentication through the PAM stack.
I may state obvious to you, but Kerberos ticket can only be obtained if you use software that requests it. On a typical system such a ticket would be requested through PAM auth stage if either pam_sss or pam_krb5 is defined in auth stack of the PAM configuration used by your application. When such application (e.g. sshd) is skipping auth stage, none of PAM modules responsible for authentication are called and no Kerberos ticket can be obtained this way.
When Kerberos client attempts to request an initial ticket granting ticket (TGT), it and Kerberos KDC exchange a list of so-called "pre-authentication methods". In practice, these are the methods used to authenticate your client against KDC. One method chosen by a client, if accepted by the KDC, implements actual authentication process. There are no Kerberos pre-authentication methods that use a SSH key-pair for authentication, so you cannot use SSH key-pair to obtain a TGT. All standard password-based pre-authentication methods are built around both Kerberos client and Kerberos KDC knowning the long-term key (password) of the user principal, even though they do not pass it over the network. There is currently one method that does not rely on a password and it is so-called PKINIT method which relies on completing authentication using public key certificate infrastructure.
What can you do? You might want to turn it all around and use a smartcard for authentication instead. Smartcard authentication is supported by Kerberos as a 'pkinit' pre-authentication method. In addition to that, SSH daemon is capable to treat a certificate from your smartcard for authentication similar to the SSH key-pair case.
If you'd use PKINIT authentication, you have two ways: either obtain a Kerberos TGT with PKINIT on your workstation and login to SSH daemon on other machine using Kerberos ticket you have locally, or use your smartcard certficiate to login to SSH daemon as a SSH key and then use smartcard forwarding to request a Kerberos ticket on the host directly. In the former case your original TGT would not be forwarded to the SSH host automatically, unless you have asked for a ticket delegation. In the latter case you'd still need to request a TGT.
Regardless which method to use, you can definitely benefit from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_certificates_in_idm/index
If you don't want or cannot use smartcards, then the only method left is to use Kerberos login directly and forget about SSH key-pair authentication.
