Docs fix — coherence: path /deploy-manage/deploy/cloud-on-k8s — 2 findings

Generated by `gh-aw-docs-coherence-sweep` for `elastic/docs-content` on 2026-W24.

Path /deploy-manage/deploy/cloud-on-k8s · 94 total in scope · subtree corpus 94 pages.

## Findings (2)

```yaml
- file: deploy-manage/deploy/cloud-on-k8s/virtual-memory.md
line: 130
category: contradictory-content
severity: high
evidence: >
Line 130 shows an init container check `if [ ${mmc} -eq 262144 ]; then exit 0; fi`
described as working with the DaemonSet defined above it (line 98:
`echo 1048576 > /proc/sys/vm/max_map_count`). Because the DaemonSet sets
1048576, this check will never exit 0 for non-GKE-Autopilot environments.
The published GKE Autopilot page pairs the same 262144 check exclusively with
a GKE-Autopilot-specific DaemonSet (also 262144), confirming that the 262144
check value belongs only in the Autopilot context. Additionally, the GKE
Autopilot page states "Use the provided Daemonset exactly as specified, with
a vm.max_map_count value of 262144", which contradicts the virtual-memory.md
DaemonSet command that writes 1048576.
related_url: https://www.elastic.co/docs/deploy-manage/deploy/cloud-on-k8s/deploy-eck-on-gke-autopilot
suggested_fix: |
In virtual-memory.md, update the init container check at line 130 to check for
1048576 (matching the non-Autopilot DaemonSet that sets 1048576) rather than 262144.
Add a separate GKE-Autopilot-specific example that uses 262144 in both the DaemonSet
and the init container check. Treat the GKE Autopilot page as the authoritative source
for what value Autopilot requires (262144), and remove the ambiguous footnote pattern
in favour of two clearly scoped examples.

- file: deploy-manage/deploy/cloud-on-k8s/init-containers-for-plugin-downloads.md
line: 1
category: near-duplicate
severity: low
evidence: >
The entire page describes installing ES plugins via a Kubernetes init container
(bin/elasticsearch-plugin remove --purge then install --batch ).
The published custom-configuration-files-plugins page contains an identical section
("Use init containers for plugins installation") with the same YAML structure,
the same install/remove command pattern, and the same prose about inheriting the
main container image and volume mounts. Both pages are published as separate docs
under the same Elasticsearch configuration section.
related_url: https://www.elastic.co/docs/deploy-manage/deploy/cloud-on-k8s/custom-configuration-files-plugins
suggested_fix: |
Consolidate init-containers-for-plugin-downloads.md into the existing
"Use init containers for plugins installation" section of custom-configuration-files-plugins.md,
keeping any unique details (init container inheritance behaviour) in that section.
Replace init-containers-for-plugin-downloads.md with a redirect to the relevant
section anchor in custom-configuration-files-plugins, treating that page as the
canonical source for plugin and configuration installation options.
```

## Done when
- Duplicate content is consolidated or replaced with a cross-link.
- Contradictions are reconciled, with one page as source of truth.
- A PR addressing this issue is merged.

## Notes
- MCP calls succeeded for all sampled pages; no availability issues.
- Snippet files (`_snippets/`) were out of scope for direct comparison.

> Generated by [Docs coherence sweep agent](https://github.com/elastic/docs-content/actions/runs/27336211842) · 852 AIC · ⌖ 13.1 AIC · ⊞ 26.4K · [◷](https://github.com/search?q=repo%3Aelastic%2Fdocs-content+is%3Aissue+%22gh-aw-workflow-call-id%3A+elastic%2Fdocs-content%2Fgh-aw-docs-coherence-sweep%22&type=issues)