Enable Network Observability on Day 0 #1908
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/cc |
|
|
||
| Being able to manage and observe the network in an OpenShift cluster is critical in maintaining the health and integrity of the network. Without it, there’s no way to verify whether your changes are working as expected or whether your network is experiencing issues. | ||
|
|
||
| Currently, Network Observability is an optional operator that many customers are not aware of. A majority of customers using OpenShift Networking do not have Network Observability installed. Customers are missing out on features that they should have and have already paid for. |
There was a problem hiding this comment.
from telemetry, what's the percentage of clusters with NOO installed today?
|
|
||
| This adds the installNetworkObservability field in the Network CRD under the spec section. See Listing 2 above. | ||
|
|
||
| ### Topology Considerations |
There was a problem hiding this comment.
Single node OpenShift (SNO) clusters have strict requirements in terms of resource usage: is it ok that NOO gets installed by default in this case?
| ### Risks and Mitigations | ||
|
|
||
| * Network Observability requires CPU, memory, and storage that the customer might not be aware of. | ||
| Mitigation: The default setting stores only metrics at a high sampling interval to minimize the use of resources. If this isn’t sufficient, more fine-tuning and filtering can be done in the provided default configuration (e.g. filtering on specific interfaces only). |
There was a problem hiding this comment.
Single node OpenShift (SNO) clusters have strict requirements in terms of resource usage: is it ok that NOO gets installed by default in this case?
|
|
||
| ### Risks and Mitigations | ||
|
|
||
| * Network Observability requires CPU, memory, and storage that the customer might not be aware of. |
There was a problem hiding this comment.
Can we get an estimate of the overhead running NOO with a "stripped-down" flow collector on a typical CI cluster (3 control plane nodes + 3 workers)?
|
|
||
| Summary: | ||
|
|
||
| * Sampling at 400 |
There was a problem hiding this comment.
Does it depend on the in-cluster Prometheus stack? If yes how does it play with #1880?
|
|
||
| ### Topology Considerations | ||
|
|
||
| All topologies are supported where CNO is supported, so this excludes MicroShift. |
There was a problem hiding this comment.
Can we describe briefly how it works for HyperShift?
| 4. Wait for NOO to be ready and the OpenShift web console to be available. | ||
| 5. Create the "netobserv" namespace if it doesn't exist. | ||
| 6. Check if a FlowCollector instance exists. If yes, exit. | ||
| 7. Create a FlowCollector instance. |
There was a problem hiding this comment.
Concretely what gets deployed in terms of pods and services? Regarding pods, what level of customization is offered in terms of resource requests/limits and scheduling (infrastructure nodes)?
|
@stleerh: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| Rather than actually installing NOO and creating the FlowCollector instance, it is less risky and simpler to just display a panel or a button to let the user install and enable Network Observability. This resolves the awareness issue. However, by doing this, it will get much less installs compared to making it enabled by default. It goes against the principle that networking and network observability should always go hand in hand and be there from the start. | ||
|
|
||
| ## Alternatives (Not Implemented) |
There was a problem hiding this comment.
Was installation via the assisted-installer considered? https://github.com/openshift/assisted-service/blob/master/docs/dev/olm-operator-plugins.md
This seems like a viable option to mitigate the drawbacks around topologies and resource constraints.
|
|
||
| ## Motivation | ||
|
|
||
| Network Observability is an optional OLM operator that collects and stores traffic flow information and provides insights into your network traffic, including troubleshooting features like packet drops, latencies, DNS tracking, and more. |
There was a problem hiding this comment.
Which of this functionality applies to single node deployment?
4 participants
No description provided.