-
Notifications
You must be signed in to change notification settings - Fork 471
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add network flows export support proposal
- Loading branch information
1 parent
0689995
commit de7baf5
Showing
1 changed file
with
92 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,92 @@ | ||
--- | ||
title: OpenShift Network Flow export and collection support | ||
authors: | ||
- "@rcarrillocruz" | ||
reviewers: | ||
- "@russellb" | ||
approvers: | ||
- TBD | ||
creation-date: 2021-01-11 | ||
last-updated: 2020-01-11 | ||
status: provisional | ||
--- | ||
|
||
# OpenShift NetFlow support | ||
|
||
## Release Signoff Checklist | ||
|
||
- [ ] Enhancement is `implementable` | ||
- [ ] Design details are appropriately documented from clear requirements | ||
- [ ] Test plan is defined | ||
- [ ] Graduation criteria for dev preview, tech preview, GA | ||
- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/) | ||
|
||
## Summary | ||
|
||
Collecting all traffic from a cluster at a packet level would be an enormous amount of data. | ||
An alternative approach for analysis of network traffic is to capture only metadata about the traffic in a cluster. | ||
This metadata would include information like the protocols, source and destination addresses, port numbers, and the amount of traffic. | ||
Collecting this metadata becomes a more manageable approach to getting visibility into network activity across the cluster. | ||
|
||
There are existing protocols for how this metadata is transmitted between systems, including NetFlow, IPFIX, and sFlow. | ||
Open vSwitch (OVS) supports these protocols and OVS is a fundamental building block of the OVN-Kubernetes network type. | ||
|
||
This proposal discusses how we start providing this functionality by allowing cluster administrators to enable the export of network flow metadata using one of these protocols. | ||
|
||
## Motivation | ||
|
||
* Cluster administrators need to be able to get network flows out of OpenShift to be consumed by their collectors. | ||
* Cluster administrators need to be able to see a log of the network traffic that flows thru OpenShift cluster. | ||
* Cluster administrators need to get metrics and monitoring data of the OpenShift cluster network traffic to make decisions on capacity and/or security issues. | ||
|
||
### Goals | ||
|
||
- Add support for exporting the network flows traffic in an OpenShift cluster by leveraging the NetFlow/sflow/IPFIX protocols supported by OVS. | ||
|
||
### Non-Goals | ||
|
||
- This document only applies to OVN-Kubernetes, not OpenShift SDN or any other other network plugin. | ||
- This document will not discuss the flow logs store solutions. Typically, customers store the NetFlow data in a data warehouse system (e.g. ClickHouse) or search and analytics system (e.g. ElasticSearch). It is out of the scope of this document to discuss which option should be used and if we should manage that solution. | ||
- This document will not discuss flow visualization or flow dashboards. | ||
|
||
## Proposal | ||
|
||
OVS supports NetFlow v5, IPFIX and sflow. | ||
NetFlow v5 does not support IPv6, thus it should not be considered as a default protocol | ||
sFlow is the most performant protocol as it is a sampling protocol, which polls periodically interfaces to get samples of packets. The drawback is that it does not capture all packets. | ||
IPFIX is capable of capturing all traffic at line rate and supports IPv6, therefore it should be the default protocol if this option is not specified. | ||
|
||
The Cluster Network Operator (CNO) should expose: | ||
* A *exportNetworkFlows* option to enable the export of network flows data from OVS bridges | ||
* A *exportNetworkFlowsProtocol* to specify which protocol should be used. Valid values should be *netflowV5*, *ipfix* and *sflow*, being the default ipfix. | ||
* A *exportNetworkFlowsCollectorIP* to specify the IP of the collector that will consume the flow data | ||
* A *exportNetworkFlowsCollectorPort* to specify the port of the collector that will consume the flow data | ||
|
||
Under the covers, these options will make the CNO to perform an ovs-vsctl command on the bridge br-int, which is the bridge the containers are connected to on OVN-Kubernetes, and its management port ovn-k8s-mp0. | ||
As an example, if sFlow was enabled this is the command that would be executed. | ||
|
||
`ovs-vsctl -- --id=@sflow create sflow agent=ovn-k8s-mp0 target="\"${exportNetworkFlowsCollectorIP}:{exportNetworkFlowsCollectorPort}\"" header=128 sampling=64 polling=10 -- set bridge br-int sflow=@sflow` | ||
|
||
### Test Plan | ||
|
||
- Unit tests for the feature | ||
- e2e tests covering the feature | ||
|
||
### Graduation Criteria | ||
|
||
From Tech Preview to GA | ||
|
||
#### Tech Preview -> GA | ||
|
||
- Ensure OpenShift can export network flows data off OVS to an endpoint | ||
- Ensure OpenShift bundled collector can log the network flows data off OVS | ||
|
||
### Upgrade / Downgrade Strategy | ||
|
||
N/A | ||
|
||
### Version Skew Strategy | ||
|
||
N/A | ||
|
||
## Implementation History |