Kubenet: A Framework for Declarative Network Automation

Introduction

In today’s rapidly evolving technology landscape, automation plays a pivotal role in enhancing efficiency, accuracy, and scalability. At Kubenet, we’ve embraced a declarative approach to network automation that focuses on defining the ‘what’ — the objectives — without getting bogged down by the ‘how.’ This article delves into the foundational principles and innovative architecture of Kubenet’s framework, designed to meet the dynamic demands of modern network environments.”

Terminology

Understanding the correct terminology is crucial, as network automation involves multiple components and layers of technology. Below, we clarify the key terms used at Kubenet.

figure 1. service

First of all in Kubenet we think of network automation as a set of services offered to a consumer(s). A service can be composed of additional fine graned services.

To help illustrate the idea, we will use the network service in figure 2. A network service is decomposed per network device based on its topology into additional services:

• specific interface(s) with respective IP/VLAN
• specific network instance(s)
• specific protocol(s)
• the ultimate device configuration

figure 2. network service illustration

The network automation provides the building blocks necessary for a service to serve the consumer(s). The ability to decompose network services into finer-grained building blocks is a cornerstone of our approach. This modular design philosophy aligns with the UNIX principle of doing one thing and doing it well. By breaking down complex services into smaller, reusable components, our automation logic becomes more manageable, scalable, and adaptable. This modularity allows for each component to be optimized independently while contributing to the efficiency of the overall system.
On top the service decomposition offers lots of flexibility to tailor services to specific environments, while maintaining the ability to offer abstract service definitions.

The actuator is what is used to instantiate the resulting configuration of the service to the production environment. The actuator includes change management that allows the service to progress from one state of production to another in a safe and controlled way. More on this is subsequent articles.

Services and resources

In the Kubenet framework, service implementation is structured around three foundational building blocks:

1. Data Model: Each service in Kubenet is meticulously defined and structured using a comprehensive data model, such as OpenAPI or YANG. These models provide detailed blueprints of the service, outlining essential elements and their interrelationships. This detailed specification serves as the operational and interactive framework for the service within the broader system architecture.

2. API Accessibility: Services in Kubenet are made accessible through APIs that facilitate a set of declarative operations. These operations empower users to interact with services by specifying the desired outcomes — ‘what’ needs to be achieved — rather than focusing on the execution methods. This approach simplifies user interaction, enhancing user experience by abstracting the underlying complexities.

3. Business Logic Integration: The APIs in Kubenet are further enhanced by integrating comprehensive business logic. This logic governs the operations’ behavior, ensuring compliance with established rules and protocols. Consequently, it guarantees the consistency, integrity, and reliability of interactions within the services.

Resource Implementation and Management:

In Kubenet, we adopt the Kubernetes Resource Model (KRM) to underpin our API modeling. This framework guides us in designating elements that describe the service’s data model as ‘resources.’ A resource represents the practical implementation aspect of a service’s API, encapsulating both the structural and operational definitions.

Clarification on Services and Resources:

A service in Kubenet is invariably facilitated through a resource, ensuring every service is supported by a well-defined API model. However, it’s crucial to note that not all resources qualify as services. For example, resources lacking embedded business logic do not constitute services; instead, they function more like templates or configurations used in service provision.

Types of Resources:

• Abstract Resources: These provide high-level definitions that abstract specific implementations, enhancing adaptability and flexibility across different environments. They serve as foundational templates for developing more specific service functionalities.
• Internal Resources: These are managed internally and focus on deriving outcomes crucial for the efficient operation of Kubenet’s automation services. They are integral to service offerings.
• Identity and Inventory Resources: Known also as inventory resources, these define crucial environmental contexts, such as network inventory IP pools, etc, vital for configuring network services. While these resources inform service logic, they are not directly offered as standalone services.
• Template and Context Resources: Facilitate implementation and abstract service implementations, they are not offered as a service.
• External Resources: Depending on external systems’ data models and protocols, these resources often include vendor-specific information and are structured to align with external service expectations.

Conclusion

At Kubenet, we champion the use of decomposable software to facilitate network automation solutions. By conceptualizing network automation as modular services and resources, we allow to structure your automation framework in reusable components that are easy to maintain and extend.

We invite you to engage with us further — leave your thoughts below or connect with us on LinkedIn or Discord