Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for pointing out the Operator framework. Please correct me if I am wrong, but Operator is not a Kubernetes thing - its a custom functionality built by coreos. It is undoubtedly awesome, but it is very hard to get it working on non coreos distro.

I personally believe that orchestration primitives like operators, linkerd, ingress, etc are what the k8s project should focus on. Im actually unsure if StatefulSets are solving production problems for anybody.

IMHO they are a fairly Googley concept and hard to apply outside of Google for anybody (without solving the networked filesystem problem first).



Small correction: Operators aren't a CoreOS-specific thing, and they're easy to install on any cluster.

Ultimately, the "Operator framework" is just a pattern: you represent some class of software (e.g. etcd, Elasticsearch, PostgreSQL) as a ThirdPartyResource, and you have some controller that monitors those TPRs, driving other resources toward the desired state.


sounds good - my bad then. I think they are awesome and not very well utilized.

It might be positioning - Operators vs Helm for example (even though the blog post tries to differentiate)


Think of Helm like a Linux package manager. You tell it you want etcd, and it makes it happen for you.

The way it makes it happen might be by using an operator, a Deployment/ReplicaSet, or a StatefulSet.

Think of operators as a "replica set that is aware of what it is replicating", and can do work to get things in the correct state.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: