• This repository has been archived on 27/Jan/2021
  • Stars
    star
    463
  • Rank 94,661 (Top 2 %)
  • Language
    Go
  • License
    MIT License
  • Created almost 6 years ago
  • Updated over 4 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

A general purpose, scale-to-zero component for Kubernetes

Osiris - A general purpose, Scale to Zero component for Kubernetes

CircleCI

Osiris enables greater resource efficiency within a Kubernetes cluster by allowing idling workloads to automatically scale-to-zero and allowing scaled-to-zero workloads to be automatically re-activated on-demand by inbound requests.

Osiris, as a concept, is highly experimental and currently remains under heavy development.

How it works

Various types of Kubernetes resources can be Osiris-enabled using an annotation.

Osiris-enabled pods are automatically instrumented with a metrics-collecting proxy deployed as a sidecar container.

Osiris-enabled deployments (if already scaled to a configurable minimum number of replicas-- one by default) automatically have metrics from their pods continuously scraped and analyzed by the zeroscaler component. When the aggregated metrics reveal that all of the deployment's pods are idling, the zeroscaler scales the deployment to zero replicas.

Under normal circumstances, scaling a deployment to zero replicas poses a problem: any services that select pods from that deployment (and only that deployment) would lose all of their endpoints and become permanently unavailable. Osiris-enabled services, however, have their endpoints managed by the Osiris endpoints controller (instead of Kubernetes' built-in endpoints controller). The Osiris endpoints controller will automatically add Osiris activator endpoints to any Osiris-enabled service that has lost the rest of its endpoints.

The Osiris activator component receives traffic for Osiris-enabled services that are lacking any application endpoints. The activator initiates a scale-up of a corresponding deployment to a configurable minimum number of replicas (one, by default). When at least one application pod becomes ready, the request will be forwarded to the pod.

After the activator "reactivates" the deployment, the endpoints controller (described above) will naturally observe the availability of application endpoints for any Osiris-enabled services that select those pods and will remove activator endpoints from that service. All subsequent traffic for the service will, once again, flow directly to application pods... until a period of inactivity causes the zeroscaler to take the application offline again.

Scaling to zero and the HPA

Osiris is designed to work alongside the Horizontal Pod Autoscaler and is not meant to replace it-- it will scale your pods from n to 0 and from 0 to n, where n is a configurable minimum number of replicas (one, by default). All other scaling decisions may be delegated to an HPA, if desired.

This diagram better illustrates the different roles of Osiris, the HPA and the Cluster Autoscaler:

diagram

Setup

Prerequisites:

  • Helm (v3.0.0 or greater)
  • A running Kubernetes cluster.

Installation

Osiris' Helm chart is hosted in an Azure Container Registry, which does not yet support anonymous access to charts therein. Until this is resolved, adding the Helm repository from which Osiris can be installed requires use of a shared set of read-only credentials.

Make sure helm is initialized in your running kubernetes cluster.

For more details on initializing helm, Go here

helm repo add osiris https://osiris.azurecr.io/helm/v1/repo \
  --username eae9749a-fccf-4a24-ac0d-6506fe2a6ab3 \
  --password =s-e.2-84BhIo6LM6=/l4C_sFzxb=sT[

Installation requires use of the --devel flag to indicate pre-release versions of the specified chart are eligible for download and installation. The following command install the latest version of Osiris with the default values for all options - see the next section for all available installation options.

kubectl create namespace osiris-system
helm install osiris osiris/osiris-edge \
  --namespace osiris-system \
  --devel

Installation Options

Osiris global configuration is minimal - because most of it will be done by the users with annotations on the Kubernetes resources.

The following table lists the configurable parameters of the Helm chart and their default values.

Parameter Description Default
zeroscaler.metricsCheckInterval The interval in which the zeroScaler would repeatedly track the pod http request metrics. The value is the number of seconds of the interval. Note that this can also be set on a per-deployment basis, with an annotation. 150

Example of installation with Helm and a custom configuration:

kubectl create namespace osiris-system
helm install osiris osiris/osiris-edge \
  --namespace osiris-system \
  --devel \
  --set zeroscaler.metricsCheckInterval=600

Usage

Osiris will not affect the normal behavior of any Kubernetes resource without explicitly being directed to do so.

To enabled the zeroscaler to scale a deployment with idling pods to zero replicas, annotate the deployment like so:

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: my-aoo
  name: my-app
  annotations:
    osiris.deislabs.io/enabled: "true"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        osiris.deislabs.io/enabled: "true"
    # ...
  # ...

Note that the template for the pod also uses an annotation to enable Osiris-- in this case, it enables the metrics-collecting proxy sidecar container on all of the deployment's pods.

In Kubernetes, there is no direct relationship between deployments and services. Deployments manage pods and services may select pods managed by one or more deployments. Rather than attempt to infer relationships between deployments and services and potentially impact service behavior without explicit consent, Osiris requires services to explicitly opt-in to management by the Osiris endpoints controller. Such services must also utilize an annotation to indicate which deployment should be reactivated when the activator component intercepts a request on their behalf. For example:

kind: Service
apiVersion: v1
metadata:
  namespace: my-namespace
  name: my-app
  annotations:
    osiris.deislabs.io/enabled: "true"
    osiris.deislabs.io/deployment: my-app
spec:
  selector:
    app: my-app
  # ...

Configuration

Most of Osiris configuration is done with Kubernetes annotations - as seen in the Usage section.

Deployment Annotations

The following table lists the supported annotations for Kubernetes Deployments and their default values.

Annotation Description Default
osiris.deislabs.io/enabled Enable the zeroscaler component to scrape and analyze metrics from the deployment's pods and scale the deployment to zero when idle. Allowed values: y, yes, true, on, 1. no value (= disabled)
osiris.deislabs.io/minReplicas The minimum number of replicas to set on the deployment when Osiris will scale up. If you set 2, Osiris will scale the deployment from 0 to 2 replicas directly. Osiris won't collect metrics from deployments which have more than minReplicas replicas - to avoid useless collections of metrics. 1
osiris.deislabs.io/metricsCheckInterval The interval in which Osiris would repeatedly track the pod http request metrics. The value is the number of seconds of the interval. Note that this value override the global value defined by the zeroscaler.metricsCheckInterval Helm value. value of the zeroscaler.metricsCheckInterval Helm value

Pod Annotations

The following table lists the supported annotations for Kubernetes Pods and their default values.

Annotation Description Default
osiris.deislabs.io/enabled Enable the metrics collecting proxy sidecar container to be injected into this pod. Allowed values: y, yes, true, on, 1. no value (= disabled)
osiris.deislabs.io/ignoredPaths The list of (url) paths that should be "ignored" by Osiris. Requests to such paths won't be "counted" by the proxy. Format: comma-separated string. no value

Service Annotations

The following table lists the supported annotations for Kubernetes Services and their default values.

Annotation Description Default
osiris.deislabs.io/enabled Enable this service's endpoints to be managed by the Osiris endpoints controller. Allowed values: y, yes, true, on, 1. no value (= disabled)
osiris.deislabs.io/deployment Name of the deployment which is behind this service. This is required to map the service with its deployment. no value
osiris.deislabs.io/loadBalancerHostname Map requests coming from a specific hostname to this service. Note that if you have multiple hostnames, you can set them with different annotations, using osiris.deislabs.io/loadBalancerHostname-1, osiris.deislabs.io/loadBalancerHostname-2, ... no value
osiris.deislabs.io/ingressHostname Map requests coming from a specific hostname to this service. If you use an ingress in front of your service, this is required to create a link between the ingress and the service. Note that if you have multiple hostnames, you can set them with different annotations, using osiris.deislabs.io/ingressHostname-1, osiris.deislabs.io/ingressHostname-2, ... no value
osiris.deislabs.io/ingressDefaultPort Custom service port when the request comes from an ingress. Default behaviour if there are more than 1 port on the service, is to look for a port named http, and fallback to the port 80. Set this if you have multiple ports and using a non-standard port with a non-standard name. no value
osiris.deislabs.io/tlsPort Custom port for TLS-secured requests. Default behaviour if there are more than 1 port on the service, is to look for a port named https, and fallback to the port 443. Set this if you have multiple ports and using a non-standard TLS port with a non-standard name. no value

Note that you might see an osiris.deislabs.io/selector annotation - this is for internal use only, and you shouldn't try to set/update or delete it.

Demo

Deploy the example application hello-osiris :

kubectl create -f ./example/hello-osiris.yaml

This will create an Osiris-enabled deployment and service named hello-osiris.

Get the External IP of the hello-osiris service once it appears:

kubectl get service hello-osiris -o jsonpath='{.status.loadBalancer.ingress[*].ip}'

Point your browser to "http://<EXTERNAL-IP>", and verify that hello-osiris is serving traffic.

After about 2.5 minutes, the Osiris-enabled deployment should scale to zero replicas and the one hello-osiris pod should be terminated.

Make a request again, and watch as Osiris scales the deployment back to one replica and your request is handled successfully.

Limitations

It is a specific goal of Osiris to enable greater resource efficiency within Kubernetes clusters, in general, but especially with respect to "nodeless" Kubernetes options such as Virtual Kubelet or Azure Kubernetes Service Virtual Nodes, however, due to known issues with those technologies, Osiris remains incompatible with them for the near term.

Contributing

Osiris follows the CNCF Code of Conduct.

More Repositories

1

wagi

Write HTTP handlers in WebAssembly with a minimal amount of work
Rust
882
star
2

hippo

The WebAssembly Platform
TypeScript
414
star
3

spiderlightning

A set of WIT definitions and associated implementations to enable app developers to work at a faster pace and require less knowledge of the environment in which they are executing.
Rust
309
star
4

containerd-wasm-shims

containerd shims for running WebAssembly workloads in Kubernetes
Rust
305
star
5

bindle

Bindle: Object Storage for Collections
Rust
263
star
6

ratify

Artifact Ratification Framework
Go
182
star
7

mystikos

Tools and runtime for launching unmodified container images in Trusted Execution Environments
C
142
star
8

wasi-experimental-http

Experimental outbound HTTP support for WebAssembly and WASI
Rust
135
star
9

example-bundles

CNAB bundles
JavaScript
85
star
10

yo-wasm

Yeoman generator for Rust projects intended to build to WASM in OCI registries
TypeScript
63
star
11

kc-eu-2023-k8s-wasm-microservices

JavaScript
49
star
12

wasi-nn-onnx

Experimental ONNX implementation for WASI NN.
Rust
47
star
13

image-layer-provenance

Container image provenance spec that allows tracing CVEs detected in registry images back to a CVE's source of origin.
Go
40
star
14

wagi-fileserver

A static file server for Wagi written in Grain
Makefile
32
star
15

wagi-dotnet

WAGI allows you to run WebAssembly WASI binaries as HTTP handlers. WAGI-dotnet provides an extension that enables these handlers to be run in an ASP.Net Core application
C#
29
star
16

helm-workshop

Helm workshop for KubeCon Seattle 2018
26
star
17

kind-vscode

Integrating the Kind local Kubernetes cluster into Visual Studio Code
TypeScript
22
star
18

hippo-cli

The Hippo CLI
Rust
19
star
19

krustlet-wasm3

Krustlet provider for the wasm3 runtime.
Rust
18
star
20

wasm-linker-js

A simple WebAssembly Linker in JavaScript
TypeScript
17
star
21

duffle-vscode

VS Code extension for Duffle, the CNAB installer
TypeScript
14
star
22

cnab-workshop

CNAB / Duffle workshop for KubeCon Seattle 2018
13
star
23

krustlet-wagi-provider

A Krustlet Provider for WAGI modules.
Rust
12
star
24

cnab-netstandard

.NET Standard 2.0 Client Library for CNAB
C#
12
star
25

duffle-bag

GUI tooling for CNAB bundles
TypeScript
10
star
26

hello-wagi-as

Write an HTTP responder in AssemblyScript using WASI
TypeScript
9
star
27

kubernetes-opa-vscode

A VS Code extension for working with Open Policy Agent in Kubernetes
TypeScript
8
star
28

wok

WASM on Kubernetes (WOK)
Rust
8
star
29

microk8s-vscode

Integrating the Microk8s local Kubernetes cluster into Visual Studio Code
TypeScript
8
star
30

wagi-azure-samples

WebAssembly modules that use Azure services
Rust
8
star
31

gatekeeper-vscode

Rapidly develop and test Gatekeeper policies in Visual Studio Code
TypeScript
8
star
32

dapr-wasm-exp

Dapr + Wasm experiments
Go
8
star
33

deislabs.io

Info about Deis Labs. Open Source from Microsoft Azure.
Sass
7
star
34

cnab-operator

Experimental CNAB operator for Kubernetes. WIP.
Go
7
star
35

env_wagi

An environment dumper, implemented as a WebAssembly Gateway Interface module (WASI)
Rust
7
star
36

gnarly

Go
7
star
37

magick8sball.io

companion site for the magic k8s ball ✨
SCSS
7
star
38

dwaft

A tool to make building and debugging WASM for outside the browser a breeze
Rust
6
star
39

pilothouse

Experimenting with Helm in Rust
Rust
6
star
40

wagi-examples

TypeScript
6
star
41

cnab-azure-driver

Azure CNAB Driver
Go
6
star
42

ratify-web

MDX
6
star
43

vscode-kubernetes-access-viewer

TypeScript
6
star
44

hello-wagi-grain

An example of using the Grain language to write Wagi modules
5
star
45

duffle-coat

VS Code extension for generating CNAB self-installers
TypeScript
5
star
46

rusty-macaroon

A Macaroon implementation in Rust
Rust
4
star
47

cnab-dashboard

HTML
2
star
48

bindle-dotnet

A Bindle client for the .NET runtime
C#
2
star
49

cnab-voting-app-demos

CNAB Voting App Demos
Makefile
2
star
50

art

Original vectors for our projects logos and graphics
2
star
51

kubectl-output-parser

Functions for parsing kubectl output
TypeScript
2
star
52

hippo-docs

Website for Hippo
HTML
2
star
53

ratify-verifier-plugin

Go
2
star
54

echo-provider

A simple waSCC provider for testing
Rust
2
star
55

draft-brigade-workshop

Draft / Brigade workshop for KubeCon
JavaScript
1
star
56

bindle-js

A TypeScript/JavaScript Bindle client
TypeScript
1
star
57

azure-sdk-for-rust-wasi-samples

Rust
1
star
58

hippo-client-rust

A Rust client library for Hippo
Rust
1
star
59

ratify-action

Ratify Github Action
Shell
1
star
60

spiderlightning-gh-latest-commits-demo

Rust
1
star
61

bindle-server-azure

An azure storage implementation and server for Bindle
Rust
1
star
62

wagi-fileserver-c

A static file server for Wagi written in C
Makefile
1
star
63

duffle.sh

much ado about duffle
SCSS
1
star