Live data from Hacker News

Operator Framework: Building Apps on Kubernetes

coreos.com

41–46 of 46 posts

Re: Operator Framework: Building Apps on Kubernetes

#41
post #12
post #6

Earlier quoted context omitted.

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...

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

> Any plans to switch from templatized YAML to Jsonnet/Ksonnet?

Not exactly. Two things to know...

First, a little history.

Only a tiny amount of people have asked for it. A prototype was created and no one, not even the ksonnet devs, were up for taking the work forward from the prototype phase. The code is still up on GitHub and Helm was built with the intent of more engines being used.

Second, ksonnet is going through some major changes right now. We can all come back and look on it again when it's ready.

Helm 3 is working to make it easier to bring your own tools, like jsonnet. It's just not likely to be baked in or replace YAML. People really aren't asking for it much.

Re: Operator Framework: Building Apps on Kubernetes

#42
post #39
post #36

Earlier quoted context omitted.

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!

> but it's not mainstream, and it's not going to be! Why are you suggesting jsonnet then?

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

Re: Operator Framework: Building Apps on Kubernetes

#43
post #37

Earlier quoted context omitted.

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 complicate…

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

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.

Re: Operator Framework: Building Apps on Kubernetes

#44
post #41
post #12

Earlier quoted context omitted.

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

> Any plans to switch from templatized YAML to Jsonnet/Ksonnet? Not exactly. Two things to know... First, a little history. Only a tiny amount of people have asked for it. A prototype was created and no one, not even the ksonnet devs, were up for taking the work forward from the prototype phase. The code is still up on GitHub and Helm was built with the intent of more engines being used. Second, ksonnet is going thro…

Ksonnet might be under active development, but Jsonnet is stable. YAML + Jinja2 is a dirty workaround - you can't even guarantee valid YAML with it as to Jinja2, everything's just text unlike with Jsonnet.

Re: Operator Framework: Building Apps on Kubernetes

#45
post #20

Earlier quoted context omitted.

> 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. well consider you wanted to have a High Available solutions that supports Blue Green / Rolling Deploys without downtime. You either built it yourself or you rely on something like k8s. It's not that much over engineering. K8s is a lot of code, yes. But…

>I think deploying k8s is still way easier than most other solutions out there, like all these PaaS's and Cloud solutions Have you seen nomad + consul + traefik? Much easier to install and the end result is close to a K8s cluster.

Not the parent, but I really like Nomad + Consul + Fabio (or Traefik) too. I tried learning Kubernetes but there was so much to take in all at once; I tried learning the HashiStack and I could try it out one product at a time.
Post reply on HN