Define strategy to switch from kubernetes API to elasticsearch for logging
Update
Based on the below discussion, we agreed on the following #35604 (comment 245709143)
- ES is the default view for pod logs - if ES is not installed then we will present the current pod logs view using the Kubernetes APIs (with the drop-down for
Environment
,pods
and containers) - There should be an "escape hatch" (switch button) from moving from ES to Kubernetes API in the admin console #36561
- I will open an issue for K8s API log polling (however it is our of scope for now)
One additional comment: we'd worked on an empty state message as a part of #24088 (closed), with the suggested solution we should probably communicate to our users that ES option is available when they view the pod log via K8s API's.
Original issue
We should address the concern that we will soon have 2 ways to fetch logs:
- Today we support it through kubectl.
- Moving forward we will have Elasticsearch.
@adriel Mentioned we should stick to our availability over velocity prioritization – by having both until we are sure that we have full feature parity for all of our existing functionality.
Possible approaches to support a new elasticsearch based logs:
- Feature flag: Build the new elasticsearch logs support behind a feature flag, which would hide/show UI elements that are specific to elasticsearch. UI would be altered as well, as having, e.g. a search box is only possible with elasticsearch.
- UI based selection of source, with kubectl as default: Add a switching element, link to a separate page, to allow users to select which source of logs the would like to use. Using elasticsearch could be "opt-in" in the sense that users should actively decide to use the new feature, until we reach feature parity.
- another?: Other approaches?
WIP Proposal
- ES is not installed: transparently fall back to k8s with limited feature set, and display prompt to install ES for additional features
- ES is installed and not available: transparently fall back to k8s with limited feature set, and display error prompt to investigate availability
Let users know what's happening in both of these situations by utilizing alerts. In the first scenario, we could have an information alert letting users know that they can "upgrade" their experience by enabling Elasticsearch. In the second scenario, we can have a warning message letting users know that something isn't working right, and that they need to investigate further.
Effort impact
I think the engineering efforts of the first 2 approaches are similar, with a FF having a slightly bigger overhead.
End-goal
Once we are confident that elasticsearch can do everything we are currently doing with kubectl we can deprecate the kubectl UI.