Operator Framework: Building Apps on Kubernetes
1–10 of 46 posts
Re: Operator Framework: Building Apps on Kubernetes
#2Can 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).
Re: Operator Framework: Building Apps on Kubernetes
#3Can 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).
You can think of K8s Controllers/Operators as a way to extend the K8s API at runtime with a new type of object that is managed by a controller you've written yourself (as opposed to the built in k8s objects that are handled by the default controller-manager).
A Helm chart by comparison is a way to template out K8s objects to make them configurable for different environments.
Some shops will end up combining one with the other.
Re: Operator Framework: Building Apps on Kubernetes
#4Can 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).
The main difference of Operators is explained here https://coreos.com/blog/introducing-operators.html Operators basically encapsulate human operational knowledge on a particular system, like how do you run a Memcached Ring on Kubernetes capsulated by https://github.com/ianlewis/memcached-operator.
Re: Operator Framework: Building Apps on Kubernetes
#5> 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.
Re: Operator Framework: Building Apps on Kubernetes
#6Can 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).
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...
Re: Operator Framework: Building Apps on Kubernetes
#7> 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…
Your comment would be more useful if it shared any hands-on experience with Operators instead of the usual ranting. I think you've made your general opinion on containers and Kubernetes pretty clear already.
Re: Operator Framework: Building Apps on Kubernetes
#8> 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…
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
Re: Operator Framework: Building Apps on Kubernetes
#9> 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…
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 covers his lack of response to k8s threads in his bio at https://news.ycombinator.com/user?id=cookiecaper. There is an email if you want to contact him directly.
Re: Operator Framework: Building Apps on Kubernetes
#10> 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…
Your comment would be more useful if it shared any hands-on experience with Operators instead of the usual ranting. I think you've made your general opinion on containers and Kubernetes pretty clear already.
First, I don't think anyone notices or cares when I post specifically, so it's hard to really feel like my "general opinion" is well-known enough to not talk about it anymore. I'm no Joel Spolsky over here!
Second, I feel like it's valid to point out that Operators are not really just a method of "packaging", in a post that tries to make it sound like Operators are just a small bit of YAML or metadata. You're writing real, non-trivial Go code that tells Kubernetes explicitly how to deploy and manage the lifecycles of specific types of applications.
At least until now with the "Operator Framework", there wasn't really even anything that firmly defined an Operator as an Operator; it's just what some people called their Go code that manipulated k8s's object handling and lifecycle internals.
But, if you insist, here's one operator I've worked with: https://github.com/coreos/prometheus-operator . This is from CoreOS itself.
Here's a patch I submitted about a year ago: https://github.com/coreos/prometheus-operator/pull/289 . This required updating the way the software handled HTTP response codes in one of its "watcher" daemons (because all packaging methods need those, right?), and fixing the order of operations in the bootstrap scripts.
Some more general info about this repo:
$ du -sh prometheus-operator/.git
51M prometheus-operator/.git
$ git rev-list --count master
1716
$ cloc --vcs=git --exclude-dir vendor,example,contrib .
290 text files.
278 unique files.
121 files ignored.
github.com/AlDanial/cloc v 1.74 T=0.82 s (295.4 files/s, 48117.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Go 50 1581 1392 20622
JSON 9 0 0 6276
YAML 132 260 885 4164
Markdown 30 792 0 2957
Bourne Shell 17 65 58 257
make 1 34 2 91
Python 1 10 5 40
TOML 1 11 20 30
Dockerfile 2 8 0 27
-------------------------------------------------------------------------------
SUM: 243 2761 2362 34464
-------------------------------------------------------------------------------
I dunno, it just feels a little disingenuous, to me, to say that something that involves this much code is just a "packaging method" for a normal application. "Sure, just write an operator to package that up" like it's comparable to a package.json manifest or something. It's not! You need custom daemons that watch files to make sure that your k8s deployment stays in sync, and then you need to exert very meticulous and specific control over Kubernetes' behavior to make things work well.
I think it's demonstrative that it takes north of 20k lines of Go code to package an application for deployment on Kubernetes. What do you think?
-------------
EDIT: And one clarification: my opinion on containers as such is probably not well-known, since you're conflating it with my opinion on Kubernetes.
I like containers conceptually (who wouldn't?) and I run several of them through LXC:
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
axxxx-dev STOPPED 0 - - - false
gentoo-encoder STOPPED 0 - - - false
jeff-arch-base-lxc STOPPED 0 - - - false
jeff-crypto RUNNING 0 - xxx.xxx.xx.xxx - false
jeff-ffmpeg STOPPED 0 - - - false
jeff-netsec STOPPED 0 - - - false
jeff-ocr STOPPED 0 - - - false
localtorrents-lxc RUNNING 0 - xxx.xxx.xx.xxx - false
nim-dev STOPPED 0 - - - false
plex-2018 RUNNING 1 - xxx.xxx.xxx.xxx - true
unifi STOPPED 0 - - - true
There is a good place for Kubernetes in probably about 1% of deployments where it's used. Most other people are just trying to run something like LXC, but they're confused because everyone who is critical of k8s drops to -4 and gets HN's mods after them. :)