I don’t entirely agree there. Even each individual container has resource limits set and those getting divided across multiple service processes can be saved if we end up running only a single service per container. Meaning no noise from other co running processes witin a container.
In other words, we can ensure that all the memory/cpu requested over the container config files are available to the single tenant service.
For eg:, FTS takes the benefits of any available file system cache from the operating system, and this could get compromised or challenged when other significant process are running in the system. eg: index/n1ql/kv etc within the same container. (My understanding is that - even page cache memory is accounted for the container’s overall memory usage by the container orchestrator platforms)
ref - https://docs.docker.com/config/containers/runmetrics/#metrics-from-cgroups-memory-cpu-block-io
With containers, page cache sharing across containers becomes tricky if different containers ends up accessing the same file on disk. But with CB services like N1QL/FTS/GSI chances are rare for that to happen. CB recommendations are container hostings are here - https://docs.couchbase.com/operator/2.0/best-practices.html#noisy-neighbors.
If you are using N1QL only for accessing FTS, then GSI/Index service isn’t even needed. You may disable that service itself.