如何在无NAT网关的私有子网中部署EKS节点组？（无需使用eksctl的实现方案）

First, let’s clear up a key misconception: EKS nodes in private subnets don’t strictly require a NAT gateway. NAT gateways are one way to give nodes internet access, but if we can meet the nodes’ core communication needs—interacting with the EKS control plane, accessing AWS managed services, and pulling container images—without public internet egress, we can skip the NAT gateway entirely.

Below are practical, eksctl-free methods to deploy EKS node groups in private subnets without relying on NAT gateways:

1. Use VPC Endpoints (The Official Recommended Approach) #

VPC endpoints let your private subnet resources communicate directly with AWS services over the AWS backbone network, no public internet required. You’ll need to set up these specific endpoints for your EKS nodes:

Required VPC Endpoints #

• EKS Control Plane Endpoint: Create an interface endpoint for com.amazonaws.<your-region>.eks. This lets nodes talk directly to the EKS control plane. Deploy it in your private subnets, and configure its security group to allow inbound 443 traffic from your node security group.
• ECR Endpoints: Two endpoints are needed here:
  • Interface endpoint for com.amazonaws.<your-region>.ecr.dkr (handles Docker API calls for image pulls)
  • Interface endpoint for com.amazonaws.<your-region>.ecr.api (handles ECR API operations like repository queries)
• S3 Gateway Endpoint: ECR stores actual image layers in S3, so this endpoint lets nodes pull those layers without internet access. Attach a bucket policy that allows your node IAM role to access ECR’s S3 buckets.
• CloudWatch Logs Endpoint: Interface endpoint for com.amazonaws.<your-region>.logs—this lets nodes push logs to CloudWatch without public egress.
• STS Endpoint: Interface endpoint for com.amazonaws.<your-region>.sts—nodes use this to retrieve IAM role credentials for accessing AWS services like ECR.

Step-by-Step Deployment (AWS CLI/Console) #

• Create each endpoint via the AWS Console or using the aws ec2 create-vpc-endpoint command. For interface endpoints, specify your private subnets and a security group that allows outbound 443 traffic from nodes.
• Update your node IAM role to include permissions for accessing these services (e.g., AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly, CloudWatchLogsFullAccess).
• When launching your node group (via EC2 Auto Scaling Groups or AWS Console), select your private subnets, and ensure the node user data configures kubelet to use the EKS control plane’s private endpoint (if your cluster uses a private control plane) or routes control plane traffic through the EKS VPC endpoint.

2. Use a Private EKS Cluster #

If you configure your EKS cluster to use a private control plane endpoint (no public access), nodes can communicate with the control plane entirely over the internal VPC network. Combine this with the VPC endpoints listed above, and your nodes will have zero need for public internet egress.

Key Configuration Steps #

• For new clusters, set the endpoint-public-access flag to false and endpoint-private-access to true (via AWS CLI or Console). For existing clusters, you can update this setting in the EKS Console’s cluster configuration tab.
• Ensure your private subnet nodes have network connectivity to the control plane’s private IP range (this works automatically if nodes are in the same VPC as the cluster).
• Pair this with the required VPC endpoints for ECR, S3, CloudWatch, and STS to cover all service access needs.

3. AWS Outposts (For On-Prem/Edge Deployments) #

If you’re running EKS on AWS Outposts, your nodes can communicate with the EKS control plane via the Outposts’ local network link, eliminating the need for NAT gateways. This is a niche solution but works seamlessly for on-premises or edge EKS deployments.

Final Notes #

• eksctl’s ability to deploy private nodes without NAT gateways just automates the creation of these VPC endpoints and cluster configurations. Doing it manually gives you full control over each component.
• VPC endpoints are significantly cheaper than NAT gateways (they charge per hour per endpoint and data processed, which is far lower than NAT gateway’s hourly rate plus data transfer costs).

内容的提问来源于stack exchange，提问作者Kaustubh