E.O.F.T. 17/18

“Choices”

the are ups and downs in life.

“Ice Call”

Just too fast.

“Follow The Fraser”⭐️

British Columbia is beautiful at winter and summer time.

“Into Twin Galaxies”⭐️⭐️

Seems to me Greenland is on my ‘must-visit’-list now!

“Dug Out”⭐️⭐️⭐️

The english men are still the most funny and real actors.

“Ushba”

Really impressive skiing, but I like snowboarding.

“La Congenialita”

Always two there are no more no less a master and an apprentice.

 

Kubernetes Operators (Introduction)

Kubernetes Operators as introduced by CoreOS Inc. are admin-state-machines. Their purpose is to run some kind of software and maintain its operational state. It’s basically an admin in software.

A good set of requirements can be found here (“How can you create an Operator?”)

The very basic concept is grounded on custom resource definitions (CRD, since K8s 1.7, previously known as third party resources, TPR). They describe the to-operated service and its relation to other parts.

All resources the operator maintains should be actively watched. Each event should create one or more administrative task which then should be fed into a working queue to prevent race-conditions. There can be one queue per operated service or even more, depending on their operational impact (e.g. one for K8s-specific tasks like deployment, one for backup/restore and another one for user-management or something like that.)

Each task should check its prerequisites and postconditions and should be rather atomic. More advanced implementations may handle this inside the operator itself (e.g. block other queues during critical an operation).

There will be a PoC for, I think, MariaDB here soon.