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/
Related
I am trying to access the kubectl of the master node that is running on an ec2 instance. I want to do this from another ec2 instance running on a different vpc. What steps should I take to make this possible?
I have the kubeconfig file on my second machine already but on running kubectl, it gives me a connection error,
Edit: Both the vpcs are private and have the similar CIDR.
If both of your EC2 are in diff VPCs you can do the VPC peering.
If you want to expose your master and K8s setup you can directly use the public IP(if exist) of EC2 and kubectl will connect to k8s cluster over the internet.
You can also checkout peering multiple VPC with same cidr range if you are looking for that way : Multiple VPC and Subnet with same CIDR blocks
Or : https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations-partial-access.html#two-vpcs-peered-specific-cidr
If your eks api server is private, create peering between the
VPCs and allow your Second EC2 server's private IP
If your eks api server is public, you can allow your Second EC2 instance's public IP from the aws console, in the eks security or network section
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.
I want to set up a VPC for my Elastic Beanstalk web app and RDS postgres db. I tried creating a VPC but ran into problems:
I went to VPC on AWS -> Launch VPC Wizard -> VPC with Public and Private Subnets. I am not sure what configurations to use. For example, what should I set Elastic IP Allocation ID? Do I need to set the VPC name?
After I create this, am I ready to just add it in EBS and RDS, or is there something else I need to do? Thanks!
Do I need to set the VPC name?
Its optional, but you can use, e.g. MyVPCforEB or what you want. It easier to find your vpc by name, than by cryptic vpc-id.
what should I set Elastic IP Allocation ID
You have to create EIP first. Its done in VPC -> Elastic IP addresses menu. This is required for NAT gateway, so that instances in private subnet can access the internet.
After I create this, am I ready to just add it in EBS and RDS, or is there something else I need to do?
Not really. To do it properly, you would need to add one more private subnet. The VPC wizard will create only one private subnet. For RDS, to create a subnet group, you need to have at least two private subnets in different Availability Zones.
Thus, once you have two private subnets in two different AZs, then you can create new Subnet Group in RDS with the subnets. Having this, you can create the RDS in these two subnets.
I want to have different VPC for dev/test/prod and one separate VPC for share services like jenkins. I'll use VPC peering between the Shared Services VPC and each of the environments VPCs
Each environment will have its own RDS instance.
RDS setup has this option about instance public accesibily, and I'm confused about the "No EC2 instance or devices outside of the VPC will be able to connect" statement.
If I choose "no" will I still be able to connect to the dev RDS instance from the shared services VPC by using VPC peering?
Yes you will be able to access from your 'shared services' VPC if you've peered the two VPCs.
Be sure to follow the VPC peering guide. The biggest thing is to make sure the CIDR block ranges do not overlap and you'll have to set the security groups on each RDS instance to allow traffic from the Jenkins instance in the 'shared services' VPC
I was setting up an environment using Elastic Beanstalk and I wanted the hosts to be apart of the default VPC for my account. I didn't really understand what the options meant. See the below image for an example:
Associate Public IP Address - How does this differ from the ELB visibility?
Subnets for ELB and EC2 - What do these do? The set-up wizard requires at least one box is selected. During my setup I selected all of the boxes.
VPC Security Group - How does this differ from the security group of the EC2 hosts. I use the security groups to SSH onto the hosts. Why does the VPC need a security group?
If selected, the ELB will be created with a public IP address associated to it (or the EC2 instance will if you select single instance instead of load balanced during the setup). Visibility is just for ACLs, and won't actually give it a publically accessible IP.
In a common VPC setup, you'll have both public and private subnets with a NAT in between them. Things in the public subnet can usually access the Internet and private subnet. Private subnet can usually just access the local subnet. In a load balanced EB environment, you'd typically place the ELB in the public subnet and the EC2 instance(s) in the private subnet.
VPC security groups are for your resources (anything in your VPC). They're just prefixed with the term VPC so as to distinguish between VPC security groups and legacy EC2 security groups (for EC2 instances that are not part of any VPC). The option in the UI only affects the EC2 resources in your VPC though I believe...not the ELB.