No time for downtime!
Modern businesses require a consistent and predictable user experience no matter where apps, users and data are located. To this end, we spend a great deal of time and effort monitoring the servers, containers, storage, databases, the app runtimes, we instrument the code, we run synthetic tests, we collect RUM data, but time and time again I see the network is overlooked.
The network is by far the most critical component in application delivery, be it a user on a cell phone on a train, someone on their home WiFi, a corporate user on a SDWAN enabled network, or within the datacenter or cloud itself, the variety and quality of that connectivity will have a big impact on the experience that user has.
Continuous network performance is increasingly challenging
Ensuring a reliable and performant network is in itself becoming a real challenge for companies as they struggle with the shift to hybrid cloud and SaaS delivery, labor shortages, a decreasing talent pool of network experts, the shift to SDx and the complexity that can entail and then trying to gain control and visibility over this ever expanding network.
What used to be safe and easy to observe within the four walls of a datacenter is now potentially stretched over multiple clouds, interconnected by multiple providers and with a variety of levels of visibility.
Network Observability in the world of Kubernetes
Application architecture & delivery was turned on it's head by containers and Kubernetes takes this to another level by providing one of the most popular application delivery platforms. Kubernetes gives great power to the DevOps team, freeing them from being held back by a somewhat rigid network and supplementing it the freedom of the overlay network. However, the lack of visibility in to this overlay network can often lead the NetOps and DevOps teams arguing over "is it the app? or is it the network?"
IBM SevOne 7.0, Kubernetes and RedHat NetObserv
So how do we help the NetOps team? How can we regain visibility in to the world of a Kubernetes overlay network? As part of our 7.0 release, I'm really proud to be able to introduce Kubernetes network observability, enabled via RedHat NetObserv.
RedHat NetObserv is an open source project with contributions from both IBM Research and the IBM SevOne team. It provides a 'One Click' install via the RedHat OperatorHub, but can also be deployed on any Kubernetes system.
With IBM SevOne 7.0 & RedHat NetObserv you can regain visibility into your Kubernetes overlay network. We provide instant visibility into flows between pods, namespaces, nodes as well as IP addresses, ports and protocols. The flow data is produced, enriched and displayed via our Data Insight visualisation tool and gives the ability for NetOps teams to view not only how traffic is flowing within the overlay, but also if external sources are involved we can also see the source and destination country, the BGP autonomous systems and potentially any SaaS services such as AWS S3 that the application may be accessing.
overlay visibility between namespace, node, pod & ip address
top talkers, ip adress and app port
automatic enrichment with autonomous system (AS) and country
Not only do we provide bits, bytes and packets, but we also have the power to add round trip time (RTT) as measured and experienced by what is being monitored. This is really important as it provides real world network response time measurements using real application data as apposed to synthetic transactions which may not be treated in the same way by the network.
By enriching with Kubernetes metadata such as pod, namespace and node, we can all utilise the same nomenclature and be sure that our NetOps and DevOps teams are looking at the same resources, be it with a CLI tool like k9s, an application performance management (APM) tool such as IBM Instana, or with a network view via IBM SevOne 7.0.
kubernetes application data in a netops view...
...can be matched with the same data in an apm tool such as IBM Instana
Powered by eBPF
All of this visibility is only possible due to the great technology that is eBPF. Extended Berkeley Packet Filter (eBPF) is a programming technology that enables developers to write efficient, safe and non-intrusive programs that run directly in the Linux operating system (OS) kernel space. This gives us the ability to see every packet, every system call, everything that is happening on a system without having to use a legacy probe or trying to use taps or packet capture probes and sniffers. Less cost, less complexity, more visibility.
Find out more about eBPF via ibm.com/topics/ebpf
Summary
This was a really interesting project to work on, sparked by a conversation I had with a fellow IBMer at an event and our shared frustration around the lack of visibility across the full network & application stack. I give thanks to my colleagues across RedHat, IBM Research and the IBM SevOne team for bringing this to fruition and I hope it will help empower your NetOps and DevOps teams with the data they need to ensure a consistent and predictable user experience no matter where apps, users and data are located.