My main use case for Isovalent is to show partners how to secure the infrastructure on which AI runs, specifically cloud-native applications. Isovalent excels at securing and observing cloud-native applications due to eBPF usage. I have helped major partners including WWT, SHI, and NTT understand how these systems work. Taking my application that I have developed, a cloud-native application with AI embedded in it, we would put it under a CNI such as a normal CNI and then we would use Cilium CNI and all of its service mesh and cluster mesh, and they would see the efficiency and observability, primarily observing the actual pods without sidecars. This is a wonderful example of how efficient and secure Isovalent is. Additionally, Tetragon showcases its ability to secure the application from the kernel side. I explain to partners that Isovalent is the secure highway on which all of the applications that drive AI or any other commerce will be in the future.
DevOps Engineer at a university with 1,001-5,000 employees
Real User
Jul 4, 2026
The main use case was using Cilium as a CNI for our Kubernetes cluster, so we used it for network policy and observability via Hubble, primarily for our CNI for the Kubernetes cluster. My responsibility was to implement and set up a Kubernetes cluster, and one of the things we had to choose was CNI. We had several options, one of them was Cilium, because it is eBPF based and operates at a kernel level performance, giving us better performance. After we set up that with Cilium CLI, it was somewhat difficult to set up, but afterwards, we could solve problems with the observability we had with Hubble UI. I remember one time we had to find out what the problem was between two microservices we had, and we used Hubble to understand what the problem was.
My main use case for Isovalent primarily involves network choices and network options. When my clients requested a Kubernetes migration from either on-premises or some cloud solutions, we designed a Kubernetes ecosystem. I have finance companies as clients that require more secure and faster communication at the network level, which led us to review and choose Isovalent products for our Kubernetes ecosystems. As for a specific example of how I used Isovalent for one of my finance clients, one of my clients is a fintech company with significant traffic every day, every minute, and every second. Network consistency and network monitoring are very important in this field, and Isovalent utilizes eBPF solutions in some of its products such as Cilium. We use Cilium, and its kernel-based operations and monitoring are very good, demonstrating how the network features made a difference.
Senior Principal Engineer at a outsourcing company with 1,001-5,000 employees
Real User
Top 20
May 17, 2026
We wanted to migrate from Calico to Cilium because we wanted to have an alternative CNI for our Kubernetes cluster to use the in-built eBPF native kernel path for better observability, a better network experience, L7 policies, and other benefits. I was looking at all the features provided by Isovalent so that we could migrate from Calico. I was using it as an overall product to replace Calico rather than tackling a specific use case. I have created two different Kubernetes clusters on bare metal. I added Cilium from Isovalent as the CNI and then created a service mesh between both clusters using Cilium. The clusters work fine, and the pods from one cluster to another are automatically communicating using the eBPF native data plane rather than IP tables. The routes and everything are set up by Cilium service mesh automatically. It was a good overall CNI to set up the multi-cluster setup, and I use Hubble to see the traffic pattern and how the traffic moves from one cluster to another.
Isovalent harnesses eBPF technology to enhance Kubernetes networking, offering features like Cilium and Hubble for robust observability and security.Isovalent, with its eBPF-driven capabilities, stands out in Kubernetes networking, offering comprehensive traffic insights via Hubble and seamless policy creation with YAML. Users integrate Isovalent for enhanced microservices security, reduced latency, and improved performance, appreciating its intuitive interface and effortless third-party...
My main use case for Isovalent is to show partners how to secure the infrastructure on which AI runs, specifically cloud-native applications. Isovalent excels at securing and observing cloud-native applications due to eBPF usage. I have helped major partners including WWT, SHI, and NTT understand how these systems work. Taking my application that I have developed, a cloud-native application with AI embedded in it, we would put it under a CNI such as a normal CNI and then we would use Cilium CNI and all of its service mesh and cluster mesh, and they would see the efficiency and observability, primarily observing the actual pods without sidecars. This is a wonderful example of how efficient and secure Isovalent is. Additionally, Tetragon showcases its ability to secure the application from the kernel side. I explain to partners that Isovalent is the secure highway on which all of the applications that drive AI or any other commerce will be in the future.
The main use case was using Cilium as a CNI for our Kubernetes cluster, so we used it for network policy and observability via Hubble, primarily for our CNI for the Kubernetes cluster. My responsibility was to implement and set up a Kubernetes cluster, and one of the things we had to choose was CNI. We had several options, one of them was Cilium, because it is eBPF based and operates at a kernel level performance, giving us better performance. After we set up that with Cilium CLI, it was somewhat difficult to set up, but afterwards, we could solve problems with the observability we had with Hubble UI. I remember one time we had to find out what the problem was between two microservices we had, and we used Hubble to understand what the problem was.
My main use case for Isovalent primarily involves network choices and network options. When my clients requested a Kubernetes migration from either on-premises or some cloud solutions, we designed a Kubernetes ecosystem. I have finance companies as clients that require more secure and faster communication at the network level, which led us to review and choose Isovalent products for our Kubernetes ecosystems. As for a specific example of how I used Isovalent for one of my finance clients, one of my clients is a fintech company with significant traffic every day, every minute, and every second. Network consistency and network monitoring are very important in this field, and Isovalent utilizes eBPF solutions in some of its products such as Cilium. We use Cilium, and its kernel-based operations and monitoring are very good, demonstrating how the network features made a difference.
We wanted to migrate from Calico to Cilium because we wanted to have an alternative CNI for our Kubernetes cluster to use the in-built eBPF native kernel path for better observability, a better network experience, L7 policies, and other benefits. I was looking at all the features provided by Isovalent so that we could migrate from Calico. I was using it as an overall product to replace Calico rather than tackling a specific use case. I have created two different Kubernetes clusters on bare metal. I added Cilium from Isovalent as the CNI and then created a service mesh between both clusters using Cilium. The clusters work fine, and the pods from one cluster to another are automatically communicating using the eBPF native data plane rather than IP tables. The routes and everything are set up by Cilium service mesh automatically. It was a good overall CNI to set up the multi-cluster setup, and I use Hubble to see the traffic pattern and how the traffic moves from one cluster to another.
I have used Isovalent for the networking certification, which is an open source certification.