diff --git a/docs/how-it-works.md b/docs/how-it-works.md index edb4917b..b1ba7d39 100644 --- a/docs/how-it-works.md +++ b/docs/how-it-works.md @@ -12,7 +12,7 @@ With the controller deployed and running, you will be able to manage services fo While separating the application developer from the details of the underling infrastructure, the controller also provides a Kubernetes-native experience, rather than creating a lot of new AWS ways of managing services. It does this by integrating with the Kubernetes Gateway API. -This lets you work with Kubernetes service-related resources using Kubernetes APIs and custom resource definitions (CRDs). +This lets you work with Kubernetes service-related resources using Kubernetes APIs and custom resource definitions (CRDs) defined by the Kubernetes [networking.k8s.io specification](https://gateway-api.sigs.k8s.io/references/spec/). For more information on this technology, see [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). @@ -20,7 +20,7 @@ A few things to keep in mind: * If you are new to the VPC Lattice service, keep in mind that names you use for objects must be unique across your entire account and not just across each cluster used by that account. * Your AWS CNI must be v1.8.0 or later to work with VPC Lattice. -## Deploying the Gateway API Controller +## Deploying the AWS Gateway API Controller Follow these instructions to create a cluster and deploy the AWS Gateway API Controller. Run through them again for a second cluster to use with the extended example shown later. @@ -43,12 +43,12 @@ Run through them again for a second cluster to use with the extended example sho { "Effect": "Allow", "Action": [ - "vpc-lattice:", + "vpc-lattice:*", "iam:CreateServiceLinkedRole", "ec2:DescribeVpcs", "ec2:DescribeSubnets" ], - "Resource": "" + "Resource": "*" } ] } @@ -82,10 +82,11 @@ Run through them again for a second cluster to use with the extended example sho kubectl apply -f examples/deploy-v0.0.1.yaml ``` -## Using the Gateway API Controller +## Using the AWS Gateway API Controller The first part of this section provides an example of setting up of service-to-service communications on a single cluster. The second section extends that example by creating another inventory service on a second cluster on a different VPC, and spreading traffic to that service across the two clusters and VPCs. +Both clusters are created using `eksctl`, with both clusters created from the same account by the same cluster admin. ### Set up single-cluster/VPC service-to-service communications @@ -239,7 +240,7 @@ The following figure illustrates this: 1. Switch you credentials to use the second cluster -1. Create a Kubernetes inventory in the second cluster: +1. Create a Kubernetes inventory-ver2 service in the second cluster: ```bash kubectl apply -f examples/inventory-ver2.yaml ``` @@ -336,9 +337,9 @@ With VPC Lattice you can also avoid some of these common problems: ### Relationship between VPC Lattice and Kubernetes As a Kubernetes user, you can have a very Kubernetes-native experience using the VPC Lattice APIs. -The following figure illustrates how VPC Lattice object connect to [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) objects: +The following figure illustrates how VPC Lattice objects connect to [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) objects: -[Image: VPCLatticeToKubernetesGatewayAPI.png] +![VPC Lattice objects relation to Kubernetes objects](images/personae.png) As shown in the figure, there are different personas associated with different levels of control in VPC Lattice. Notice that the Kubernetes Gateway API syntax is used to create the gateway, HTTPRoute and services, but Kubernetes gets the details of those items from VPC Lattice: diff --git a/docs/images/personae.png b/docs/images/personae.png new file mode 100644 index 00000000..6f3fbb37 Binary files /dev/null and b/docs/images/personae.png differ