From 15461fa63da72d9d994b8a01e39e58612f6b88a3 Mon Sep 17 00:00:00 2001 From: Christopher Negus Date: Tue, 15 Nov 2022 16:45:34 +0000 Subject: [PATCH 1/7] Document cluster topologies --- .../en/docs/concepts/cluster-topologies.md | 82 ++ .../en/docs/concepts/clusterworkflow.md | 16 +- .../images/eks-a_cluster_management.png | Bin 0 -> 100547 bytes .../images/eks-a_cluster_management.svg | 669 ++++++++++++++++ .../images/eks-a_cluster_standalone.png | Bin 0 -> 82259 bytes .../images/eks-a_cluster_standalone.svg | 723 ++++++++++++++++++ 6 files changed, 1489 insertions(+), 1 deletion(-) create mode 100644 docs/content/en/docs/concepts/cluster-topologies.md create mode 100644 docs/static/images/eks-a_cluster_management.png create mode 100644 docs/static/images/eks-a_cluster_management.svg create mode 100644 docs/static/images/eks-a_cluster_standalone.png create mode 100644 docs/static/images/eks-a_cluster_standalone.svg diff --git a/docs/content/en/docs/concepts/cluster-topologies.md b/docs/content/en/docs/concepts/cluster-topologies.md new file mode 100644 index 000000000000..53a77f22e5ae --- /dev/null +++ b/docs/content/en/docs/concepts/cluster-topologies.md @@ -0,0 +1,82 @@ +--- +title: "Cluster topologies" +linkTitle: "Cluster topologies" +weight: 20 +description: > + Explanation of standalone vs. management/workload cluster topologies +--- + +For trying out EKS Anywhere or for times when a single cluster is needed, it is fine to create a _standalone cluster_ and run your workloads on it. +However, if you plan to create multiple clusters for running Kubernetes workloads, we recommend you create a _management cluster_. +Then use that management cluster to manage a set of workload clusters. + +This document describes those two different EKS Anywhere cluster topologies. + +## What is an EKS Anywhere management cluster? +An EKS Anywhere management cluster is a long-lived, on-premises Kubernetes cluster that can create and manage a fleet of EKS Anywhere workload clusters. +The workload clusters are where customers run their applications. +The management cluster can only be created and managed by the Amazon CLI `eksctl`. + +The management cluster runs on customer hardware on-premises and it does not require any connectivity back to AWS to function. +Customers are responsible for operating the management cluster including (but not limited to) patching, upgrading, scaling, and monitoring the cluster control plane and data plane. + +## What’s the difference between a management cluster and a standalone cluster? +From a technical point of view, they are the same. +Regardless of which deployment topology a customer chooses, you always start by creating a singleton, standalone cluster that’s capable of managing itself. +This shows examples of separate, standalone clusters: + +![Standalone clusters self-manage and can run applications](/images/eks-a_cluster_standalone.png) + +Once a standalone cluster is created, you have an option to use it to use it as a management cluster to create separate workload cluster(s) under it, hence making this cluster a long-lived management cluster. +You can only use `eksctl` to create or delete the management cluster and the singleton standalone cluster. +This shows examples of a mamagement cluster that deploys and manages multiple workload clusters: + +![Management clusters can create and manage multiple workload clusters](/images/eks-a_cluster_management.png) + +## What’s the difference between a management cluster and a bootstrap cluster for EKS Anywhere? + +A management cluster is a long-lived entity you have to actively operate. +The _bootstrap_ cluster is a temporary, short-lived kind cluster that is created on a separate [Administrative machine]({{< relref "clusterworkflow/#administrative-machine" >}}) to facilitate the creation of an initial standalone or management cluster. +You do not need to interact or operate the `kind` cluster. +The `kind` cluster will be automatically deleted by the end of the initial cluster creation. + +## When should I deploy a management cluster? +If you want to run three or more EKS Anywhere clusters, we recommend them to choose a management/workload cluster deployment topology because of the advantages listed in the table below. +The EKS Anywhere Curated Packages feature recommends deploying certain packages such as the container registry package or monitoring packages on the management cluster to avoid circular dependency. + + +| | Standalone cluster topology | Management/workload cluster topology | +|--------|-----------------------------|---------------------------------------| +| **Pros** | Save hardware resources | Isolation of secrets | +| | Reduced operational overhead of maintaining a separate management cluster | Resource isolation between different teams. Reduced noisy-neighbor effect. | +| | | Isolation between development and production workloads. | +| | | Isolation between applications and fleet management services, such as monitoring server or container registry. | +| | | Provides a central control plane and API to automate cluster lifecycles | +| **Cons** | Shared secrets such, as SSH credentials or VMware credentials, across all teams who share the cluster. | Consumes extra resources. | +| | Without a central control plane (such as a parent management cluster), it is not possible to automate cluster creation/deletion with advanced methods like GitOps or IaC. |The creation/deletion of the management cluster itself can’t be automated through GitOps or IaC. | +| | Circular dependencies arise if the cluster has to host a monitoring server or a local container registry. | +|||| + + +## Which EKS Anywhere features support the management/workload cluster deployment topology today? + +| | Supported | Notes | +|--------|-----------|--------| +| Create/update/delete a workload cluster on... ||| +|