I have two GKE clusters with the same CIDR subnet addresses (the clusters are in different gcloud project). I need to connect the VPC with VPC peering but I get an error because the CIDR subnet and I need to change one. I have a lot of pods, secrets, deployemts...etc. Are any way to change the subnet without creating a new cluster and migrating the pods?
Thanks!
I am afraid you cannot, A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes.
Related
We have an EKS cluster running in a VPC and we are thinking of extending this VPC or creating another VPC with a different subnet IP range. EKS nodes (EC2 instances) are running with multiple ENIs, that is, with multiple private IPs.
We wonder if it is possible to make these EC2 instances which serve as EKS nodes automatically get an IP from this new subnet within current VPC or on the other VPC when they are getting instantiated. If the subnet is on another VPC, should we have a VPC peering connection between two VPCs? Can it be doable by Cloud Formation templates on EKS? What is the best practice here? Thanks.
The option to extend VPC in EKS is via adding secondary CIDR block and configure CNI plugin to use the subnets created in the secondary CIDR block. CNI is ultimately responsible to assign the ip addresses available through the subnet cidr to the pods.
To use the correct CIDR range for VPC extension and to configure the CNI please use the below article :
https://aws.amazon.com/premiumsupport/knowledge-center/eks-multiple-cidr-ranges/
According to AWS documentation - https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html
it has a private IP address from the IP address range of the subnet.
So if for example, there are 2 subnets for example(private1, private2) and RDS is hosted in private 2. Does it mean a VPC end point need to be created for each subnet or it depends on where your for example Lamda is. For example, if Lamda's are hosted in a private1 subnet then you need only it on the private 1 subnet? However, for example if you access Query Editor for example from Console, as RDS is in private 2 subnet, do you need another VPC End Point in private 2.
Goal of this is to internalize traffic to AWS VPC.
Reading further VPC endpoints can span across multiple availability zones in the same VPC. Hence, reading this, it should not matter which subnets you deploy as long as it is in the same VPC.
Is there is any workaround if we have the same vpc cidr (different aws account )at both ends and we want VPC peering? Or any other mechanism which can help me to connect between two same VPC CIDR but in different aws account ??
The peering connection requires non-overlapping CIDRs.
Ensure that your VPCs do not have overlapping IPv4 CIDR blocks. If they do, the status of the VPC peering connection immediately goes to failed. This limitation applies even if the VPCs have unique IPv6 CIDR blocks.
A way to deal with such cases is to use secondary CIDR range. Such setup is exemplified in the AWS doc:
Two VPCs peered to a specific CIDR block in one VPC
In the example, VPC A has overlapping CIDR range with VPC B and C. To establish peering connection, extra CIDR ranges are used.
There is a good article in AWS blog which provides several solutions depending on your needs:
Renumber IP networks
Use AWS PrivateLink
Use multiple IP address ranges in VPCs
Hide subnets using Private NAT Gateway
I am having a routing issue between vpc's and subnets. I am wondering is there a simple way, or steps, to work out what is blocking access i.e nacl's, sg's, route tables...
I come across this quite often and the only way I know to test is to telnet with port, but this is not super helpful, when it could be any of the above.
In this case specifically, I am trying to route from one(shared services) peered vpc through to another, and then to an instance in a subnet.
Here are some quick pointers :
Identify the source of the issue, check the route tables of the subnets with the resources that are impacted:
Public subnets
Confirm that the route table destination has a default route (0.0.0.0/0 for IPv4 and ::/0 for IPv6) that points to an internet gateway.
Subnets using NAT instances or NAT gateways
Under Subnets, choose your private subnet.
Choose the Route Table view, and confirm that the route table has a default route that points to a NAT instance or gateway.
Confirm that the NAT device is launched in a public subnet and perform the checks required for public subnets listed in the previous section.
Note: If you're using a NAT instance, be sure you've disabled the source destination check.
Subnets using VPC peering connections
Choose Peering Connections, and choose your peering connection
Confirm its status is Active.
From the navigation pane, choose Subnets, and choose the subnets of the Amazon VPC that you want to connect using a peering connection.
Choose the Route Tables view, and confirm that they have routes to CIDR with specific subnets or to the entire CIDR of the peered Amazon VPC, including the peering connection noted in step 2
Confirm that the route tables include all the subnets for the peered Amazon VPC.
Note: Confirm there are no invalid VPC peering connection configurations
You can read more about it here
Hope this helps!
I have a QA instance in a VPC-appsubnet. My VPC has a NACL different from subnets NACL. Does this cause any issue accessing my QA Instance?
A Network ACL in AWS is an object that can created inside a VPC, and can be attached to Subnet objects.
So in a nutshell, a NACL belongs to a VPC but is associated with subnet/s.
See this.
Network ACL for your VPC is at Subnet level. VPC can have multiple subnets, so there can be multiple NACL associated with the VPC.
If there are issues accessing an instance and you're concerned about the Network ACL rules, you can check the Network ACL associated with the subnet in which the instance is. Also, you could check the VPC configuration.