Skip to content

Latest commit

 

History

History
31 lines (19 loc) · 3.31 KB

agent-in-depth.md

File metadata and controls

31 lines (19 loc) · 3.31 KB

Akri Agent

The Akri Agent executes on all worker Nodes in the cluster. It is primarily tasked with:

  1. Handling resource availability changes
  2. Enabling resource sharing

These two tasks enable Akri to find configured resources (leaf devices), expose them to the Kubernetes cluster for workload scheduling, and allow resources to be shared by multiple Nodes.

Handling resource availability changes

The first step in handling resource availability is determining what resources (leaf devices) to look for. This is accomplished by finding existing Configurations and watching for changes to them.

Once the Akri Agent understands what resources to look for (via Configuration.discovery_handler), it will find any resources that are visible.

For each resource that is found:

  1. An Instance is created and uploaded to etcd
  2. A connection with the kubelet is established according to the Kubernetes Device Plugin framework. This connection is used to convey availability changes to the kubelet. The kubelet will, in turn, expose these availability changes to the Kubernetes scheduler.

Each protocol will periodically reassess what resources are visible and update both the Instance and the kubelet with the current availability.

This process allows Akri to dynamically represent resources that appear and disappear.

Enabling resource sharing

To enable resource sharing, the Akri Agent creates and updates the Instance.deviceUsage map and communicates with kubelet. The Instance.deviceUsage map is used to coordinate between Nodes. The kubelet communication allows Akri Agent to communicate any resource availability changes to the Kubernetes scheduler.

For more detailed information, see the in-depth resource sharing doc.

Resource discovery

The Agent discovers resources via Discovery Handlers (DHs). A Discovery Handler is anything that implements the DiscoveryHandler service defined in discovery.proto. In order to be utilized, a DH must register with the Agent, which hosts the Registration service defined in discovery.proto. The Agent maintains a list of registered DHs and their connectivity status, which is either Waiting, Active, or Offline(Instant). When registered, a DH's status is Waiting. Once the Agent has successfully created a connecting with a DH, due a Configuration requesting resources discovered by that DH, it's status is set to Active. If the Agent is unable to connect or loses a connection with a DH, its status is set to Offline(Instant). The Instant marks the time at which the DH became unresponsive. If the DH has been offline for more than 5 minutes, it is removed from the Agent's list of registered discovery handlers. If a Configuration is deleted, the Agent drops the connection it made with all DHs for that Configuration and marks the DHs' statuses as Waiting. Note, while probably not commonplace, the Agent allows for multiple DHs to be registered for the same protocol. IE: you could have two udev DHs running on a node on different sockets.

Supported DHs each have a library and a binary implementation. This allows them to either be run within the Agent binary or in their own Pod.