diff --git a/docs/en/networking/assets/netobserv-cli-flows-tui.png b/docs/en/networking/assets/netobserv-cli-flows-tui.png deleted file mode 100644 index cc165060a..000000000 Binary files a/docs/en/networking/assets/netobserv-cli-flows-tui.png and /dev/null differ diff --git a/docs/en/networking/assets/netobserv-cli-packets-tui.png b/docs/en/networking/assets/netobserv-cli-packets-tui.png deleted file mode 100644 index abca69c84..000000000 Binary files a/docs/en/networking/assets/netobserv-cli-packets-tui.png and /dev/null differ diff --git a/docs/en/networking/assets/netobserv-cli-packets-wireshark.png b/docs/en/networking/assets/netobserv-cli-packets-wireshark.png deleted file mode 100644 index 99899f771..000000000 Binary files a/docs/en/networking/assets/netobserv-cli-packets-wireshark.png and /dev/null differ diff --git a/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx b/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx index ab19ebba1..fc9cb8902 100644 --- a/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx +++ b/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx @@ -106,6 +106,11 @@ Before creating the gateway, prepare the following resources: - An external subnet - A Network Attachment Definition (NAD) for that subnet +:::note + The NetworkAttachmentDefinition name MUST NOT contain a dot (`.`). + Each NetworkAttachmentDefinition can be used by only one subnet. Do not reuse the same NetworkAttachmentDefinition across multiple subnets. +::: + The following example uses a Kube-OVN underlay subnet as the external network. :::note @@ -428,6 +433,50 @@ Routing Policies 29000 ip4.src == $subnet1.kube.ovn.worker_ip4 reroute 100.64.0.4 ``` +### Optional: Configure Bandwidth Limits + +To limit the bandwidth of selected namespaces or workloads, set _.spec.bandwidth.ingress_ and _.spec.bandwidth.egress_. +Each field accepts one of the following formats: + +- A non-negative integer or numeric string, interpreted as Mbps. For example, `2000` and `"2000"` both mean 2000 Mbps. +- A Kubernetes quantity string with the `M`, `Mi`, `G`, or `Gi` suffix, interpreted as bits per second. Decimal values are supported when a suffix is present. The value is rounded up to the nearest whole Mbps. For example, `1Gi` becomes 1074 Mbps. + +Omit a field or set it to `0` to leave that direction unlimited. The limits apply to each gateway instance. + +:::note + If _.spec.replicas_ is greater than 1, each replica gets the configured limit. + Quantity strings require a VPC Egress Gateway CRD and controller version that supports them. During a rolling upgrade, continue to use integer Mbps values until the Kube-OVN upgrade is complete. +::: + +The following example limits the selected namespaces to 2 Gbps ingress bandwidth and 4 Gbps egress bandwidth: + +```yaml +apiVersion: kubeovn.io/v1 +kind: VpcEgressGateway +metadata: + name: gateway-bandwidth + namespace: default +spec: + replicas: 1 + internalSubnet: ovn-default + externalSubnet: underlay-ext + externalIPs: + - 172.17.0.21 + bandwidth: + ingress: 2G + egress: 4G + selectors: + - namespaceSelector: + matchExpressions: + - key: kubernetes.io/metadata.name + operator: In + values: + - ecommerce + - ecommerce-test +``` + +In this example, the direction is relative to the selected namespaces or workloads: `ingress` limits traffic from the external network to them, and `egress` limits traffic from them to the external network. + ### Optional: Enable BFD-based High Availability BFD-based failover depends on the VPC BFD LRP. diff --git a/docs/en/networking/how_to/kube_ovn/multiple_networks.mdx b/docs/en/networking/how_to/kube_ovn/multiple_networks.mdx index 7fbf15e92..ad023ffa3 100644 --- a/docs/en/networking/how_to/kube_ovn/multiple_networks.mdx +++ b/docs/en/networking/how_to/kube_ovn/multiple_networks.mdx @@ -46,6 +46,9 @@ Example: `network-attachment-definition.yml` :::note The provider format in config is `..ovn`, where `` and `` are the name and namespace of this NetworkAttachmentDefinition CR respectively. +The NetworkAttachmentDefinition name MUST NOT contain a dot (`.`). +Each NetworkAttachmentDefinition can be used by only one subnet. Do not reuse the same NetworkAttachmentDefinition across multiple subnets. + If you use an underlay secondary network, set `spec.vlan` in the Subnet to the target VLAN CR name. ::: diff --git a/docs/en/networking/observability/cli-usage.mdx b/docs/en/networking/observability/cli-usage.mdx deleted file mode 100644 index 02ce20462..000000000 --- a/docs/en/networking/observability/cli-usage.mdx +++ /dev/null @@ -1,310 +0,0 @@ ---- -weight: 40 ---- - -# Use the CLI - -The CLI can run as a standalone tool or as a kubectl plugin. -You can copy it from the netobserv-controller-manager pod to your local machine. - -Use the CLI for on-demand troubleshooting when you want to inspect packets or flows for a limited period. -It supports these two modes: - -- TUI mode, which displays captured traffic in real time for interactive inspection -- Background mode, which starts a capture task and lets it continue until it reaches the configured stop condition or is stopped manually - -Both modes support exporting capture results for offline analysis. - -## Copy the CLI - -Example: - -```bash -# Get name of the NetObserv Controller Manager pod -CONTROLLER_POD=$(kubectl get pods -n netobserv-operator -l app=netobserv-operator -o jsonpath="{.items[0].metadata.name}") -# Copy the CLI from the controller manager pod to your local machine -kubectl cp netobserv-operator/$CONTROLLER_POD:/kubectl-netobserv /usr/local/bin/kubectl-netobserv -# Make the CLI executable -chmod +x /usr/local/bin/kubectl-netobserv -# Verify that the CLI is working -kubectl netobserv help -``` - -## Install or Copy yq - -The CLI requires __yq__ on your local machine to modify YAML files. -If yq is not installed locally, you can copy the binary from the netobserv-controller-manager pod. - -```bash -# Copy yq from the controller manager pod to your local machine -kubectl cp netobserv-operator/$CONTROLLER_POD:/yq /usr/local/bin/yq -# Make yq executable -chmod +x /usr/local/bin/yq -# Verify that yq is working -yq --version -``` - -:::note -The CLI uses some images packaged in the NetObserv Operator, but it does not require the NetObserv Operator to be installed to work. -After you prepare the CLI, you can uninstall the NetObserv Operator if you no longer need it. The CLI will continue to work. -::: - -## View the Help Message - -Before you start a capture task, review the available commands: - -```bash -# Get help message for the CLI -kubectl netobserv help -# Get help message for packet capture command -kubectl netobserv packets help -# Get help message for flow capture command -kubectl netobserv flows help -``` - -## Capture Packets - -Packet capture records raw packets that match the filters you specify. -Use packet capture when you need full packet details instead of summarized flow records. - -:::note -If a packet length is greater than 256 bytes, the packet will be truncated in the capture results. -::: - -The captured packets can be exported to a pcapng file for offline analysis with tools like Wireshark. - -Example in Wireshark: - -![Wireshark](../assets/netobserv-cli-packets-wireshark.png) - -:::note -The captured packets are not sorted by timestamp in the pcapng file, so you may need to sort the packets by timestamp in Wireshark to analyze the packet flow. -::: - -The packet comments include metadata such as node IP, interface name, and Kubernetes resource information. -Example packet comments: - -```txt -Source - Source - Src IP: 192.0.2.10 - Src Node IP: 192.0.2.10 - Src Node Name: node-a - Src Name: node-a - Src Network Name: primary - Src Owner: node-a - Src Owner Kind: Node - Src Kind: Node - Src MAC: 02:00:00:00:00:10 - Src Port: 36408 -Destination - Destination - Dst IP: 198.51.100.77 - Dst Node IP: 192.0.2.20 - Dst Node Name: node-b - Dst Name: kube-ovn-pinger-js87q - Dst Namespace: kube-system - Dst Network Name: ovn-default - Dst Owner: kube-ovn-pinger - Dst Owner Kind: DaemonSet - Dst Kind: Pod - Dst MAC: 02:00:00:00:00:20 - Dst Port: 8080(http-alt) -Common - Common - Bytes: 145B - TCP Flags: PSH - Node Dir: Egress - L4 Protocol: TCP - Length: 145 - AgentIP: 192.0.2.10 - InterfaceIndex: 7 - InterfaceName: ovn0 - InterfaceDirection: Egress -``` - -You can filter packets in Wireshark based on these comments. -Example filter by node IP and interface name: - -```txt -frame.comment == "AgentIP: 192.0.2.10" && frame.comment == "InterfaceName: ovn0" -``` - -In Kube-OVN overlay networking, packets between pods on different nodes are encapsulated with Geneve or VxLAN. -The original packet is carried as the payload of the Geneve or VxLAN packet. -To capture encapsulated traffic, use `--enable_geneve` or `--enable_vxlan` when running the packet capture command. - -Example command for capturing TCP packets on port 8080, including Geneve-encapsulated packets: - -```bash -kubectl netobserv packets --enable_geneve --protocol=TCP --port=8080 -``` - -### Run Packet Capture in TUI Mode - -Example command for TUI mode: - -```bash -kubectl netobserv packets --cidr=198.51.100.77/32 --peer_ip=192.0.2.10 --protocol=TCP --port=8080 -``` - -This command captures packets that match the specified filters and displays them in TUI mode. - -Example TUI interface: - -![Packet Capture TUI](../assets/netobserv-cli-packets-tui.png) - -Press _CTRL+C_ to exit TUI mode and stop the packet capture. -By default, the CLI will ask you whether to export the captured packets to a pcapng file after you exit TUI mode. -You can use the `--copy` flag to save the pcapng file automatically without confirmation. - -### Run Packet Capture in Background Mode - -Example command for background mode: - -```bash -kubectl netobserv packets --background --cidr=198.51.100.77/32 --peer_ip=192.0.2.10 --protocol=TCP --port=8080 -``` - -This command starts a packet capture task in the background that captures packets matching the specified filters. - -To copy captured packets to a pcapng file in background mode, run: - -```bash -kubectl netobserv copy -``` - -When the capture task is stopped or finished, you can use the `cleanup` command to remove the background capture task and free up resources. - -```bash -kubectl netobserv cleanup -``` - -## Capture Flows - -Flow capture records summarized network flow data instead of raw packets. -Use it when you want traffic metadata and flow statistics rather than full packet payloads. - -The usage of flow capture is similar to packet capture, but the results are exported in JSON and SQLite format instead of pcapng. - -Example command: - -```bash -kubectl netobserv flows --cidr=198.51.100.77/32 --peer_ip=192.0.2.10 --protocol=TCP --port=8080 -``` - -Example TUI interface: - -![Flow Capture TUI](../assets/netobserv-cli-flows-tui.png) - -Example exported flow record in formatted JSON: - -```json -[ - { - "AgentIP": "192.0.2.10", - "Bytes": 611, - "Dscp": 0, - "DstAddr": "2001:db8:1::77", - "DstK8S_HostIP": "192.0.2.20", - "DstK8S_HostName": "node-b", - "DstK8S_Name": "kube-ovn-pinger-2w2qp", - "DstK8S_Namespace": "kube-system", - "DstK8S_NetworkName": "ovn-default", - "DstK8S_OwnerName": "kube-ovn-pinger", - "DstK8S_OwnerType": "DaemonSet", - "DstK8S_Type": "Pod", - "DstMac": "02:00:00:00:00:20", - "DstPort": 8080, - "Etype": 34525, - "Flags": 530, - "FlowDirection": 2, - "IfDirections": [ - 1, - 1 - ], - "Interfaces": [ - "ovn0", - "211daf442f8b_h" - ], - "Packets": 6, - "Proto": 6, - "Sampling": 1, - "SrcAddr": "2001:db8:1::10", - "SrcK8S_HostIP": "192.0.2.10", - "SrcK8S_HostName": "node-a", - "SrcK8S_Name": "kube-ovn-cni-zgjhs", - "SrcK8S_Namespace": "kube-system", - "SrcK8S_NetworkName": "primary", - "SrcK8S_OwnerName": "kube-ovn-cni", - "SrcK8S_OwnerType": "DaemonSet", - "SrcK8S_Type": "Pod", - "SrcMac": "02:00:00:00:00:10", - "SrcPort": 59848, - "TimeFlowEndMs": 1775701945802, - "TimeFlowStartMs": 1775701945799, - "TimeReceived": 1775701946 - }, - { - "AgentIP": "192.0.2.10", - "Bytes": 509, - "Dscp": 0, - "DstAddr": "2001:db8:1::10", - "DstK8S_HostIP": "192.0.2.10", - "DstK8S_HostName": "node-a", - "DstK8S_Name": "kube-ovn-cni-zgjhs", - "DstK8S_Namespace": "kube-system", - "DstK8S_NetworkName": "primary", - "DstK8S_OwnerName": "kube-ovn-cni", - "DstK8S_OwnerType": "DaemonSet", - "DstK8S_Type": "Pod", - "DstMac": "02:00:00:00:00:30", - "DstPort": 59848, - "Etype": 34525, - "Flags": 784, - "FlowDirection": 2, - "IfDirections": [ - 0, - 0 - ], - "Interfaces": [ - "211daf442f8b_h", - "ovn0" - ], - "Packets": 4, - "Proto": 6, - "Sampling": 1, - "SrcAddr": "2001:db8:1::77", - "SrcK8S_HostIP": "192.0.2.20", - "SrcK8S_HostName": "node-b", - "SrcK8S_Name": "kube-ovn-pinger-2w2qp", - "SrcK8S_Namespace": "kube-system", - "SrcK8S_NetworkName": "ovn-default", - "SrcK8S_OwnerName": "kube-ovn-pinger", - "SrcK8S_OwnerType": "DaemonSet", - "SrcK8S_Type": "Pod", - "SrcMac": "02:00:00:00:00:40", - "SrcPort": 8080, - "TimeFlowEndMs": 1775701945802, - "TimeFlowStartMs": 1775701945800, - "TimeReceived": 1775701946 - } -] -``` - -Example exported flow records in SQLite: - -```shell -$ sqlite3 2026-04-09T022936Z.db \ - "SELECT SrcAddr, SrcPort, DstAddr, DstPort, Proto, Packets, Bytes FROM flow;" -╭───────────────────────┬─────────┬───────────────────────┬─────────┬───────┬─────────┬───────╮ -│ SrcAddr │ SrcPort │ DstAddr │ DstPort │ Proto │ Packets │ Bytes │ -╞═══════════════════════╪═════════╪═══════════════════════╪═════════╪═══════╪═════════╪═══════╡ -│ 2001:db8:1::10 │ 59848 │ 2001:db8:1::77 │ 8080 │ 6 │ 6 │ 611 │ -│ 2001:db8:1::77 │ 8080 │ 2001:db8:1::10 │ 59848 │ 6 │ 4 │ 509 │ -╰───────────────────────┴─────────┴───────────────────────┴─────────┴───────┴─────────┴───────╯ -``` - -## Additional Resources - -- [eBPF - Introduction, Tutorials & Community Resources](https://ebpf.io/) \ No newline at end of file diff --git a/docs/en/networking/observability/index.mdx b/docs/en/networking/observability/index.mdx index 08c2fd2c1..a957cfb99 100644 --- a/docs/en/networking/observability/index.mdx +++ b/docs/en/networking/observability/index.mdx @@ -4,4 +4,6 @@ weight: 70 # Network Observability - \ No newline at end of file +Network Observability provides continuous cluster-wide network flow collection and on-demand packet or flow capture for troubleshooting. It uses eBPF to inspect traffic behavior, identify performance issues, and investigate connectivity problems between workloads. + + diff --git a/docs/en/networking/observability/operator-deployment.mdx b/docs/en/networking/observability/operator-deployment.mdx deleted file mode 100644 index 7ff4c07e5..000000000 --- a/docs/en/networking/observability/operator-deployment.mdx +++ /dev/null @@ -1,284 +0,0 @@ ---- -weight: 30 ---- - -# Deploy with the Operator - -To enable continuous network flow collection, you need: - -1. A reachable ClickHouse server for storing flow logs -2. The NetObserv Operator -3. A FlowCollector instance - -The ClickHouse backend can be prepared in either of these ways: - -- Use an existing ClickHouse server and provide its connection information in the FlowCollector configuration -- Deploy a new ClickHouse instance in the cluster by using the ClickHouse Operator - -## Choose a ClickHouse Deployment Option - -Choose one of the following approaches before you create the FlowCollector instance: - -- Existing ClickHouse server: Use this option if you already have a ClickHouse deployment that FlowCollector can access. -- New in-cluster ClickHouse instance: Use this option if you want to deploy ClickHouse in the cluster with the ClickHouse Operator. - -If you use an existing ClickHouse server, prepare these values in advance: - -- ClickHouse service address in `host:port` format -- Database name for flow logs -- Username and password for ClickHouse authentication -- The namespace that will be used in `.spec.namespace` of the FlowCollector - -## Optional: Deploy ClickHouse with the ClickHouse Operator - -If you already have a ClickHouse server for NetObserv, skip this section and go to [Install the NetObserv Operator](#install-the-netobserv-operator). - -### Install the ClickHouse Operator - -1. Navigate to __Administrator__ > __Marketplace__ > __OperatorHub__. - -2. Search for "ClickHouse" and locate the ClickHouse Operator provided by . - -3. If the ClickHouse Operator status is _Absent_, upload the ClickHouse Operator package that you downloaded from the __ Customer Portal__. - -4. Click on the ClickHouse Operator to open the details page. - -5. On the operator details page, click __Install__. - -6. Fill in the configuration parameters as needed. - -7. Click __Install__ to start the installation. - -8. Confirm the installation by clicking __Confirm__ in the pop-up dialog. - -9. Wait for the installation to complete. - -:::note -If the ClickHouse Operator provided by is already installed, skip this section and go directly to creating a ClickHouse cluster for NetObserv. -::: - -### Create a ClickHouseInstallation Instance - -1. In the ClickHouse Operator details page, navigate to the __All Instances__ page and click __Create__. - -2. In the pop-up dialog, click __Create__ in the __ClickHouseInstallation__ section. - -3. In the __Create ClickHouseInstallation__ page, click __YAML__ on the top right corner to switch to YAML editing mode. - -4. Edit the YAML file as needed and click __Create__ to create the ClickHouseInstallation instance. - -Example ClickHouseInstallation YAML: - -```yaml -apiVersion: clickhouse.altinity.com/v1 -kind: ClickHouseInstallation -metadata: - name: netobserv - namespace: cpaas-system -spec: - configuration: - files: - disable-trace-log: | - - - - - - - - - - clusters: - - layout: - replicasCount: 1 - shardsCount: 1 - name: replicated - users: - clickhouse_root/networks/ip: - - 127.0.0.1 - - 0.0.0.0/0 - - ::/0 - clickhouse_root/password_sha256_hex: - defaults: - templates: - dataVolumeClaimTemplate: default - logVolumeClaimTemplate: log-volume-template - podTemplate: clickhouse:25.8 - templates: - podTemplates: - - name: clickhouse:25.8 - podDistribution: - - type: ShardAntiAffinity - spec: - containers: - - command: - - clickhouse-server - - --config-file=/etc/clickhouse-server/config.xml - env: - - name: CLICKHOUSE_DO_NOT_CHOWN - value: "1" - image: build-harbor.alauda.cn/middleware/clickhouse-server:v25.8.16.34-61a7880e - name: clickhouse-pod - resources: - limits: - cpu: "2" - memory: 4Gi - requests: - cpu: "1" - memory: 2Gi - securityContext: - readOnlyRootFilesystem: true - securityContext: - fsGroup: 101 - runAsGroup: 101 - runAsNonRoot: true - runAsUser: 101 - volumeClaimTemplates: - - name: default - spec: - storageClassName: sc-topolvm - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 80Gi - - name: log-volume-template - spec: - storageClassName: sc-topolvm - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 15Gi -``` - -After the ClickHouse instance is ready, get the service endpoint by inspecting field `.status.endpoint` of the ClickHouseInstallation instance. -You can also run the following command to get the endpoint: - -```bash -kubectl -n cpaas-system get chi netobserv -o jsonpath="{.status.endpoint}" -``` - -`cpaas-system` and `netobserv` in the command must match the namespace and name of the ClickHouseInstallation instance respectively. -If you use a different namespace or name, replace `cpaas-system` and `netobserv` in the command accordingly. - -Record the ClickHouse endpoint address and credentials for later use. -You will need this information when you create the FlowCollector instance. - -## Install the NetObserv Operator \{#install-the-netobserv-operator} - -1. Navigate to __Administrator__ > __Marketplace__ > __OperatorHub__. - -2. Search for "__Alauda Container Platform Network Observability Operator__". - -3. Click __Install__ to open the installation configuration page. - -4. Fill in the configuration parameters as needed. - -5. Click __Install__ to start the installation. - -6. Confirm the installation by clicking __Confirm__ in the pop-up dialog. - -7. Wait for the installation to complete. - -## Create the ClickHouse Authentication Secret - -Before you create the FlowCollector instance, create a Kubernetes secret for ClickHouse authentication. - -This secret is referenced by `.spec.clickhouse.authSecret.name` in the FlowCollector configuration. - -1. Create a local file named _ck-auth.env_ with the following content: - - ```ini - username= - password= - ``` - -2. Create the Kubernetes secret: - - ```bash - # Create namespace if it does not exist - test ! -n "$(kubectl get ns netobserv --ignore-not-found -o name)" && kubectl create ns netobserv - # Create the secret from the environment file - kubectl -n netobserv create secret generic ck-auth --from-env-file=./ck-auth.env - ``` - -In this command, `netobserv` must match the value of `.spec.namespace` in the FlowCollector configuration. - -If you use a different namespace in the FlowCollector configuration, replace `netobserv` in the command accordingly. - -## Create a FlowCollector Instance - -Before creating the FlowCollector instance, confirm that: - -- The ClickHouse server is reachable from the cluster -- The `ck-auth` secret exists in the namespace specified by `.spec.namespace` -- The ClickHouse address, database, and credentials are correct - -Then create the FlowCollector instance: - -1. Navigate to the __All Instances__ page and click __Create__. - -2. In the pop-up dialog, click __Create__ in the __FlowCollector__ section. - -3. In the __Create FlowCollector__ page, click __YAML__ on the top right corner to switch to YAML editing mode. - -4. Edit the YAML file as needed and click __Create__ to create the FlowCollector instance. - -Example FlowCollector YAML: - -```yaml -apiVersion: flows.netobserv.io/v1beta2 -kind: FlowCollector -metadata: - name: cluster -spec: - agent: - ebpf: - features: # [!code callout] - - DNSTracking - - FlowRTT - - PacketTranslation - - TLSTracking - metrics: - enable: false - sampling: 50 # [!code callout] - type: eBPF - clickhouse: - addresses: # [!code callout] - - clickhouse-netobserv.cpaas-system.svc.cluster.local:9000 - authSecret: - name: ck-auth # [!code callout] - database: netobserv # [!code callout] - enable: true - protocol: native - readTimeout: 30s - retention: 24h # [!code callout] - writeBatchSize: 128 - writeBatchWait: 1s - writeTimeout: 10s - deploymentModel: Service - namespace: netobserv # [!code callout] - processor: - consumerReplicas: 1 # [!code callout] - logTypes: Flows - service: - tlsType: Disabled -``` - - - -1. Enabled features of the eBPF agent. -2. Sampling interval of the eBPF probe. A value of 100 means that 1 out of every 100 packets is sampled. A value of 0 or 1 means that all packets are sampled. -3. ClickHouse server addresses. Use the `host:port` format. These addresses can point to a ClickHouse instance created in the cluster or to an existing external ClickHouse server. -4. ClickHouse authentication secret. The secret __MUST__ contain two keys: `username` and `password`. The secret must be created in the same namespace specified by `.spec.namespace`. -5. Database name in ClickHouse for storing flow logs. If the database does not exist, it is created automatically. -6. Data retention period in ClickHouse. Use a number followed by a time unit, for example `24h`. This setting takes effect only when the ClickHouse table is created. -7. Namespace where the eBPF agents and the flow logs pipeline are deployed. -8. Number of replicas for the flow logs pipeline. - - - -If you are using an existing ClickHouse server, make sure that the FlowCollector can reach the server address and that the referenced secret contains valid credentials. - -After the FlowCollector instance is created, the eBPF agents and the flow logs pipeline are deployed to the namespace specified by `.spec.namespace`. \ No newline at end of file diff --git a/docs/en/networking/observability/overview.mdx b/docs/en/networking/observability/overview.mdx deleted file mode 100644 index bb388881f..000000000 --- a/docs/en/networking/observability/overview.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -weight: 10 ---- - -# Overview - -## About Network Observability - -In Container Platform, network observability is provided by __NetObserv__. -NetObserv uses eBPF to capture network data and help you inspect traffic behavior, identify performance issues, and troubleshoot connectivity problems. - -Use Network Observability when you need to: - -- Monitor network traffic continuously across the cluster -- Debug network issues with detailed packet or flow data -- Investigate connectivity or latency issues between workloads -- Capture packets or flows for offline analysis - -NetObserv includes these main components: - -- An eBPF agent that runs on cluster nodes and captures packets or flow data -- A flow logs pipeline that enriches and exports flow logs -- A CLI that supports on-demand packet capture and flow capture - -You can use NetObserv in either of these ways: - -- Deploy the operator to collect and store cluster-wide flow logs continuously -- Use the CLI to capture packets or flows for troubleshooting and export the results for offline analysis - -Choose the operator-based deployment if you need continuous, cluster-wide visibility. -Choose the CLI if you need short-term troubleshooting without changing the long-running collection setup. - -## Recommended Workflow - -For most deployments, follow this order: - -1. Review [Prerequisites](./prerequisites.mdx) and verify kernel requirements. -2. Download and upload the NetObserv Operator package. -3. Prepare a ClickHouse backend. -4. Install the NetObserv Operator. -5. Create the ClickHouse authentication secret. -6. Create the FlowCollector instance. -7. Use the [CLI](./cli-usage.mdx) when you need packet or flow capture for troubleshooting. - -## Operator Deployment Architecture - -When deployed with the NetObserv Operator, the eBPF agents run as DaemonSets on Kubernetes nodes to collect network flow logs. -The flow logs pipeline runs as a Deployment, enriches the collected data with Kubernetes metadata, and exports it to ClickHouse for storage and analysis. - -The following diagram shows the high-level architecture of NetObserv deployed with the NetObserv Operator: - -```mermaid -flowchart LR - subgraph Nodes[Kubernetes Nodes] - A1[eBPF Agent] - A2[eBPF Agent] - A3[eBPF Agent] - end - - subgraph Pipeline[Flowlogs Pipeline] - P[Flowlogs Pipeline] - end - - subgraph Storage[Data Storage] - CH[ClickHouse Server] - end - - subgraph K8s[Kubernetes Control Plane] - API[Kubernetes API] - end - - A1 -->|Sends network flow logs| P - A2 -->|Sends network flow logs| P - A3 -->|Sends network flow logs| P - API -.->|Fetches metadata| P - P -->|Writes enriched flow logs| CH -``` - -## CLI Architecture - -The CLI is a shell script that can run as a standalone tool or as a kubectl plugin. -It can capture packets or flows and export the results to files for further analysis. - -The following diagram shows the high-level architecture of the NetObserv CLI: - -```mermaid -flowchart LR - subgraph Nodes[Kubernetes Nodes] - A1[eBPF Agent] - A2[eBPF Agent] - A3[eBPF Agent] - end - - subgraph Control[Kubernetes Control Plane] - API[Kubernetes API] - end - - subgraph Central[Kubernetes Node] - Collector[Collector Pod] - end - - subgraph Shell[Shell / TUI] - CLI[CLI Command] - end - - API -.->|Fetches metadata| A1 - API -.->|Fetches metadata| A2 - API -.->|Fetches metadata| A3 - - A1 -->|Sends enriched packets| Collector - A2 -->|Sends enriched packets| Collector - A3 -->|Sends enriched packets| Collector - - CLI -->|Interacts with & exports results| Collector -``` \ No newline at end of file diff --git a/docs/en/networking/observability/prerequisites.mdx b/docs/en/networking/observability/prerequisites.mdx deleted file mode 100644 index 544824d4e..000000000 --- a/docs/en/networking/observability/prerequisites.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -weight: 20 ---- - -# Prerequisites - -Before you deploy Network Observability, make sure that you have: - -- Access to the platform as an administrator -- The NetObserv Operator package, which is installed in the fixed namespace `netobserv-operator` -- A reachable ClickHouse server, either existing or newly deployed -- ClickHouse credentials that can be stored in a Kubernetes secret - -## Kernel Requirements - -The minimum kernel version for the eBPF agent is 5.14. - -On Ubuntu, the _kernel.perf_event_paranoid_ parameter must be set to 3 or lower. -This allows unprivileged processes to use the _perf_event_open()_ system call, which is required by the eBPF agent. - -To check the current value, run: - -```bash -sysctl kernel.perf_event_paranoid -``` - -If the value is greater than 3, set it to 3: - -```bash -sysctl -w kernel.perf_event_paranoid=3 -``` - -To make this change persistent, add the following line to _/etc/sysctl.conf_: - -```ini -kernel.perf_event_paranoid=3 -``` - -## Prepare the NetObserv Operator Package - -Before installing the operator, obtain the NetObserv Operator package and upload it to the platform. - -### Download the Package - -Visit the __ Customer Portal__ to download the NetObserv Operator package. - -If you don't have access to the __ Customer Portal__, contact technical support. - -### Upload the Package - -Use the __violet__ tool to publish the package to the platform. - -For detailed instructions on using this tool, refer to [Upload Packages](../../extend/upload_package). \ No newline at end of file diff --git a/sites.yaml b/sites.yaml index b70dd8c20..2eb76a8b9 100644 --- a/sites.yaml +++ b/sites.yaml @@ -152,6 +152,13 @@ base: /gitops version: "4.3" repo: https://github.com/alauda/gitops-docs +- name: network-observability-operator + displayName: + en: Alauda Container Platform Network Observability Operator + zh: Alauda Container Platform Network Observability Operator + base: /network-observability-operator + version: "1.11" + repo: https://github.com/alauda/network-observability-operator-docs - name: hosted-control-plane displayName: en: Hosted Control Plane