Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable probe check on pods using serviceAccountName #518

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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.

None yet

2 participants