Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Enable Time-Sensitive Applications in Kubernetes with Container Network Interface Plugin Agnostic Metadata Proxy

Ferenc Orosi, Ferenc Fejes

TL;DR

The paper tackles the challenge of running Time-Sensitive Applications (TSAs) within Kubernetes by addressing the loss of per-packet TSN metadata caused by container network namespace isolation. It introduces a TSN metadata proxy implemented as an extension CNI that uses eBPF to capture and restore essential TSN metadata (e.g., priority and timestamp) without modifying TSAs or primary CNIs, and integrates with existing CNI plugins. The architecture comprises a node-wide DaemonSet that manages eBPF maps and programs and per-pod eBPF-based metadata handling, enabling TSN NIC scheduling via standard Kubernetes networking. This approach preserves deterministic timing for TSAs across typical Kubernetes services and emphasizes compatibility, security, and ease of deployment over kernel bypass or TSA alterations, representing a practical path toward time-sensitive microservices in cloud-native environments.

Abstract

Application deployment in cloud environment is dominated by Kubernetes-orchestrated microservices. Provides a secure environment, networking, storage, isolation, scheduling, and many other abstractions that can be easily extended to meet our needs. Time-Sensitive Applications (TSAs) have special requirements for compute and network. Deploying TSAs in Kubernetes is challenging because the networking implemented by Container Network Interface (CNI) plugins is not aware of the traffic characteristic required by Time-Sensitive Network. Even if a network interface supports TSN features (e.g.: Scheduled Traffic) and a modified CNI plugin is aware of this interface, the pod network isolation built on top of Linux deletes the metadata required for TSN protocols to work with. We propose TSN metadata proxy, a simple architecture that allows any TSA microservice to use the TSN capabilities of the physical NIC, without any modification. This architecture is tightly integrated with the Kubernetes networking model, works with popular CNI plugins, and supports services such as ClusterIP, NodePort, or LoadBalancer without additional configuration. Unlike former proposals, this architecture does not require either bypassing the Linux kernel network stack, direct access to the physical NIC, escalated privileges for the TSA microservice, or even modification of the TSA.

Enable Time-Sensitive Applications in Kubernetes with Container Network Interface Plugin Agnostic Metadata Proxy

TL;DR

The paper tackles the challenge of running Time-Sensitive Applications (TSAs) within Kubernetes by addressing the loss of per-packet TSN metadata caused by container network namespace isolation. It introduces a TSN metadata proxy implemented as an extension CNI that uses eBPF to capture and restore essential TSN metadata (e.g., priority and timestamp) without modifying TSAs or primary CNIs, and integrates with existing CNI plugins. The architecture comprises a node-wide DaemonSet that manages eBPF maps and programs and per-pod eBPF-based metadata handling, enabling TSN NIC scheduling via standard Kubernetes networking. This approach preserves deterministic timing for TSAs across typical Kubernetes services and emphasizes compatibility, security, and ease of deployment over kernel bypass or TSA alterations, representing a practical path toward time-sensitive microservices in cloud-native environments.

Abstract

Application deployment in cloud environment is dominated by Kubernetes-orchestrated microservices. Provides a secure environment, networking, storage, isolation, scheduling, and many other abstractions that can be easily extended to meet our needs. Time-Sensitive Applications (TSAs) have special requirements for compute and network. Deploying TSAs in Kubernetes is challenging because the networking implemented by Container Network Interface (CNI) plugins is not aware of the traffic characteristic required by Time-Sensitive Network. Even if a network interface supports TSN features (e.g.: Scheduled Traffic) and a modified CNI plugin is aware of this interface, the pod network isolation built on top of Linux deletes the metadata required for TSN protocols to work with. We propose TSN metadata proxy, a simple architecture that allows any TSA microservice to use the TSN capabilities of the physical NIC, without any modification. This architecture is tightly integrated with the Kubernetes networking model, works with popular CNI plugins, and supports services such as ClusterIP, NodePort, or LoadBalancer without additional configuration. Unlike former proposals, this architecture does not require either bypassing the Linux kernel network stack, direct access to the physical NIC, escalated privileges for the TSA microservice, or even modification of the TSA.

Paper Structure

This paper contains 14 sections, 2 figures.

Table of Contents

  1. Introduction
  2. Time-Sensitive Networking Overview
  3. Time-Sensitive Computing
  4. Time-Sensitive Application Microservice Deployment on Scale
  5. Time-Sensitive Applications with Kubernetes
  6. Control plane
  7. Data plane
  8. Related Work
  9. Proposed Architecture
  10. Steps of the node initialization
  11. Steps of the pod initialization
  12. Tracking the packets through the node
  13. Operation Example
  14. Conclusion

Figures (2)

  • Figure 1: Architecture of the TSN metadata proxy. A proxy instance on every node in the cluster setup a storage for the TSN metadata. With eBPF it collects the metadata from each packet into the storage and restores it before reaching the TSN NIC. A tracking eBPF program update the memory address of the packet if changes during the forwarding.
  • Figure 2: RX timestamps mapped to 802.1Qbv (taprio Qdisc) cycles. Without the proxy (\ref{['fig:noproxy']}), the priority info lost and every packet uses the best-effort timeslot. With TSN proxy (\ref{['fig:proxy']}) the priorities preserved and the packets received within their timeslot.