DOCSEARCHbyAlgolia
Submit Docs

Meridio Documentation

website·Indexed 33 days ago

https://meridio.nordix.org/

Documentation for Meridio, a networking solution for Kubernetes featuring stateless load-balancing, port-NAT, and IPAM. It includes guides on components like the Network Service Platform (NSP), Attractors, Trenches, and Gateways, as well as deployment via Helm and Operator for versions v1.0.0 and v1.1.0.

Tokens
78.2K
Snippets
381
Records
547
Agent score
47%

What's inside Meridio

  1. Overview of Meridio Conduit

    A Conduit defines the physical path of chained network services that traffic traverses before being consumed by a target application. Traffic is assigned to a Conduit by a Stream. Currently, the primary supported network service function is stateless load balancing. To specify the owner reference trench, the resource must be created with the label metadata.labels.trench.

  2. Overview of Meridio Proxy functionality

    The Meridio Proxy allows targets (e.g., TCP applications) to connect to multiple network service instances (e.g., stateless-lb) through a single network interface. It creates a full mesh between the proxy and network service instances by monitoring NSEs via the NSM API.

    Key behaviors include:

    • Naming: The proxy acts as a network service with the naming convention: proxy.<conduit-name>.<trench-name>.<namespace>.
    • IP Management: Upon startup, the proxy requests a unique subnet from the IPAM Service to allocate IPs for targets and network service instances.
    • Traffic Routing: For network service instances, the proxy acts as a bridge. For targets, it acts as a router/gateway, creating source-based routes to distribute outgoing traffic among network service instances.
    • Constraint: Currently, the proxy supports only one conduit.

  3. Overview of the Meridio Proxy

    v1.1.0

    The Meridio Proxy allows targets (such as TCP applications) to connect to multiple network service instances (e.g., stateless-lb) through a single network interface. It uses the NSM API to monitor NSEs and request connections. For targets, the proxy acts as a network service with the naming convention proxy.<conduit-name>.<trench-name>.<namespace>.

    Key operational behaviors:

    • IP Management: Requests a unique subnet from the IPAM Service to allocate IPs for targets and network service instances.
    • Traffic Handling: Acts as a bridge for network service instances to access targets via IP, and as a router/gateway for target outgoing traffic, using source-based routes to distribute traffic among network service instances.
    • Constraint: Currently supports only one conduit.

  4. Overview of Stateless-lb load balancing

    v1.1.0
    Stateless-lb is a user-space load balancer that implements the Maglev algorithm to distribute traffic among multiple targets. It subscribes to events from the NSP Service to track target registration/unregistration and updates the nfqueue-loadbalancer program, IP rules, and IP routes accordingly. It uses iptables and nfqueue to move traffic from kernel space to user space, where a forwarding mark is added based on Maglev and registered target identifiers before returning the traffic to kernel space for forwarding.

  5. Overview of Meridio Proxy functionality

    v1.0.0

    The Meridio Proxy allows targets (e.g., TCP applications) to connect to multiple network service instances (e.g., stateless-lb) through a single network interface.

    Key operational behaviors include:

    • Connectivity: It uses the NSM API to monitor Network Service Endpoints (NSEs) and requests connections to each. For targets, the proxy presents itself as a network service with the naming convention: proxy.<conduit-name>.<trench-name>.<namespace>.
    • IP Management: Upon startup, the proxy requests a unique subnet from the IPAM Service to allocate IPs for targets and network service instances.
    • Traffic Routing:
      • From the network service instance side, the proxy acts as a bridge, allowing access to individual targets via their IPs.
      • From the target side, the proxy acts as a router/gateway, creating source-based routes to distribute outgoing traffic among network service instances.
    • Constraint: Currently, the proxy supports only one conduit.

  6. Overview of the Stateless Load-balancer architecture

    v1.0.0

    The Stateless Load-balancer uses a user-space Maglev implementation to balance traffic across multiple targets. It subscribes to events from the NSP Service to receive notifications about target registration and unregistration, which it uses to update identifiers in the nfqueue-loadbalancer program, IP rules, and IP routes.

    Traffic is moved from kernel space to user space using iptables and nfqueue. The nfqueue-loadbalancer program assigns a forwarding mark to the traffic based on Maglev and registered target identifiers, then returns the traffic to kernel space to be forwarded to the selected target via IP rules and routes.

  7. Overview of Meridio IPAM Service

    v1.0.0
    The Meridio IPAM service prevents IP collisions and manages IP distribution within a system. It operates as a gRPC server listening on port 7777 and is typically consumed via a Kubernetes clusterIP service over the primary network. The service is implemented as a StatefulSet with a single replica, using a local SQLite database stored in a persistent volume for data persistence.

  8. Overview of the Attractor resource

    The Attractor defines a group of Front-Ends (FEs) that share common characteristics, such as the external interface to use, IP address assignment methods, gateways for establishing connections, and VIP addresses to announce.

    Crucially, every Attractor resource must be created with the label metadata.labels.trench to specify its owner reference trench.

  9. Overview of Target Access Point Ambassador (TAPA)

    v1.1.0
    The Target Access Point Ambassador (TAPA) is a local service running as a side-car container within a user pod. It serves as the main interface for user applications to interact with Meridio. Applications connect to the TAPA server via a shared Unix socket file and can utilize the TAPA API through three primary functions: Open, Close, and Watch. The Watch function specifically allows applications to monitor opened streams on the pod and verify their status.

  10. Overview of the Network Service Platform (NSP)

    The Network Service Platform (NSP) is a gRPC server that manages two primary responsibilities in the Meridio ecosystem:

    1. Configuration Management: It watches a Kubernetes ConfigMap for changes to resources (trenches, conduits, streams) and propagates updates to Meridio components (Load-balancer, proxy, targets).
    2. Target Registry: It tracks the availability of targets. Targets notify the NSP of their status (IP, stream, and identifiers). To prevent 'ghost' targets resulting from crashes or ungraceful terminations, targets must regularly call the Register function to refresh their entry.

  11. Overview of Meridio Frontend external gateway routing

    v1.1.0

    The Frontend component enables Meridio to attract external traffic via a secondary network. It achieves this by installing source routing rules for configured VIP addresses and running a BIRD routing instance restricted to the external interface. It supports BGP (with optional BFD supervision) and Static+BFD setups.

    In a BGP configuration, the frontend announces a next-hop route for each VIP address to its external peer, using the frontend's own IP as the next-hop. To prevent traffic blackholing, the frontend only advertises VIP addresses when the collocated load balancer signals that it is capable of forwarding traffic to application targets.

  12. Overview of Stateless-lb load balancer

    The Stateless-lb is a load balancer that uses a user-space Maglev implementation to distribute traffic among multiple targets. It subscribes to events from the NSP Service to track target registration and unregistration, updating identifiers in the nfqueue-loadbalancer program, IP rules, and IP routes. It utilizes iptables and nfqueue to move traffic from kernel space to user space, where a forwarding mark is added based on Maglev and registered target identifiers before returning the traffic to kernel space for forwarding.