Intent-Driven Orchestration: Simplifying Cloud and Edge Deployments

Highlights:

  • Using research from Intel Labs, Intel has developed an Intent-Driven Orchestration (IDO) model, a novel approach to resource allocation using intent-driven requests based on application key performance indicators (KPIs).

  • Instead of relying on domain knowledge, IDO enables users in serverless environments to define what they really care about— their application objectives.

  • The Intent-Driven Orchestration planner is available under an open-source Apache 2.0 license on GitHub.

author-image

By

Using research from Intel Labs, Intel developed the open-source Intent-Driven Orchestration (IDO) planning component for Kubernetes (K8s), supporting a novel approach to resource management that enables deployment of cloud-native applications through service level objectives (SLOs) expressed as KPIs, which minimizes service owner and administrator overhead. IDO simplifies deployment, enabling users to run cloud and edge applications in a semantically portable and efficient manner without needing knowledge about the underlying platform and its characteristics, such as power, CPU, memory, and storage-related configurations. Open sourcing the IDO planner will provide an opportunity for Intel Labs to engage with the cloud and edge ecosystem. Intel Labs plans to do research on observability through telemetry data, planning and decision making, and artificial intelligence/machine learning (AI/ML)-driven closed-loop automation for applications deployed at the cloud and edge.

As more and more applications are developed with cloud-native deployment styles in mind, we envision that resource allocation will move from declarative requests for specific resources to intent-driven requests based on KPIs, such as required latency, throughput, or reliability targets. This follows the overall trend of moving toward serverless, low-code environments, in which the underlying hardware is abstracted from the users. With IDO, we’re leaving it to the autonomous orchestration stack to determine how to set up the environment to ensure we reach the targeted intents and associated objectives. This can be achieved as this autonomous close-loop feedback system gains a better understanding of the context of the platform, allowing the efficient allocation of resources as needed. By adding a planning component to a Kubernetes-based orchestration stack, IDO can translate service objectives into actionable decisions on the minimal resources needed to fulfill the KPIs.

Watch a demonstration of Intent-Driven Orchestration.

Solving Resource Allocation Requests

Many orchestration and management systems are highly resource-oriented, and allocations are commonly based on resource requests. However, declarative requests based on specific resource requirements have drawbacks. Users need to have detailed knowledge about the available resources, but the quantification of the resource requirements may not be easily determined (for example, the exact performance characteristics of the targeted platform need to be known to make optimal resource requests). Incorrectly specified resource requirements can often lead to suboptimal performance, faults, or under-allocation and overallocation of resources.

Users of serverless and low-code platforms need less knowledge about resource allocations and do not have to worry about what hardware their code will run on when using cloud-native app design paradigms. These factors are driving the gradual transition from a resource-oriented requirement definition model to an intent-driven one in the future.

IDO Platform Features

IDO supports resource allocation methodologies and can support vertical and horizonal scaling of cloud-native applications. With IDO, platform features can be configured and set up without the service owner explicitly requesting them or knowing about their existence. The IDO model can autonomously enable available platform features, showcasing ease of use for application and resource owners in benefitting from platform-differentiating features. For example, platform features include but are not limited to the following:

Intel® Speed Select Technology (Intel® SST)

IDO integrates with Intel Speed Select Technology (Intel SST) to allocate the right amount of CPU resources needed for the targeted application intents and associated objectives. In addition to CPU rightsizing, the associated CPU cores are set to the most efficient power profile, ensuring the power consumption of the least amount of energy needed for the given SLO targets.

Intel® Resource Director Technology (Intel® RDT)

IDO also integrates with Intel Resource Director Technology (Intel RDT) to make sure the right amount of memory and cache resources are allocated based on the targeted intents and associated objectives. IDO can autonomously enable platform features in a dynamic manner, which is helpful in resource constraint environments with multiple applications running on a shared platform.

Deep Dive: Intent-Driven Orchestration Uses Planning Component

Here’s an overview on how the IDO system works: A planning component is embedded in the Kubernetes control plane to enable intent-driven orchestration in the closed loop system. The intents are defined as objects in the K8s cluster while they are assessed by the planning component. This component continuously watches the current state of the user’s KPIs and the system’s telemetry information, using a planning algorithm to generate a set of actions to keep the desired and current state close. Various orchestration actions can be performed through plugin actuators supporting different kinds of resources.

Figure 1. The IDO planning component uses a pluggable architecture.

The planner continuously compares the current state of a workload instance to the desired one, and dynamically adjusts to meet the target objective. Different workloads, such as microservices, functions, or others, require different resource management techniques. While compute-intensive and cache-sensitive workloads benefit from memory bandwidth and last-level-cache tuning, others might benefit from scaling out and/or up.

Figure 2. Autonomous intent management is enabled by foreground and background flows.

In the ML-based autonomous intent management system, data from observability stacks is processed using AI/ML techniques, forming a continuously running background flow that gives insight into the effect of orchestration actions on target objectives. These insights are stored in a knowledge base as lookup tables, regression models, or neural networks, for example. The insights are then used in a foreground flow where the service owner requests the intents and the orchestration stack tries to adhere to the given targets within the bounds of the effects possible with resource assignment. This flow enables closed-loop automation for managing the intents. IDO uses this type of reactive planning where the planner reacts to an event and uses current insights to determine a possible set of actions. The platform can also use opportunistic planning where the planner tries to bring the current state closer to the goal state (although the goal state cannot be reached), and proactive planning where the planning component and its plugins try to explore the effect of an orchestration action.

Instead of relying on domain knowledge, IDO enables users in serverless environments to define what they really care about — their application objectives.