The etcd operator: Simplify etcd cluster configuration and management
1–10 of 36 posts
Re: The etcd operator: Simplify etcd cluster configuration and management
#2I've been thinking about implementing a custom controller that would use Third Party Resources as a way to install and manage an application on top of Kubernetes. The way that Kuberetes controllers work (watching a declarative configuration, and "making it so") seems like a great fit for the problem.
Its exciting to see CoreOS working in the same direction - this looks much more elegant than what I would have hacked up.
Re: The etcd operator: Simplify etcd cluster configuration and management
#3This sounds a lot like Joyent's Autopilot Pattern (http://autopilotpattern.io), but will be more integrated with Kubernetes, rather than being agnostic.
Re: The etcd operator: Simplify etcd cluster configuration and management
#4Being someone who's been getting more familiar lately with backend engineering and has been trying to make sense of various options, I've got a strong enough impression of CoreOS that I'm betting my time it'll be dominating the next few years.
I also can't wait to see an open version of AWS Lambda / Google Functions appear.
Re: The etcd operator: Simplify etcd cluster configuration and management
#5Being someone who's been getting more familiar lately with backend engineering and has been trying to make sense of various options, I've got a strong enough impression of CoreOS that I'm betting my time it'll be dominating the next few years. I also can't wait to see an open version of AWS Lambda / Google Functions appear.
IBM has already launched openwhisk, and there are some other open lambda implementations.
Re: The etcd operator: Simplify etcd cluster configuration and management
#6I would love to understand the design rational on why a custom controller is needed to run etcd as opposed to leveraging the existing k8s constructs such as replicasets or petsets. While this is a very useful piece of technology it gives me the wrong impression that if you want to run a persistent or "more complicated" work load then you must develop a significant amount of code for that to work on k8s. Which I don't believe is the case, which I why I'm asking why this route was chosen.
Re: The etcd operator: Simplify etcd cluster configuration and management
#7I would love to understand the design rational on why a custom controller is needed to run etcd as opposed to leveraging the existing k8s constructs such as replicasets or petsets. While this is a very useful piece of technology it gives me the wrong impression that if you want to run a persistent or "more complicated" work load then you must develop a significant amount of code for that to work on k8s. Which I don't…
The FAQ at the end of the OP addresses this:
"Q: How is this different than StatefulSets (previously PetSets)?
A: StatefulSets are designed to enable support in Kubernetes for applications that require the cluster to give them "stateful resources" like static IPs and storage. Applications that need this more stateful deployment model still need Operator automation to alert and act on failure, backup, or reconfigure. So, an Operator for applications needing these deployment properties and could use StatefulSets instead of leveraging ReplicaSets or Deployments."
There is inevitably some app-specific logic required to modify a complex stateful deployment; the Operator encapsulates this logic so that the external interface is a simple config file.
Re: The etcd operator: Simplify etcd cluster configuration and management
#8This sounds a lot like Joyent's Autopilot Pattern ( http://autopilotpattern.io ), but will be more integrated with Kubernetes, rather than being agnostic.
Thanks, I remember seeing the autopilot pattern mentioned on Joyent's blog, but haven't seen that website. The lifecycle [0] looks remarkably similar to the build and deployment steps outlined in Distelli's manifest [1]. I use Distelli+Consul on Joyent so I suppose I've been doing the autopilot pattern without realizing it!
I know that much of Distelli's workflow comes from the founders' experience at AWS, so I wonder where the root of this pattern lies. Perhaps that would help unify these similar methods.
[0]: http://autopilotpattern.io/#how-do-we-do-it
[1]: https://www.distelli.com/docs/manifest/deployment-types
Re: The etcd operator: Simplify etcd cluster configuration and management
#9This is great news. We developed an internal controller managing etcd cluster used by kubernetes apiserver using third party resource too. The control loop design pattern works really well.
Re: The etcd operator: Simplify etcd cluster configuration and management
#10I would love to understand the design rational on why a custom controller is needed to run etcd as opposed to leveraging the existing k8s constructs such as replicasets or petsets. While this is a very useful piece of technology it gives me the wrong impression that if you want to run a persistent or "more complicated" work load then you must develop a significant amount of code for that to work on k8s. Which I don't…
The FAQ at the end of the OP addresses this: "Q: How is this different than StatefulSets (previously PetSets)? A: StatefulSets are designed to enable support in Kubernetes for applications that require the cluster to give them "stateful resources" like static IPs and storage. Applications that need this more stateful deployment model still need Operator automation to alert and act on failure, backup, or reconfigure.…
Darren, the FAQ is at the overview post here: https://coreos.com/blog/introducing-operators.html