[k8s docs] Update k8s docs to include how to ingest rotated container log files, including GZIP compressed

[AndersonQ]

Now that filebeat supports ingesting GZIP files, update all k8s related docs to explain how to ingest container rotated logs, including GZIP compressed ones.

As much as possible, point to filestream docs for details so all explanation about ingesting GZIP compressed files are in one single place.

Docs requiring changes:

• filebeat "run on k8s#log-rotation"
• filebeat run on k8s#autodiscover snippet - I think it should not be under OpenShift. I don't know if it's intentional or a mistake.
• filebeat deploy on k8s
• filebeat Log rotation results in lost or duplicate events (this is unrelated to k8s, but can profit from at least us mentioning we can read gzip files)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[AndersonQ]

@cmacknz, @nimarezainia FYI:

tl;dr:

When running Filebeat on Kubernetes without autodiscover, the add_kubernetes_metadata processor is used and it relies on log paths. Ingesting from /var/log/pods/ (instead of the default /var/log/containers/) will cause you to lose container-specific metadata. Using autodiscover or the Elastic Agent avoids this issue as the metadata is added to the input config.

At the end, this will require a more convoluted config to ingest rotated logs if the active log is still ingested from /var/log/containers. And longer docs to explain the situation and the difference to autodiscover.

---

the long version:

I discovered something interesting about running Filebeat on Kubernetes without autodiscover. When doing so, we configure (see below) the add_kubernetes_metadata processor.

beats/deploy/kubernetes/filebeat-kubernetes.yaml

Lines 127 to 131 in 08108e4

	- add_kubernetes_metadata:
	host: ${NODE_NAME}
	matchers:
	- logs_path:
	logs_path: "/var/log/containers/"

The add_kubernetes_metadata processor must be configured to match metadata with the event it's processing. By default, this is done using the log file path. It defaults to matching container metadata using the path /var/log/containers/, allowing the container ID to be extracted from the full path.

It is also possible to match pod metadata (using /var/log/pods/), but if this path is used, container-specific metadata (like container.name) is not available.

Thus, files ingested from /var/log/pods/ will miss the container metadata. This is consistent with the default behaviour of the OTEL Kubernetes Attributes Processor (though I haven't tested it to compare it with Filebeat).

On the other hand, when using autodiscover, the metadata is added directly in the input configuration instead of relying on the add_kubernetes_metadata processor. This means that when using autodiscover (or running Filebeat under the Elastic Agent), all metadata is available regardless of the log's origin path.

[AndersonQ]

@cmacknz, @nimarezainia if you wanna see what I planned for the docs:

The PR has a draft of what I'm planning for the docs. Once CI runs, #47384 (comment) should be updated with a live version on the docs on my PR