<p>I've got a deployment which worked just fine on K8S 1.17 on EKS. After upgrading K8S to 1.18, I tried to use <code>startupProbe</code> feature with a simple deployment. Everything works as expected. But when I tried to add the <code>startupProbe</code> to my production deployment, it didn't work. The cluster simply drops the <code>startupProbe</code> entry when creating pods (the <code>startupProbe</code> entry exists in deployment object definition on the cluster though). Interestingly when I change the <code>serviceAccountName</code> entry to <code>default</code> (instead of my application service account) in the deployment manifest, everything works as expected.
So the question now is, why existing service accounts can't have startup probes?
Thanks.</p>

Rad
<p>Posting this as a community member answer. Feel free to expand.</p>
<h2>Issue</h2>
<blockquote>
<p>startupProbe is not applied to Pod if serviceAccountName is set</p>
<p>When adding serviceAccountName and startupProbeto the pod template in my deployment, the resulting pods will not have a startup probe.</p>
</blockquote>
<p>There is <a href="https://github.com/kubernetes/kubernetes/issues/95604" rel="nofollow noreferrer">github issue</a> about that.</p>
<h2>Solution</h2>
<p>This issue is being addressed <a href="https://github.com/aws/amazon-eks-pod-identity-webhook/issues/84" rel="nofollow noreferrer">here</a>, currently it is still open and there is no specific answer for this.</p>
<p>As mentioned by @mcristina422</p>
<blockquote>
<p>I think this is due to the old version of k8s.io/api being used in the webhook. The API for the startup probe was added more recently. Updating the k8s packages should fix this</p>
</blockquote>
