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

Investigate possibility of fork bomb on provider clusters #230

Open
cloud-j-luna opened this issue Jun 5, 2024 · 0 comments
Open

Investigate possibility of fork bomb on provider clusters #230

cloud-j-luna opened this issue Jun 5, 2024 · 0 comments
Assignees
Labels
P2 repo/provider Akash provider-services repo issues

Comments

@cloud-j-luna
Copy link
Member

Kubernetes by default is not protected against a "fork bomb". A "fork bomb" would essentially be a Pod spawning many processes to the point other workloads get impacted because the controllers will no longer be able to create Pods and they'll be stalled. It could theoretically crash the node. This happens because pods share the host kernel settings. A badly designed application that doesn't clean spawned child processes can easily cause a node to crash because of this.
This issue is to investigate if this is an issue that can happen and how we can limit the impact and protect providers as much as possible.

To Reproduce
One way to test this would be to create a simple application that infinitely spawns processes to check if a crash happens.

Additional context
To check the maximum number of pids run:

cat /proc/sys/kernel/pid_max

The limit on pids can be set on the kubelet configuration.

@chainzero chainzero added P2 repo/provider Akash provider-services repo issues and removed awaiting-triage labels Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 repo/provider Akash provider-services repo issues
Projects
None yet
Development

No branches or pull requests

3 participants