search

zegl / kube-score

Kubernetes object analysis with recommendations for improved reliability and security. kube-score actively prevents downtime and bugs in your Kubernetes YAML and Charts. Static code analysis for Kubernetes.
https://kube-score.com
MIT License
2.75k stars 177 forks source link

Enable probe check on pods using serviceAccountName #518

Open skunkworker opened 1 year ago

skunkworker commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.