Cilium provides sophisticated routing capabilities, particularly through the integration of the Gateway API with Kubernetes. This documentation aims to explore the routing features and paths defined within the Cilium codebase, using relevant examples sourced from various files.

Key Concepts and Implementation

Cilium’s routing capabilities extend to both ingress and egress traffic management, providing flexibility in how services communicate internally and externally. The following sections will identify specific routes defined in the codebase.

Gateway API Routes

The Gateway API enhances the Kubernetes Ingress model by allowing more robust traffic management capabilities. In the Cilium implementation, this means defining routes that can control traffic splitting, header modifications, and support for different protocols (TCP, UDP, gRPC, etc.).

Example of Gateway API Implementation:

const sectionContent1 = {

title: 'Advanced Routing and Protocol Support',

description:

'Cilium’s Gateway API implementation provides a fully conformant implementation of Kubernetes Ingress and offers advanced routing capabilities that go beyond the limitations of the Ingress API. It supports features such as traffic splitting, header modification, and URL rewriting. Additionally, it extends beyond HTTP and HTTPS traffic, with support of other protocols such as TCP, UDP, and gRPC. This allows for more flexible and sophisticated routing strategies.',

videoSrc: 'https://www.youtube.com/embed/dqyBoqJYveQ',

};

Source: src/pages/use-cases/gateway-api.jsx

Cross-Namespace Routing

Cilium supports cross-namespace routing, a feature that allows routes to exist seamlessly across different namespaces in a Kubernetes cluster. This is particularly beneficial for applications needing service discovery beyond their immediate namespace.

Example from Tutorial on Cross-Namespace Routing:

A in-depth tutorial on Cross-Namespace Routing with Cilium Gateway API.

Source: src/posts/2023-05-05-cross-namespace/index.md

Direct and Encapsulated Routing Modes

Cilium supports two primary IP routing modes: Direct and Encapsulated. These modes define how packet forwarding is handled within the environment.

Reference to Routing Modes:

Learn about Cilium’s supported IP routing modes in this video.

Source: src/posts/2022-04-23-ip-routing-modes/index.md

Workload-Specific Routing

Workload-specific routing is defined through Egress Gateways, which allow the routing configurations to be tailored for individual workloads. This setup is crucial for environments hosting multi-tenant applications where different workloads must adhere to unique network requirements.

Example Description for Egress Gateway:

const sectionContent3 = {

title: 'Workload-Specific Routing',

description:

'In multi-tenant Kubernetes clusters, different workloads might need to interact with different external systems that have specific network requirements. Egress gateways can help meet these requirements by allowing the configuration of workload-specific routing rules.',

imageSrc: EgressImage3,

};

Source: src/pages/use-cases/egress-gateway.jsx

BGP-Enabled Routing

Cilium’s integration with BGP (Border Gateway Protocol) enables efficient routing for workloads, especially in hybrid cloud environments. The architecture simplifies the management of routing information for both on-premises and cloud workloads.

Case Study of BGP Implementation:

Trip.com chose a topology based on where workloads run. Bare-metal on-premises workloads use Direct routing via BGP using BIRD, while AWS workloads use AWS ENI routing mode via Cilium AWS ENI support.

Source: src/posts/2020-02-05-how-trip-com-uses-cilium/index.md

Conclusion

Cilium’s routing capabilities encompass a variety of defined routes that handle ingress and egress traffic, support for multiple protocols, and advanced features like workload-specific routing. By leveraging the Gateway API, Cilium forms a robust framework for managing network traffic in Kubernetes environments. This documentation presents a detailed look into the routing paths defined within the Cilium codebase, with references drawn from different implementations across the source files.

For further details, the interested developer may refer to the specific source files listed throughout this document.