https://github.com/sapcc/kubernetes-operators

Operators that automate common tasks for managing Openstack on Kubernetes.
https://github.com/sapcc/kubernetes-operators

kubernetes openstack operators

Last synced: 21 days ago
JSON representation

Operators that automate common tasks for managing Openstack on Kubernetes.

• Host: GitHub
• URL: https://github.com/sapcc/kubernetes-operators
• Owner: sapcc
• License: apache-2.0
• Created: 2016-11-18T12:14:57.000Z (about 8 years ago)
• Default Branch: master
• Last Pushed: 2024-10-24T05:52:05.000Z (27 days ago)
• Last Synced: 2024-10-24T23:57:02.460Z (27 days ago)
• Topics: kubernetes, openstack, operators
• Language: Go
• Size: 63.9 MB
• Stars: 124
• Watchers: 45
• Forks: 14
• Open Issues: 37
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# Kubernetes Openstack Operators

This repository holds operators that automate common tasks for managing

Openstack on Kubernetes.

We define an operator as piece of software that uses Kubernetes primitives to

model domain specific operational tasks. It extends Kubernetes using best

practices and controller concepts to remote control the system through the API

on behalf of a Kubernetes user. Using the third party resource mechanismm, this

allows us to detangle configuration changes and offloads the burden of

generating and reconfiguring the system into a dynamic runtime component.

See also: [CoreOS - Introducing Operators](https://coreos.com/blog/introducing-operators.html)

## Example 

As an example, a [ThirdPartyResource](http://kubernetes.io/docs/user-guide/thirdpartyresources/) `BuildingBlock` drives the creation of

a set of Nova-Agents through a `DeploymentSpec`. The operator will watch for

changes on `BuildingBlock` events and create/update the specs for the nova

agents. Additionally, it could remote control auxiliary systems, like sending a

status notification when a builing block goes into maintenance mode.

Now that building block configuration can be manages as Kubernetes spec, we

have a standarized way of changing the system's configuration - through

Kubernetes. This decoupling reduces the churn on the redeployment of the whole

system and makes changes easy and documentable. 

Additionally, "change" is now easy to compose even across system boundaries.

A new building block can be onboarded with an automated process, directly from

a build pipeline, triggered by a Git commit. Even auto-registration is

a thinkable scenario now. The building block could come with an agent that

talks directly to Kubernetes.

## Design Principles

Operators are build in Go. They use [kubernetes/client-go](https://github.com/kubernetes/client-go) to interface with the 

Kubernetes API. They follow the Kubernetes controller best practices and

programatically manage resources. 

Operators have one job and do that job well. They are easy to reason about. 

## Prior Art

  * [sapcc/kube-parrot](https://github.com/sapcc/kube-parrot)

  * [coreos/etcd-operator](https://github.com/coreos/etcd-operator)

  * [coreos/prometheus-operator](https://github.com/coreos/prometheus-operator)

  * [kelseyhightower/kubernetes-certificate-manager](https://github.com/kelseyhightower/kube-cert-manager)