lakshan-banneheke / brownout-controller Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 278 KB

Go 99.65% Dockerfile 0.35%

brownout-controller's Introduction

Hello, I'm Lakshan

Software Engineer - WSO2

🔭 My final year research project - The research investigates the use of the brownout approach for container orchestration to achieve energy efficiency in containerized applications on edge clusters. A software system consisting of an analytical model to compute the power consumption and a brownout controller for container orchestration is being developed.
👨‍💻 Projects:
💼 Work Experience
- WSO2 LLC - Software Engineer
- WSO2 LLC - Software Engineering Intern
- iXD Labs (Pvt) Ltd - Software Engineering Intern
📝 Certifications
- Microsoft Certified: Azure Fundamentals
- WSO2 Certified Identity Server Developer - V5
📫 How to reach me [email protected]

Skills

Programming Languages

Cloud Technologies

Web Development

Mobile Development

Databases

My GitHub Stats

Connect with me

brownout-controller's People

Contributors

Watchers

brownout-controller's Issues

Improvement to consider battery percentage in main brownout algorithm

Get the battery percentage via an API endpoint and activate and deactivate the brownout algorithm when its within a certain range.
Obtain a battery min value to activate the algorithm and a max battery value to deactivate the algorithm.

Implement the Node Idling Selection Policy algorithm

Configure Docker file and Kubernetes manifest for Raspberry Pi deployment

The Docker file and Kubernetes manifests to build and deploy on a Raspberry Pi are in the rpi-deploy branch

https://github.com/Lakshan-Banneheke/brownout-controller/tree/rpi-deploy

Implement the LUCF container selection policy algorithm

Develop the web frontend interface/dashboard

Implement the HUCF container selection policy algorithm

Issue with using LUCF per node within NISP

Lucf uses GetPodsPower to calculate the power when used within NISP. It doesnt consider that some nodes have been turned off. GetPodsPower uses the full worker node count when calculating power.

Integrate Prometheus for monitoring to get SLA violations

DeactivateNode needs to prevent new pods from being created in the deactivated node.

Issue

New pods may get scheduled on a node that is deactivated and made idle.
Eg: If the user creates a new deployment, those pods may get created on the deactivated node.
If that node is turned off after a new pod has gotten scheduled, that will cause issues

This will help when doing container migration as well

Solutions

Cordon off the node - But then how can it be reconnected
Add a label to mark a node as idle

Develop the dashboard

Functionality on deactivating containers

Improvements to make the applications more efficient for the edge environments.

Use watchers instead of periodic polling
Deactivating pods deployment-wise
Improve error handling

Develop analytical model to compute power consumption based on cluster configurations

Implement the RCSP container selection policy algorithm

Connect to Kubernetes Cluster

Improvements after experimentation

Implement the LRU container selection policy algorithm

Integrate the power model with the abstract policy and nisp

The following functions are required in the power model

Get the power given a set of pods in the cluster
Get the power given a set of nodes in the cluster

Once the functions are available, need to use them in the executePolicy method in both abstract policy and nisp

Container Migration to improve the power saved in NISP

Migrating containers from the least utilized nodes to the other nodes will allow more nodes to be idle.

Since some containers of the "i"th node will be removed based on LUCF within the NISP policy, it is possible to migrate these containers to other nodes to make the "i"th node idle as well which will further improve the power saved.

Draining the "i"th node using the Kubernetes API will automatically make that node idle and migrate its containers to other nodes