Skip to content

Conversation

@skunkworker
Copy link

If a pod uses serviceAccountName make sure the probes are being set, as if it's being targeted by a service normally.

RELNOTE: If a pod is using a serviceAccountName check probes

@zegl
Copy link
Owner

zegl commented Feb 28, 2023

Hey @skunkworker!

Could you please explain the rationale behind this change?

Except for the confusing names, Service Accounts and Services are not related to each other. Service Accounts are for authentication towards the Kubernetes API, and Services are for networking and service discovery.

@skunkworker
Copy link
Author

Thanks, I am still newer to k8s and did not understand the difference as much as I could've.

We have some deployments which are not http servers still are receiving TCP traffic (RPC, queue subscriptions, async workers etc), and thus are not being targeted by services, yet we still want their configuration to fail if they do not have probes setup.

Currently configured probes are both http and file stat based.

Is there a way to make sure probes are being required on those kind of non-http webserver processes?

@zegl
Copy link
Owner

zegl commented Feb 28, 2023

Aha, I see now.

So basically you're using a non-Service based Service Discovery, but still want enforcement of probes, to enable safe rollouts, and automatic restarts of containers, and so on.

It's not obvious exactly how to do this without introducing a lot of false positives (require pods where they have no effect), but I have some ideas:

One idea could be to require probes for apps (Deployments, StatefulSets, etc) that have more than 1 replica, as probes are used when rolling out updates. But it's not 100% clear if this is a good idea. An alternative path is to run the check if the app is targeted by a PodDisruptionBudget, as it's also powered by the status of the pod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants