Proposal: Refactor to use ContainerPilot 3 and bootstrap from Consul

[misterbisson]

This implementation was originally built to demonstrate how Etcd can replace Consul for use with ContainerPilot. ContainerPilot 3 removes support for Etcd, and #3 was opened to mark this repo as deprecated. Certainly the original intent and assumptions of this repo are deprecated, but this ticket is intended to ask the following question:

Is there reason to have an Autopilot Pattern implementation of Etcd that bootstraps itself from Consul?

One potential use is in the development of an Autopilot Pattern implementation of Kubernetes, though there may be other approaches to bootstrap Kubernetes and Etcd to build self-assembling Kubernetes clusters.

[tgross]

Is there reason to have an Autopilot Pattern implementation of Etcd that bootstraps itself from Consul?

I can't think of any. ContainerPilot doesn't really even add that much to the Consul blueprint, to be honest. However, the Autopilot Pattern only uses ContainerPilot by implementation detail, not by principle. We could use this blueprint to demonstrate the principles of the Autopilot Pattern (self-assembly and self-management of the orchestration) without ContainerPilot.

One potential use is in the development of an Autopilot Pattern implementation of Kubernetes, though there may be other approaches to bootstrap Kubernetes and Etcd to build self-assembling Kubernetes clusters.

Any Consul available as part of the Kubernetes cluster would have to presuppose the existence of Kubernetes, which would make it sort of backwards for bootstrapping the etcd that Kubernetes needs.

[jwreagor]

Any Consul available as part of the Kubernetes cluster would have to presuppose the existence of Kubernetes, which would make it sort of backwards for bootstrapping the etcd that Kubernetes needs.

@tgross Are you talking about Etcd running inside a Kubernetes cluster or externally as a supporting service?

For HA setups, the latter is true. Etcd runs outside the Kubernetes control plane. Older setups that aren't utilizing a self hosted Kubernetes setup (control services running within self booted containers) also run Kubernetes outside the "guest" Docker containers/pods.

There could be a win if there's value having ContainerPilot supervise Etcd. I don't know Etcd well enough yet to know if there's a better story for Etcd cluster management, deployment, and upgrading.

We could use this blueprint to demonstrate the principles of the Autopilot Pattern (self-assembly and self-management of the orchestration) without ContainerPilot.

I second this, it's possible there are ways to handle lifecycle of Etcd that assist its management without using Consul or ContainerPilot.

[tgross]

Are you talking about Etcd running inside a Kubernetes cluster or externally as a supporting service? For HA setups, the latter is true. Etcd runs outside the Kubernetes control plane.

Right, I'm talking about the etcd that runs Kubernetes. Otherwise there's basically zero reason to have both ContainerPilot (which requires Consul) and etcd in the same installation. If you're having Kubernetes host itself then you've already got the orchestration the bootstrap it (using whatever the Kubernetes folks are shipping to do this).

[jwreagor]

In terms of HA options for operators running Etcd outside the Kubernetes eco-system, it would be beneficial for me to take up the cause with this Autopilot app. We'll see where the chips fall where for anything else.

[jwreagor]

Ran across a quote that helps support the revival of this pattern for the Kubernetes community. Thought it was worth leaving here for no particular reason.

All Kubernetes components are stateless which greatly simplifies managing a Kubernetes cluster. All state is stored in etcd, which is a database and must be treated specially. To limit the number of compute resource to complete this lab etcd is being installed on the Kubernetes controller nodes. In production environments etcd should be run on a dedicated set of machines for the following reasons:

• The etcd lifecycle is not tied to Kubernetes. We should be able to upgrade etcd independently of Kubernetes.
• Scaling out etcd is different than scaling out the Kubernetes Control Plane.
• Prevent other applications from taking up resources (CPU, Memory, I/O) required by etcd.

EDIT: I realize this has nothing to do with ContainerPilot and Consul specifically (for the moment).