
Operator Framework: Building Apps on Kubernetes - polvi
https://coreos.com/blog/introducing-operator-framework
======
thedevopsguy
I've been an early adopter of docker. Used Compose when it was still called
Fig, used and deployed kubernetes beta up to version 1 for in-house
PAAS/heroku like environment.

Must say I do miss those days when K8s was an idea that could fit in your
head. The primitives were just enough back then. It was powerful developer
tool for teams and we used it aggressively to accelerate our development
process.

K8s has now moved beyond this and seems to me to be focussing strongly on its
operational patterns. You can see these operational patterns being used
together to create a fairly advanced on-prem cloud infrastructure. At times,
to me, it looks like over-engineering.

Looking at the borg papers, I don't remember seeing operational primitives
this advanced. The develop interface was fairly simple i.e this is my app,
give me these resources, go!

I know you don't have to use this new construct but it sure does make the
landscape a lot more complicated.

~~~
hardwaresofton
I agree that this new construct makes the landscape even more complicated, but
I disagree that k8s has reached the point of over-engineering. Most of the
parts of k8s are still essentially complex to me -- they're what you'd need if
you wanted to build a robust resource pool management kind of platform.

Ironically, the push to "simplify" the platform with various add-on tools is
what is making it seem more complicated. Rather than just bucking up and
telling everyone to read the documentation, and understand the concepts they
need to be productive, everyone keeps building random, uncoordinated things to
"help", and newcomers become confused.

For example, I don't know who this operator framework is aimed at -- it's not
at application developers, but at k8s component creators who write cluster-
level tools, but what cluster tool writer would want to write a tool without
understanding k8s at it's core? Those are the table stakes -- if I understand
k8s and already understand the operator pattern (which is really just a
Controller + a CRD, two essential bits of k8s), why would I use this
framework?

I think if they really wanted to help, they'd produce some good documentation
or a cookbook and maintain an annex of the state of the art in how to
create/implement operators. But that's boring, and has no notoriety in it.

~~~
pm90
I don’t see how these abstractions make the product more complex. They’re
still optional.

~~~
hardwaresofton
It's not that they force Kubernetes to be more complex, it's that they muddy
the waters. I clearly understand that they're optional, and that they're an
add-on essentially, but it might not look this way to a newcomer.

People are being encouraged to download a helm chart before they even write
their first kubernetes resource definition. People might start using this
Operator Framework before they implement their own operator from scratch
(that's kind of the point) -- though honestly it's unlikely that they'll
actually be clueless since it's for cluster operators.

------
pm90
Can anyone talk about the positives/negatives of Operators v/s Helm Charts?

From what I see, it seems like Operators are a better tool for defining and
deploying Custom k8s resources whereas helm charts are good way to organize
applications (deployment, service etc. templates packaged into one tar).

~~~
mfer
Helm and Community Charts maintainer here...

Helm is a package manager. Think of it like apt for Kubernetes.

Operators enable you to manage the operation of applications within
Kubernetes.

They are complementary. You can deploy an operator as part of a Helm Chart. I
recently wrote a blog post that explains how the different tools relate.
[https://codeengineered.com/blog/2018/kubernetes-helm-
related...](https://codeengineered.com/blog/2018/kubernetes-helm-related-
tools/)

~~~
nikolay
Any plans to switch from templatized YAML to Jsonnet/Ksonnet?

~~~
bryanlarsen
The helm 3 proposal uses Lua. Not sure if they've actually started working on
it: [https://github.com/kubernetes-
helm/community/blob/master/hel...](https://github.com/kubernetes-
helm/community/blob/master/helm-v3/000-helm-v3.md)

~~~
nikolay
Honestly, this is a terrible choice! I like Lua, but it's not mainstream, and
it's not going to be! There are tons of embeddable JavaScript engines - they
could've used TypeScript, too!

~~~
hobofan
> but it's not mainstream, and it's not going to be!

Why are you suggesting jsonnet then?

~~~
nikolay
Because it's popular in Kubernetes and makes sense, unlike Lua in the context.

------
hardwaresofton
__tl;dr __\- this is a rant. the operator pattern should stay a pattern.
"framework" and "application" are meaningless these days. Stop trying to make
things so easy a "monkey could do it".

No no no no no. The words "framework" and "application" are so meaningless now
that even reading this post is draining.

CoreOS pioneered the Operator _pattern_ , but I think building up that pattern
into a framework to get people developing it away from the knowing the basics
of k8s is such a mistake. The operator pattern falls out of the primitives
that k8s offers (there's _literally_ a concept called a controller) -- this
makes it seem like another app platform. I think the level of abstraction
isn't even right, this is like trying to enable people to write daemons
without knowing anything about linux or signals or processes.

Then again, I also dislike tools like Helm because they do the same thing. Why
is everyone so in a rush to make inevitably leaky abstractions to make
everything so easy a monkey could do it? All you're doing is encouraging
cookie cutter programmers to write cookie cutter poorly understood code that
will break on someone inevitably.

All essential complexity introduced by features in the layer below an
abstraction cannot be simplified, it can only be hidden or removed. It is OK
for things to be hard, as long as they are simple (in the rich hickey easy vs
simple analogy).

------
pgalgali
Can we use Operator Framework for building operators that also require new api
server using api aggregator?

------
cookiecaper
> _You may be familiar with Operators from the concept’s introduction in 2016.
> An Operator is a method of packaging, deploying and managing a Kubernetes
> application._

"Operators", as introduced in 2016, were just bespoke Go programs that
communicated with Kubernetes internals in a pretty low-level way.

You were writing special-case plugins for Kubernetes, but they didn't want to
make it _sound_ that way, because I guess that just doesn't sound hip or
devopsy. This branding exercise worked out for CoreOS -- Red Hat just bought
them.

This whole space is massively infused with bullshit. It's because all of these
companies want to make money selling you cloud stuff, because it's profitable
to rent computers at 3-5x the TCO. Google especially is hungry to claw back
the lead in the cloud space from Amazon, and it's not hard to conceive why
Kubernetes doesn't seem to work without fuss anywhere except GKE, or to
understand the massive marketing dollars that Google is pumping into this
whole Kubernetes farce (and for the record, Google seems to consider HN an
important platform for k8s PR; I've been censured after too many Googlers
found my k8s-skeptical posts "tedious").

Anyway, I guess that's neither here nor there. Just annoyed at what is by now
the totally conventional status quo of overhyped empty promises made by people
who seem more like ignorant promoters and fanboys than serious engineers.

This "Operator Framework" seems to be the same concept of Operators, just with
additional library support for the plugins -- err, "Operators". It may be a
good improvement, will have to research more.

~~~
TheIronYuppie
I'm sorry you've been down voted. FWIW, I've asked you several times for
feedback, but you've never responded. We'd love to be better!

Aronchick (at) google.com

Disclosure: I work at Google on Kubeflow

~~~
cookiecaper
Minor correction: I've replied a couple of times on HN and gotten no response.
You once clarified that this is because you don't check HN often enough to
reply before the deadline, which is fine. I do admit that you once sent me an
email and that I didn't reply to it.

