Kubernetes 1.18 on EKS StartupProbe with old ServiceAccountName

10/23/2020

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 startupProbe feature with a simple deployment. Everything works as expected. But when I tried to add the startupProbe to my production deployment, it didn't work. The cluster simply drops the startupProbe entry when creating pods (the startupProbe entry exists in deployment object definition on the cluster though). Interestingly when I change the serviceAccountName entry to default (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.

-- Rad
amazon-eks
kubernetes

1 Answer

11/2/2020

Posting this as a community member answer. Feel free to expand.

Issue

startupProbe is not applied to Pod if serviceAccountName is set

When adding serviceAccountName and startupProbeto the pod template in my deployment, the resulting pods will not have a startup probe.

There is github issue about that.

Solution

This issue is being addressed here, currently it is still open and there is no specific answer for this.

As mentioned by @mcristina422

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

-- Jakub
Source: StackOverflow