docs: note inotify limits for scale test - #360
Conversation
✅ Deploy Preview for node-readiness-controller ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
|
Welcome @Daniel-1600! |
kubernetes-prow
Bot
added
cncf-cla: no
|
Hi @Daniel-1600. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubernetes-prow
Bot
added
size/S
| > watchers, etc.). The default Linux limit (`fs.inotify.max_user_instances`, | ||
| > often 128) is shared across your entire user session — desktop | ||
| > environment, editors, browsers, and other file-watching tools all draw | ||
| > from the same pool. On a typical dev machine, this budget can already be |
There was a problem hiding this comment.
| > from the same pool. On a typical dev machine, this budget can already be | |
| > from the same pool. On some dev environments, this budget can already be |
Is this specific to any Unix distro? I haven't experienced such issues for scaling more kind nodes in test environments. Also we use kwok for large scale testing (ref #284 )
There was a problem hiding this comment.
Its not really specific to any distro , it depends with inotify budget configured on your machine by default like for fedora max instances were set as 128 as default . but i tend to believe it depends with kernel version cause some other distros ship with a higher configuration (even fedora the one im on) can ship with higher default instances set
| > from the same pool. On a typical dev machine, this budget can already be | ||
| > significantly consumed before any kind nodes start, making it easy to | ||
| > hit `Failed to allocate manager object: Too many open files` when | ||
| > scaling to 3-4+ worker nodes. |
There was a problem hiding this comment.
| > scaling to 3-4+ worker nodes. | |
| > scaling to more worker nodes. |
|
/lgtm |
kubernetes-prow
Bot
added
the
lgtm
Signed-off-by: Daniel Mungai <chegedan699@gmail.com>
0b86c3b to
e781c38
Compare
kubernetes-prow
Bot
removed
the
lgtm
|
/lgtm |
kubernetes-prow
Bot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ajaysundark, Daniel-1600 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
the
approved
2 participants
Description
Adds a troubleshooting note to Step 9 (Autoscaling Simulation Test) in
DEMO_ENVIRONMENT_SETUP.md, documenting
inotifylimit issueencountered when scaling up to 4 kind worker nodes.
Related Issue
Type of Change
kind documentation
Testing
Manually reproduced and verified on a local Fedora dev machine:
kindscaler.sh nrr-test 2)to go from 2 to 4 worker nodes, with default
fs.inotify.max_user_instances=128.docker logs nrr-test-worker4showedFailed to allocate manager object: Too many open files.fs.inotify.max_user_instancesand
fs.inotify.max_user_watchesviasysctl).Step 9 (taint verification) completed as expected.
Checklist
make testpassesmake lintpassesDoes this PR introduce a user-facing change?
Doc #(issue)