Skip to content

Commit

Permalink
Address PR comments
Browse files Browse the repository at this point in the history
  • Loading branch information
Zijun Wang committed Nov 22, 2023
1 parent cf12458 commit 2ba72eb
Showing 1 changed file with 7 additions and 3 deletions.
10 changes: 7 additions & 3 deletions docs/guides/multi-cluster.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,24 +2,28 @@

Here is a recommended multi-cluster architecture if you'd like to setup kubernetes service-to-service communications across multiple clusters.

Suppose your organization would like to have one large infrastructure that have many clusters in one AWS account, this service mesh should include the following components:
Suppose your organization would like to have one large infrastructure that have many clusters in one AWS account. It's recommended your infrastructure includes the following components:
- One manually created VPC Lattice service network, (it could create by either AWS Console, CLI, CloudFormation, Terraform or any other tools)
- Create `VpcServiceNetworkAssociations` between VPC Lattice service network and each config cluster's VPC and workload clusters' VPCs
- Multiple workload cluster(s), that are used to run application workload(s). Workload cluster(s) should only have following workloads related kubernetes objects:
- Application workload(s) (Pods, Deployments etc.)
- `Service(s)` for application workload(s)
- `ServiceExport(s)`, that export kubernetes application Service(s) to the "config cluster"
- One extra dedicated "config cluster", which is act as a "service mesh control plane" and it should include following kubernetes objects:
- One extra dedicated "config cluster", which is act as a "service network control plane" and it should include following kubernetes objects:
- One `Gateway` that has __same name__ as the manually created VPC Lattice service network name
- `ServiceImport(s)`, that reference to kubernetes application services that export from workload cluster(s)
- `HTTPRoute(s)`,`GRPCRoute(s)`, that have rules backendRefs to `ServiceImport(s)` that referring kubernetes application service(s) in workload cluster(s)


Above architecture is recommended for following reasons:
- Put all Route(s) and one Gateway only in the config cluster is easier to manage and have less chance to have conflict.
- You could have seperated roles in your organization. The infra operator team only manage the resource in the config cluster, and the app developer team only manage the resource in the workload cluster(s).

You can see this similar production use case at Airbnb: [airbnb mullti-cluster setup](https://www.youtube.com/watch?v=1D8lg36ZNHs)

![config cluster and multiple workload clusters](../images/multi-cluster.png)

Following steps will show you how to set up this recommended multi-cluster architecture with 1 config cluster and 2 workload clusters.
Following steps show you how to set up this recommended multi-cluster architecture with 1 config cluster and 2 workload clusters.
1. Create 3 k8s clusters: `config cluster`, `workload cluster-1`, `workload cluster-2`. Install AWS gateway api controller in each cluster, you could follow this instruction [deploy.md](deploy.md)
1. Create a VPC Lattice `ServiceNetwork` with name `my-gateway`
1. Create `VPCServiceNetworkAssociation(s)` between previous step created service network and each config cluster's VPC and workload clusters' VPCs
Expand Down

0 comments on commit 2ba72eb

Please sign in to comment.