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

[github-actions]

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)

- 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 <plugin> then install --batch <plugin>).
    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 · 852 AIC · ⌖ 13.1 AIC · ⊞ 26.4K · ◷