Embedded Cluster single-node and mutli-node architecture diagrams #2967
Conversation
✅ Deploy Preview for replicated-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for replicated-docs-upgrade ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
replicated-ci
added
type::docs
| import EmbeddedClusterPortRequirements from "../partials/embedded-cluster/_port-reqs.mdx" | ||
|
|
||
| # Using Embedded Cluster | ||
| # Embedded Cluster Overview |
There was a problem hiding this comment.
Moved the intro material like overview, architecture, reqs, and to a new Overview topic. The "Using Embedded Cluster" was reaching a critical mass (still need to break that page up more, but this seemed like a good start rather than continuing to pile on)
|
|
||
| [View a larger version of this image](/images/embedded-cluster-install.png) | ||
| ### Single-Node Architecture |
There was a problem hiding this comment.
added single- and multi- node diagrams. My thought was that this would make it easier to see at a glance what aspects of EC installs are specific to single versus multi node installs. For example, if we just showed multi-node, then the question might be, "are these components deployed in this way specifically because it's multi-node, or would it look like this for single node too?"
| As shown in the diagram above, in multi-node installations, an instance of the Embedded Cluster manager systemd service runs on each node and communicates with the KOTS instance running on the primary node through a websocket. This allows Embedded Cluster and KOTS to manage installations where workloads are running on multiple nodes in a cluster. | ||
|
|
||
| Additionally, for installations that include disaster recovery with Velero, the Velero Node Agent also runs on each node in the cluster. The Node Agent is a Kubernetes DaemonSet that performs backup and restore tasks such as creating snapshots and transferring data during restores. | ||
|
|
There was a problem hiding this comment.
^ just called out multi-node specific points/the pieces that are distinct from single-node installs
| @@ -75,241 +105,4 @@ Embedded Cluster has the following limitations: | |||
|
|
|||
| * **Policy enforcement on Embedded Cluster workloads is not supported**: The Embedded Cluster runs workloads that require higher levels of privilege. If your application installs a policy enforcement engine such as Gatekeeper or Kyverno, ensure that its policies are not enforced in the namespaces used by Embedded Cluster. | |||
|
|
|||
| * **Installing on STIG- and CIS-hardened OS images is not supported**: Embedded Cluster isn't tested on these images, and issues have arisen when trying to install on them. | |||
|
|
|||
| ## Quick Start | |||
There was a problem hiding this comment.
^ As mentioned above, moved everything from here down over to a new embedded-using topic, which gets the same "Using Embedded Cluster" page title that exists today
NOTE: I still need to update xrefs before merging
docs/vendor/embedded-overview.mdx
Outdated
|
|
||
| [View a larger version of this image](/images/embedded-architecture-single-node.png) | ||
|
|
||
| As shown in the diagram above, the Embedded Cluster binary first installs the k0s cluster as a systemd service. This systemd service is named using the slug of the application (for example, `gitea`). |
There was a problem hiding this comment.
is it worth explaining what this .tgz is, like that you download all the assets for installing? maybe sefl-explanatory, I don't know
There was a problem hiding this comment.
Yeah couldn't hurt!
There was a problem hiding this comment.
I'm good with this. I could see an argument for just saying "node" instead of "controller worker node" since you can have controller workers and just workers, depending on the node roles you define. and that seems more in depth than we're trying to show right now in this diagram.
|
@ajp-io Yeah I went back and forth on that...I landed on controller worker for all of them since this particular diagram happens to show a 3-node cluster, and if you are theoretically doing HA (which I know isn't show in this diagram either), having 3 controller nodes is necessary. I thought maybe showing one controller with two workers (or something like that) would be misleading since idk if we want to imply that that's a good pattern to follow. Not sure if that's sound logic, but just to give context :) |
|
It makes sense. And I think that's fine, unless we want to say that this architecture diagram isn't touching node roles like that, so we just say node to keep it generic. |
|
@ajp-io true...you know what, I do think it might be better to just keep it generic since I don't explain what controller workers are in the description. Probably just invites confusion |
|
I'll edit that in the diagrams then merge |
New: https://deploy-preview-2967--replicated-docs.netlify.app/vendor/embedded-overview#architecture-and-add-ons