[Docs] Increase vm.max_map_count suggested value

[shainaraskas]

We want to recommend a higher vm.max_map_count for Elasticsearch environments - additional context in issue

What issues does this PR fix?

Part of https://github.com/elastic/docs-content-internal/issues/592

[prodsecmachine]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[pebrc]

I see another ~30 references to the old value in the examples in the code base that we should probably address https://github.com/search?q=repo%3Aelastic%2Fcloud-on-k8s%20262144&type=code

[shainaraskas]

@pebrc let me know if editing those recipes is overkill. I'll have to recreate the changes in main and backport them to the 3.x branches as well

[pebrc]

I did some testing on GKE Autopilot with the new values recommended in this PR. We have an issue here in that only the previously approved DaemonSet with the old value will be accepted. I think for this PR it means that we have to keep all the autopilot examples on the old value for the time being and make some adjustments to the virtual memory page to call out the special case.

I am also wondering why we are backporting this change to the 2.16 branch instead of just updating the main branch/docs-content with the new values. BTW for the current documentation in docs-content we have the same issue with GKE Autopilot.

[shainaraskas]

I am also wondering why we are backporting this change to the 2.16 branch instead of just updating the main branch/docs-content with the new values. BTW for the current documentation in docs-content we have the same issue with GKE Autopilot.

Fixing the issue in docs-content now (draft while we agree on language here: elastic/docs-content#4490).

Backporting was requested here, because ECK 2.16 supports the impacted versions of ES, 2.16 is still in support, and this setting is controlled at the ECK level. Not exactly sure why 2.16 was the only version targeted - @kunisen, can you provide some insight on that?

[kunisen]

Thanks @shainaraskas and @pebrc !

Backporting was requested https://github.com/elastic/docs-content-internal/issues/592, because ECK 2.16 supports the impacted versions of ES, 2.16 is still in support, and this setting is controlled at the ECK level. Not exactly sure why 2.16 was the only version targeted - @kunisen, can you provide some insight on that?

I don't have strong opinion here and this is my thought:

• ECK 2.16 and 3.x are the two versions we are actively maintaining, means for both code and docs. See EOL website page here.
• Other versions, although it's great to change the value, it might be hard for us to do all of them. (It happens to ECK that being able to run all 8.16+ versions, and that could also mean ECK 1.x version right? IIRC, there's no such ECK version and stack version compatibility limitation like we have in ECE)

Based on the above thoughts, the most cost-effective and also following EOL policy way is to do 2.16 and 3.x, IMHO.

---

FWIW, why 2.16 is the only maintained version? is because we only maintain that minor. Per EOL policy,

• For ECK 2.x, we maintain 2.16 (latest minor)
• For ECK 3.x, we maintain 3.2 and 3.1 (latest 2 minors)

For the version that is under support but not under maintenance per our EOL policy, such as ECK 1.9, I didn't include it as target.

---

@shainaraskas @pebrc if doc team or ECK team think we should expand it to more targets, I think the support team is more than happy to have that. But that might be an overkill as you said.

I will leave the decision to you since you are more authoritative teams than us :) thank you!

[pebrc]

LGTM (just one small correction)

[shainaraskas]

@pebrc I'm sorry to bug you again, but I'm blocked from merging as well (not sure if it's due to insufficient permissions, or some other conflict between my branch and this repo)

I've reopened the PR from a fork, but am running into the same issue

I also reached out in the channel because it looks like perhaps permissions to the repo have been changed

[pebrc]

Apologies for the delay. I merged your PR. We have additional branch protections on release branches, that prevent you from merging.