generated from amazon-archives/__template_Apache-2.0
-
Notifications
You must be signed in to change notification settings - Fork 71
Support Standalone Service Creation & Surface Service ARN #818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 16 commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
e1069fa
Add annotation constants and helper functions
95cc9e4
Implement standalone mode detection in service model builder
0d26386
Modify service model building to support standalone mode
5b3bda3
Update service manager to handle standalone services
5af4784
Enhance route status updates with service ARN
2c2fd45
Update route controller to use enhanced status function
a2b4de0
Add validation and error handling for annotation transitions
388311d
Update setup.sh dependencies and address linting issues
fe008a4
Create integration tests for standalone service creation
a110e73
Create integration tests for annotation precedence and inheritance
b4f03ed
Create integration tests for transition scenarios
8bc255e
Update documentation for standalone VPC Lattice services
971ef60
Merge branch 'aws:main' into issue/691
22f78a4
Upgrade golangci-lint version to v2.4.0 in GitHub workflow
7a0f722
Merge branch 'main' into issue/691
34fa3d0
Merge branch 'main' into issue/691
bfab529
Address PR comments
f2ee002
Address PR comments related to documentation
e0e7a24
Simplify ParseBoolAnnotation()
3587de4
Remove switch statement
ddc53a0
Update action to setup-go@v4
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,6 +22,98 @@ AWS Gateway API Controller supports Gateway API CRD bundle versions `v1.1` or gr | |
|
|
||
| In multi-cluster deployments, when you apply a TargetGroupPolicy to a ServiceExport, the health check configuration is automatically propagated to all target groups across all clusters that participate in the service mesh. This ensures consistent health monitoring behavior regardless of which cluster contains the route resource. | ||
|
|
||
| ## Standalone VPC Lattice Services | ||
|
|
||
| **What are standalone VPC Lattice services?** | ||
|
|
||
| Standalone VPC Lattice services are services created without automatic service network association. They provide more flexibility for independent service management, selective service network membership, and integration with external systems. Use the `application-networking.k8s.aws/standalone: "true"` annotation on Gateway or Route resources to enable this mode. | ||
|
|
||
| **Why is my standalone service not accessible from other services?** | ||
|
|
||
| Standalone services are not automatically discoverable through service network DNS resolution. To enable communication: | ||
|
|
||
| 1. **Use the VPC Lattice assigned DNS name** from the route annotation: | ||
| ```bash | ||
| kubectl get httproute my-route -o jsonpath='{.metadata.annotations.application-networking\.k8s\.aws/lattice-assigned-domain-name}' | ||
| ``` | ||
|
|
||
| 2. **Manually associate the service with a service network** using AWS CLI: | ||
| ```bash | ||
| SERVICE_ARN=$(kubectl get httproute my-route -o jsonpath='{.metadata.annotations.application-networking\.k8s\.aws/lattice-service-arn}') | ||
| SERVICE_ID=$(echo "$SERVICE_ARN" | cut -d'/' -f2) | ||
| aws vpc-lattice create-service-network-service-association \ | ||
| --service-network-identifier "sn-12345678901234567" \ | ||
| --service-identifier "$SERVICE_ID" | ||
| ``` | ||
|
|
||
| **How do I transition between standalone and service network modes?** | ||
|
|
||
| To transition from service network to standalone mode: | ||
| ```bash | ||
| kubectl annotate httproute my-route application-networking.k8s.aws/standalone=true | ||
| ``` | ||
|
|
||
| To transition from standalone to service network mode: | ||
| ```bash | ||
| kubectl annotate httproute my-route application-networking.k8s.aws/standalone- | ||
| ``` | ||
|
|
||
| The controller handles transitions gracefully without service disruption. | ||
|
|
||
| **Why isn't my route-level annotation working?** | ||
|
|
||
| Check the annotation precedence: | ||
|
|
||
| 1. **Route-level annotations** override Gateway-level annotations | ||
| 2. **Gateway-level annotations** apply to all routes referencing that gateway | ||
| 3. **Invalid annotation values** (anything other than "true" or "false") are treated as "false" | ||
|
|
||
| Verify your annotation syntax: | ||
| ```bash | ||
| kubectl get httproute my-route -o yaml | grep -A5 -B5 standalone | ||
| ``` | ||
|
|
||
| **How do I access the VPC Lattice service ARN for AWS RAM sharing?** | ||
|
|
||
| The service ARN is automatically populated in the route annotations: | ||
|
|
||
| ```bash | ||
| # Get service ARN | ||
| SERVICE_ARN=$(kubectl get httproute my-route -o jsonpath='{.metadata.annotations.application-networking\.k8s\.aws/lattice-service-arn}') | ||
|
|
||
| # Use for RAM sharing | ||
| aws ram create-resource-share \ | ||
| --name "shared-lattice-service" \ | ||
| --resource-arns "$SERVICE_ARN" \ | ||
| --principals "123456789012" | ||
| ``` | ||
|
|
||
| **Can I use standalone services with existing policies?** | ||
|
|
||
| Yes, all existing policies (IAMAuthPolicy, TargetGroupPolicy, AccessLogPolicy, VpcAssociationPolicy) work normally with standalone services. The only difference is the lack of automatic service network association. | ||
|
|
||
| **What happens if I have conflicting annotations on Gateway and Route?** | ||
|
|
||
| Route-level annotations always take precedence over Gateway-level annotations. For example: | ||
|
|
||
| - Gateway has `standalone: "true"` | ||
| - Route has `standalone: "false"` | ||
| - Result: The route creates a service network associated service | ||
|
|
||
| **Why don't I see the service ARN annotation immediately?** | ||
|
|
||
| The service ARN annotation is populated after the VPC Lattice service is successfully created. This typically takes 30-60 seconds. Check the route status and controller logs if the annotation doesn't appear within a few minutes. | ||
|
|
||
| **Can standalone services communicate across VPCs?** | ||
|
|
||
| Standalone services require explicit configuration for cross-VPC communication: | ||
|
|
||
| 1. **AWS RAM sharing** to share the service with other accounts/VPCs | ||
| 2. **VPC peering or Transit Gateway** for network connectivity | ||
| 3. **Manual service network association** in target VPCs | ||
|
||
|
|
||
| Service network associated services automatically handle cross-VPC communication within the same service network. | ||
|
|
||
| **How do I prevent 503 errors during deployments?** | ||
|
|
||
| When using AWS Gateway API Controller with EKS, customers may experience 503 errors during deployments due to a timing gap between pod termination and VPC Lattice configuration propagation, which affects the time controller takes to deregister a terminating pod. We recommend setting `terminationGracePeriod` to at least 150 seconds and implementing a preStop hook that has a sleep of 60 seconds (but no more than the `terminationGracePeriod`). For optimal performance, also consider setting `ROUTE_MAX_CONCURRENT_RECONCILES` to 10 which further accelerates the pod deregistration process, regardless of the number of targets. | ||
| When using AWS Gateway API Controller with EKS, customers may experience 503 errors during deployments due to a timing gap between pod termination and VPC Lattice configuration propagation, which affects the time controller takes to deregister a terminating pod. We recommend setting `terminationGracePeriod` to at least 150 seconds and implementing a preStop hook that has a sleep of 60 seconds (but no more than the `terminationGracePeriod`). For optimal performance, also consider setting `ROUTE_MAX_CONCURRENT_RECONCILES` to 10 which further accelerates the pod deregistration process, regardless of the number of targets. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.