Skip to content

Architecture

Jump to bottom
DragonBanana edited this page Dec 18, 2020 · 8 revisions

Architecture

The diagram shows our architecture proposal to implement the COCOS controller system over Kubernetes. This decision was driven by COCOS hard maintainability, since it was nested inside Kubernetes. So we have decided to propose a component which can be deployed on Kubernetes, allowing us to fully exploit its API and grants little effort on maintaining it unless the underlying API does not change (specifically the part related to the in place pod resource update). The resulting system has three sub components to achieve the coordination between vertical and horizontal scaling techniques implemented in COCOS and are briefly explained below.

Sub components

  • PodScale Controller: performs the matching between Pods to autoscale and the Service Level Agreement declared by the user. It handles the PodScale resources lifecycle (see CRDs description for further details).
  • Pod Autoscaler: this component wraps the recommending and the vertical scaling. The following components runs under the hood:
    • Recommender: computes the optimal resource allocation per pod.
    • Contention Manager: converts the optimal resource allocation in a feasible one by taking into account the resources available on the node.
    • Pod Resource Updater: applies the vertical scaling changes decided by the Contention Manager.
  • Pod Replicas Updater: decides whether to scale horizontally or not based on potential differences between the optimal and feasible resource allocation.

External components

Metrics architecture

In order to work, the autoscaler needs to access metrics (E.G. response time of the pod), which is not available by default from Kubernetes. We developed an external component (by extending the NGINX Ingress) that collects response data and expose them as metrics.

  • Metrics Ingestion: This component is connected to the NGINX Ingress by a shared volume (/var/log/nginx), and it saves on a external storage all the information written in the Ingress log.
  • Metrics Storage: This component stores the response information and can be queried in order to provides metrics like the response time.
  • Metrics Exposer: This component expose an HTTP endpoint which provides the metrics of a pod.

For more information

Clone this wiki locally