This section defines a CNF, and where Ligato fits in CNF development. It also includes a list of developer resources.
A cloud native network function (CNF) is a cloud native application that implements network functionality. A CNF consists of one or more microservices and has been developed using Cloud Native Principles including immutable infrastructure, declarative APIs, and a “repeatable deployment process”.
Source: CNCF definition
Cloud providers are shifting towards a cloud native approach for application development, operations and management. Applications are packaged up in containers. Kubernetes automates container startup, placement and teardown based on policies, services, scale and resiliency. The cloud native lifecycle simplifies the steps beginning with development all the way to deployment automation and operations in modern cloud environments.
Cloud native network functions (CNF) run inside containers and inherit all behaviors and benefits afforded to cloud native applications. Indeed, you can think of CNFs as just another application container.
By applying the Kubernetes lifecycle to CNFs, you can spin up different network configurations to meet your respective needs. Several examples follow:
- Webscale services running on multiple application pods interconnected through a CNF virtual switch network overlay.
- Cloud service bundles composed of CNFs strung together in a service function chain.
- VPN internet gateway solutions employing IPsec crypto/tunnel CNFs.
CNFs require two more important attributes:
- High performance data plane.
- Programmability and observability using cloud native APIs including k8s CRDs, gRPCs, etcd data stores and REST APIs.
CNF solutions must keep pace with cloud native adoption and growth. The cloud native developer community requires solutions that simplify and expedite the development and implementation of customized, scalable and versatile CNFs.
That’s where Ligato comes into play.
100K foot View#
Ligato is a Golang (Go) framework for developing software agents to control and manage CNFs.
CNF solutions with different personalities exist in cloud native networks. Some replicate the functions of existing physical (PNF) and virtual NFs (VNF). Others will support new and emerging cloud native functions.
The following figure shows a high-level conceptual view of Ligato CNF solutions, Ligato features, and a sampling of compatible open source components.
Ligato at a 100K foot view
You can develop CNFs that address your individual cloud native network requirements. The following lists the Ligato “take-aways” to help you achieve that:
- Features devoted to CNF development and operational deployment.
- Focus on CNF configuration and monitoring.
- Tailored for the high-performance FD.io/VPP data plane.
- Embraces integration with other open source projects.
10K foot View#
Ligato supplies you with the plugins, infrastructure, code and documentation to develop software agents.
The next figure takes you down to a “10K foot” view, beginning at the top:
Ligato at a 10K foot view
- Applications - External applications, rpc clients, telemetry apps, and data stores. They communicate via declarative APIs to Ligato NB plugins.
- Northbound Plugins - Set of reusable plugins enabling Ligato agents to communicate with external applications.
- KV Scheduler - Core plugin that supports configuration item dependency resolution, and computes the proper programming sequence for multiple interdependent configuration items. The KV Scheduler receives configuration data from NB, determines dependencies, and executes CRUD callbacks in the SB towards the VPP or Linux plugins.
- VPP and Linux Plugins - Set of plugins providing network functions you can use to assemble your Ligato agent. Note that you can “cherry pick” plugins as needed. And you can develop your own custom plugins.
- Infra - Provides plugin lifecycle management including initialization and graceful shutdown of plugins. Infra includes a set of infrastructure plugins for health checking, NB data store communications, messaging, logging, and rpc APIs.
You will implement a mix of cn-infra plugins, VPP agent plugins, and/or custom plugins, to define your CNF.
VPP Agent Functions#
Ligato makes it easy to develop a VPP agent for programming a VPP data plane
You will likely hear the term, VPP agent, associated with Ligato. It loosely describes an agent that configures and monitors a VPP data plane.
The following lists VPP agent functions:
- VPP and Linux plugins.
- VPP agent + VPP data plane in one container.
- Multi-VPP configuration support.
- Multi-version configuration support.
- Dependency handling between related configuration items.
- Transaction-based configuration processing and tracking.
- Failover NB/SB synchronization mechanisms.
- Stateless configuration management based on a KV data store “watch” paradigm.
- Direct access via REST or gRPC.
- Component health checks.
The VPP agent does not perform packet processing when forwarding packets. The VPP data plane handles those functions.
Ligato comes with many developer resources
- Golang programming language.
- Model-driven protobuf APIs.
- Common programming pattern for agents.
- Multiple out-of-the-box plugins.
- Automatic plugin lookup and dependency injection.
- Plugin KV data store, REST, and gRPC examples.
- KV scheduler core plugin for handling plugin dependencies and programming sequence.
- Custom agent coding example.
- Developer guide
- KV Scheduler troubleshooting guide
- Startup troubleshooting
- Configuration troubleshooting
- Detailed logging.