开源工具：容器集群的调度与弹性

GitHub - kube-arbiter/arbiter: An extendable scheduling and scaling tool built on Kubernetes
 

An extendable scheduling and scaling tool based on Kubernetes​

Arbiter is an extendable scheduling and scaling tool built on Kubernetes. It’ll aggregate various types of data and take them into account when managing, scheduling or scaling the applications in the cluster. It can facilitate K8S users to understand and manage resources deployed in the cluster, and then use this tool to improve the resource utilization and runtime efficiency of the applications.

The input can be metrics from your monitoring system, logs from your logging system or traces from your tracing system. Then arbiter can abstract the data to a unified format，so it can be consumed by scheduler, autoscaler or other controllers. Arbiter can also add labels to your applications based on how the administrator defines the classification and the data it collects. User can understand the characteristics of each application and the overall placement across the cluster, and then tune the factors that can improve it.

The high level architecture of this project: 

The focus of current project is to integrate with various observability tools and generate the indicator that can be used by Kubernetes scheduler, scaler (HPA / VPA) or other extended executors, to make it more easy to enhance and extend for different scenarios.

Quick Start​

See our documentation on Quick Start

View data using the dashboard​

You can also install the dashboard for better visualization, will add later.

Features​

1. Get the cluster metrics for resource usage, such as cluster capacity、system resource usage，reserved resource and actual resource usage
2. Usage trend of various resources
3. Grafana template to show cluster metrics
4. Scheduling based on actual resource usage of node
5. Classify the pod/deployment/statefulset/service based on the resource sensitivity and the baseline defined by the administrator
6. Support grouping of nodes for resource isolation
7. Oversold configuration of pod and node for temporary resource feed

Scenarios​

Here are some typical scenarios we're trying to provide possible solutions using arbiter, refer to User Cases

Build and contribute Arbiter​

If you want to build Arbiter, refer to Contribute

Roadmap​

You can get what we're doing and plan to do here.

v0.1 - done​

1. Define what's OBI(Observability Indicator) that can convert metrics/logging/tracing to an unified indicator, so we can use OBI for scheduler and scaler.
2. Introduce a context to let user extend scheduler easily using Javascript, and let user write Javascript to implement schedule logic.
3. Create a plugin framework that can integrate with different observability tools as input and generate OBI output, such as metric-server, prometheus etc...
4. Create a command line tool called 'abctl' to get OBI for K8S resources
5. Create sample use cases using current framework to show how it can work, including:

• Schedule Pod based on actual resource usage on nodes
• Schedule Pod based on node labels using different schedule policy
• Tag the pod/service for different resource sensitivity
• Schedule based on pod and node names/labels without define node affinity
• Reserve node resource in the scheduler extension
• Provide executor to demo how to use OBI to support various use cases.

v0.2 - working on now​

1. Use kube-scheduler-simulator to evaluate the effect of different schedule policy
2. Support logging indicator in the observer plugins
3. Enhance the executor framework, so the user can easily define actions based on the results of OBI.
4. Allow to use Kubernetes scheduler policy dynamically in scheduler extension
5. Add more samples to generate OBI to introduce popular indicators, so the user can use directly