Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to Quarkus Roq #2

Merged
merged 25 commits into from
Nov 28, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
import all blog posts
  • Loading branch information
jotak committed Nov 18, 2024
commit 3b6ca22a68c0a78cfb98d3d727331b62dce857da
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
data/*.json
old/
.quarkus
target/
131 changes: 131 additions & 0 deletions content/posts/2022-12-12-3d_topology.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,131 @@
---
layout: :theme/post
title: "3D Topology"
description: "Ways to display your Kubernetes / OpenShift network flows"
image: https://images.unsplash.com/photo-1458501534264-7d326fa0ca04?q=80&w=3540&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D
tags: blogging
author: jpinsonneau
---

# Ways to display your Kubernetes / OpenShift network flows

By: Julien Pinsonneau

Red Hat OpenShift Container Platform (OCP) has had monitoring capabilities from the start and [Network Observability as Developer Preview](https://cloud.redhat.com/blog/a-guide-to-providing-insight-with-network-observability) since OCP 4.10 release.

Network Observability brings user interfaces in OpenShift web console administration to filter and visualize your cluster network flows as:

- Graph (top 5 flow rates stacked with total example)
![Graph example]({page.image('3d_topology/graph.png')})

- Table (showing sources and destinations sorted by time)
![Table example]({page.image('3d_topology/table.png')})

- Topology (using directed graph layout)
![Topology example]({page.image('3d_topology/topology.png')})

If you are interested in Network Observability for your cluster, check [official documentation for installation](https://docs.openshift.com/container-platform/4.12/networking/network_observability/installing-operators.html).

## Network representations

Topology view is a great way to understand how the different components of your cluster interact internally and identify which ones are communicating with the external world. It can also help you define your network policies or highlight potential threats.

To avoid huge and unreadable network graphs, we introduced in Network Observability multiple options to focus on the content you are looking for.

- Time range
Showing by default the last 5 minutes, it allows you to focus on a particular time window

- Filtering
To select a particular set of records based on Source and / or Destination criterias such as `IPs`, `Ports`, `Protocol`, `Kind`, `Name` etc

- Level of details (scope display option)
Allowing you to select from `Node` / `Namespace` / `Owner` / `Resource` aggregating metrics into the specified layer

- Groups
To arrange components by their ownership

## Example of usage

What happens in your network when you deploy a [httpd sample application](https://github.com/sclorg/httpd-ex) ?

![Sample app deployment]({page.image('3d_topology/sample-app-deployment.png')})

You can see that the final deployed pod in blue involved another pod called `httpd-sample-1-build` that pulled the image from `openshift-image-registry` (1), did some DNS resolution for provided image URL (2), pulled it from the resolved external IP (3) before creating our pod through kubernetes services (4).

Finally, some flows are showing between our pod and `openshift-ingress` after opening the hosted page (5).

After moving my time window or waiting a bit, the `httpd-sample-1-build` pod disappears as it's status is now `Completed`.

![Sample app deployed]({page.image('3d_topology/sample-app-deployed.png')})

## Complex representations

Sometimes we need to see more than a single application to troubleshoot network issues or to highlight bandwidth usage at cluster level.

2D network topology may start to show its limits as you need to switch between multiple options and never get an overview into a single render.

![Complex 2D topology]({page.image('3d_topology/huge-topology.png')})

We can do the following observation from this:
- it is almost impossible to have a good overview of your entire network
- drawing each connection on a flat representation is hard to read
- it is difficult to understand ownership and relations between objects without a concrete representation

## Another dimension

Here is where [3D Topology](https://github.com/jpinsonneau/react-three-topology) makes the scene !

3D representations are pretty old and you can find a lot of them online such as [networkmaps](https://github.com/pablomarle/networkmaps), [vagrant-mesh-net](https://github.com/IMPIMBA/vagrant-mesh-net) or even more generic ones such as [splunk-3D-graph-network-topology-viz](https://github.com/splunk/splunk-3D-graph-network-topology-viz). Each of these has its own rendering philosophy to resolve specific use cases.

This is a way to render your network using a representation everybody knows: "buildings".
```
To enable this feature in Network Observability, you will need to use Network Observability v1.0 and add "&3d=preview" in the URL.
Then go to Topology tab -> Show advanced options -> Display options
From there set Scope option as "Resource" and Layout as "3D".
```

![3D topology building]({page.image('3d_topology/3d-building.png')})

- **Building** drawn by dotted lines represent your `Cluster`
Every internal communication is inside these lines
Each floor is represented by a line
- **Bricks surrounding the building** in a circle shape account for `external ips`
- **Ground floor** with purple bricks represents your `Nodes`
You can have multiple nodes all located at ground level
- **Upper floors** in green shows your `Namespaces`
Namespaces are aligned between nodes so each floor represent a single namespace
If a namespace is not carried by a node, you will see an empty space
- **Rooms** stand for owners such as `Deployments` in dark blue or `StatefulSets` in light blue
You can have multiple owners per namespaces
They will repeat on each node + namespace combination if the load is distributed
- Finally, **rooms contents** depict `Pods`
These are represented in the proper node + namespace + owner combination according to its kindred

![3D topology ownership]({page.image('3d_topology/3d-ownership.png')})
This representation emphasizes the entire ownership chain from `Node` to `Pod` passing by `Namespace`.
It also pin up how your load is balanced between nodes.

![3D topology connections]({page.image('3d_topology/3d-connection.png')})

The important part of your network traffic is highlighted since lines are less likely to cross than in the 2D view and their size and color differ according to bytes rate.
A thin black line will represent a smaller amount than a heavy red line.

## Conclusion

We need to identify the various use cases to elaborate proper representations. This is a daily step by step work between internal teams on both engineering and UI / UX and customers. We are likely to implement more views in the future to highlight network issues, health, threats and usage.
One of the next implementations is going to be [sankey chart](https://observablehq.com/@d3/sankey) that will be useful for connection tracking.

## We need you !

Feel free to contribute by commenting this post, opening issues in [netobserv console plugin](https://github.com/netobserv/network-observability-console-plugin/issues) or opening pull request in any [netobserv component](https://github.com/netobserv)

Tell us more about your expectations, the way you currently solve issues and what could help your daily experience.

![Gallery 1]({page.image('3d_topology/gallery-1.png')})
![Gallery 2]({page.image('3d_topology/gallery-2.png')})
![Gallery 3]({page.image('3d_topology/gallery-3.png')})
![Gallery 4]({page.image('3d_topology/gallery-4.png')})
![Gallery 5]({page.image('3d_topology/gallery-5.png')})
![Gallery 6]({page.image('3d_topology/gallery-6.png')})
![Gallery 7]({page.image('3d_topology/gallery-7.png')})
![Gallery 8]({page.image('3d_topology/gallery-8.png')})
154 changes: 154 additions & 0 deletions content/posts/2023-09-12-dns_tracking.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,154 @@
---
layout: :theme/post
title: "DNS tracking"
description: "Network Observability Per Flow DNS tracking"
image: https://images.unsplash.com/photo-1458501534264-7d326fa0ca04?q=80&w=3540&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D
tags: blogging
author: jpinsonneau
---


# Network Observability Per Flow DNS tracking

![logo]({page.image('dns_tracking/dns_tracking_logo.png')})

By: Julien Pinsonneau, Mehul Modi and Mohamed S. Mahmoud

In today's interconnected digital landscape, Domain Name System (DNS) tracking
plays a crucial role in networking and security. DNS resolution is a fundamental
process that translates human-readable domain names into IP addresses, enabling
communication between devices and servers. It can also be a security vulnerability
and a tool for firewalling and blocking access to content, depending on how it is
configured and manipulated. For operations excellence, DNS
resolution benefits from monitoring and analysis, which can be achieved through
innovative technologies like eBPF (extended Berkeley Packet Filter). In this
blog post, we'll delve into the world of DNS tracking using eBPF tracepoint
hooks, exploring how this powerful combination can be used for various purposes,
including network monitoring and security enhancement.

## Understanding DNS Resolution

Before diving into the specifics of eBPF tracepoint hooks, let's briefly recap
how DNS resolution works. In a Kubernetes architecture, DNS plays a critical role
in enabling communication between various components and services within the cluster.
Kubernetes uses DNS to facilitate service discovery and to resolve domain names
to the corresponding IP addresses of pods or services.
This process involves multiple steps, including querying DNS
servers, caching responses, obtaining the IP address to establish a connection
and caching response for future re-occurrence of the same DNS query.

## Utilizing Tracepoint Hooks for DNS Tracking

Tracepoint hooks are predefined points in the Linux kernel where eBPF programs
can be attached to capture and analyze specific events. For DNS tracking, we
leveraged tracepoint hooks associated with DNS resolution processes,
specifically the `tracepoint/net/net_dev_queue` tracepoint. Then we parse the
DNS header to determine if it is a query or a response, attempt to correlate the
query or response with a specific DNS transaction, and then record the elapsed time
to compute DNS latency. Furthermore, DNS network flows are enriched with DNS-related
fields (id, latency and response codes) to help build graphs
with aggregated DNS statistics and to help filtering on specific fields for display
in the Network Observability console.

## Potential Use Cases

DNS tracking with eBPF tracepoint hooks can serve various purposes:

- Network Monitoring: Gain insights into DNS queries and responses, helping
network administrators identify unusual patterns, potential bottlenecks, or
performance issues.

- Security Analysis: Detect suspicious DNS activities, such as domain name
generation algorithms (DGA) used by malware, or identify unauthorized DNS
resolutions that might indicate a security breach.

- Troubleshooting: Debug DNS-related issues by tracing DNS resolution steps,
tracking latency, and identifying misconfigurations.

## How to enable DNS tracking

By default DNS tracking is disabled because it requires `privileged` access. To
enable this feature we need to create a flow collector object with the following
fields enabled in eBPF config section as below:

```yaml
apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
name: cluster
spec:
agent:
type: EBPF
ebpf:
privileged: true
features:
- DNSTracking
```

## A quick tour in the UI

Once the `DNSTracking` feature is enabled, the Console plugin will automatically
adapt to provide additional filters and show informations across views.

Open your OCP Console and move to `Administrator view` -> `Observe` ->
`Network Traffic` page as usual.

Three new filters, `DNS Id`, `DNS Latency` and `DNS Response Code` will be
available in the common section:

![dns filters]({page.image('dns_tracking/dns_filters.png')})

The first one will allow you to filter on a specific DNS Id (found using `dig`
command or in flow table details) to correlate with your query.

![dns id]({page.image('dns_tracking/dns_id.png')})

The second one helps to identify potential performance issues by looking at DNS
resolution latency.

![dns latency more than]({page.image('dns_tracking/dns_latency_more_than.png')})

The third filter surfaces DNS response codes, which can help detect errors or
unauthorized resolutions.

![dns rcode]({page.image('dns_tracking/dns_response_code.png')})

### Overview

New graphs are introduced in the `advanced options` -> `Manage panels` popup:

![advanced options 1]({page.image('dns_tracking/advanced_options1.png')})

- Top X average DNS latencies
- Top X DNS response code
- Top X DNS response code stacked with total

![dns graphs 1]({page.image('dns_tracking/dns_graphs1.png')})
![dns graphs 2]({page.image('dns_tracking/dns_graphs2.png')})

### Traffic flows

The table view adds the new DNS columns `Id`, `Latency` and `Response code`,
which are available from the `advanced options` -> `manage columns` popup.

![advanced options 2]({page.image('dns_tracking/advanced_options2.png')})

The DNS flows display this information in both the table and the side panel:

![dns table]({page.image('dns_tracking/dns_table.png')})

## Future support

- Adding tracking capability for mDNS

- Adding support for DNS over TCP

- Investigating options to handle DNS over TLS where the DNS header is fully
encrypted.

## Feedback

We hope you liked this article !

Netobserv is an OpenSource project [available on github](https://github.com/netobserv).
Feel free to share your [ideas](https://github.com/netobserv/network-observability-operator/discussions/categories/ideas), [use cases](https://github.com/netobserv/network-observability-operator/discussions/categories/show-and-tell) or [ask the community for help](https://github.com/netobserv/network-observability-operator/discussions/categories/q-a).
Loading