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

how to handle un-running pod #97

Open
songbinliu opened this issue Sep 8, 2017 · 1 comment
Open

how to handle un-running pod #97

songbinliu opened this issue Sep 8, 2017 · 1 comment

Comments

@songbinliu
Copy link
Contributor

songbinliu commented Sep 8, 2017

In Kubernetes, pods can be in different phases: pending, running, and terminating. In addition, the containers in Pods may be in different status: running, waiting (because of CrashLoopBackOff).

Question Shall we only report the pods that are in running phase, and its containers are in running status?

In current implementation, we report all the running pods can be found by kuberentes.Pods().List() API.
However, in cases that some pods are in running phase, and its containers have been crashed, CPU/Memory usage metrics will be missing for these containers and pods. In these cases, should we set the CPU/Memory usage to be zero, or drop these kinds of Pods in discovery response? In current implementation, we drop the CPU/Memory commodities for the containers/Pods.

@songbinliu
Copy link
Contributor Author

Another case is that a pod is pending because of not enough resource, then this pod won't be reported to OpsMgr. In this case, OpsMgr will never do anything for this pending Pod.

pallavidn pushed a commit to pallavidn/kubeturbo that referenced this issue Mar 29, 2024
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

No branches or pull requests

1 participant