Ligato Use Cases
1. MultiSolution Diversity
Container-based high-Performance, scalable, FeatureHeavy, lightweight software component
based on open source
easily programmable from multiple control/management entities (e.g. K8s)
maximum code reusability
function plugin options to building and applying solution specificity
Stats and Telemetry steaming and export
Solution: Programmable VPP vSwitch
Programmable VPP vSwitch
Already implemented in multiple solutions and frameworks (see below). By definition proves code reusability and operational deployment feasibility
Composed of the Ligato VPP Agent plus the VPP dataplane.
Inherits all of the dataplane features and services from FD.io/VPP. This includes your standard L2/L3 forwarding, as well as more application-specific processing including IPsec tunnel termination, firewall policies and K8s services and policies.
Figure above illustrates the origins starting with separate open source components. At the “midpoint” the two open source pieces, the Ligato VPP Agent and the VPP dataplane are bolted together forming the programmable VPP vSwitch. The targets are solutions where this vSwitch forms THE core component.
Other solutions, projects and ventures either working on, shipping or considering a container-based vSwitch include hICN, ONAP, Service Function Chaining, StrongSwan-based IPsec VPN Gateway as well as cable, mobility and service mesh edge proxies.
A blog on this topic is available here.
2. Contiv VPP
From their inception, Kubernetes Container Network Interfaces (CNI) define an API for managing connectivity between application pods in a K8s cluster. CNI plugins come in many flavors with each focused on a particular aspect of cluster networking that at the end of the day accomplish the same general task: networking between pods on different hosts. The operative word is networking.
With the application pod networking problem solved, we need to turn our attention to K8s policies and services. The former defines which pods can talk to each other; the latter defines pods acting as service endpoints. Policies and services must be programmed into the network and meanwhile at the speed of the pod placement-create-destroy “work flow” orchestrated by K8s.
Details on the overall problem statement (i.e. requirements) are discussed here. For convenience sake, several are reiterated here:
Policies and Services are
first-class citizensin cluster networking which translates to k8s policy and service awareness at the network layer.
Current and future feature/function support with performance.
Classic (i.e. tap, veth) and high-performance, inter-VPP memif interface support
Fast Configuration Programmability - Important Containers are added and removed frequently. They must (re)start within a second and there could be multiple running instances on single host. They may even move to other hosts. Therefore it is crucial that there be minimal delay to programming in the correct configuration into the dataplane.
Solution - Contiv VPP
Contiv-VPP is a Kubernetes CNI plugin (not to be confused with Ligato plugins) that exploits VPP as the forwarding plane for optimal performance and K8s policy and service handling.
The figure above presents an abstracted view of Contiv-VPP deployed in a K8s cluster. The unique aspects of this solution are:
k8s Policy and Service Mapping to FD.io/VPP Configuration. This is an automated distribution pipeline where k8s policies and services are automatically reflected into FD.io/VPP configuration information which is then programmed into the network.
contiv-vswitch This is the CNF composed of the FD.io/VPP dataplane and a Ligato-based VPP agent. It is across APIs enabled by the VPP agent/plugins that configurations rendered from policy and services are passed into the FD.io/VPP dataplane. The contiv-vswitch runs completely in userspace and uses DPDK for direct access to the network I/O layer.
3. Network Service Mesh
The Network Service Mesh (NSM) is novel approach that manages L2/L3 “pipes” (another term is “wires) between client Pods that require a service and server pods that host the service. It is separate from CNI plugins but can co-exist in a K8s cluster network with any CNI plugin.
NSM addresses the problem of “too much network configuration complexity” for developers and operators who merely need to connect client pods (network service clients or NSCs) to service Pods (network service endpoints or NSEs).
An Ligato/VPP-based CNF is one implementation supporting the x-connect of local and remote interfaces (e.g. tap, memif, SRv6, vxlan tunnels, etc.) that when strung together form the aforementioned client to service pod wires.
Reference: Network Service Mesh