-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix(modules,eks): eks-managed nodepool node labels and taints #80
Conversation
…_extra_args to k8s_labels and move taints from kubelet_extra_args to taints
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch 😄
2a52f84
8a13ad6
to
8fb1586
Compare
24fc658
to
d560159
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During testing, I observed that the AMI ID selection fluctuates between different values, even when no modifications were made to the example provided by the repository. Running terraform plan and terraform apply multiple times consistently led to variations in the assigned AMI ID. This inconsistency has critical implications for the stability and predictability of the deployment.
The selected AMI IDs vary between:
- AMI ID ami-07e1ee9a4c62970c8: "amazon-eks-gpu-node-1.29-v20241106" — a GPU-enabled EKS node image.
- AMI ID ami-0464f6a0d134ee64c: "amazon-eks-node-1.29-v20241106" — a standard EKS node image without GPU support.
Steps to Reproduce
To replicate this behavior:
- Use the unmodified example from the repository.
- Execute terraform plan and terraform apply multiple times.
- Observe the AMI ID assigned to the EKS node pool. It may alternate between the two AMIs noted above, despite there being no changes to the code or configuration.
This inconsistency can be verified with the following commands:
# To verify the GPU-enabled AMI
export AMI_ID=ami-07e1ee9a4c62970c8
aws ec2 describe-images --image-ids $AMI_ID --query 'Images[0].Name' --output json --region eu-west-1 | jq
# Expected output: "amazon-eks-gpu-node-1.29-v20241106"
# To verify the standard AMI
export AMI_ID=ami-0464f6a0d134ee64c
aws ec2 describe-images --image-ids $AMI_ID --query 'Images[0].Name' --output json --region eu-west-1 | jq
# Expected output: "amazon-eks-node-1.29-v20241106"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After pulling the latest changes on fix/eks-node-pool-k8s-labels-and-taints, I created a cluster using the repository’s base configuration. I then modified the AMI type for the m5-node-pool-self-managed node pool to ami_type = "alinux2023".
However, running terraform plan now results in an error:
Error: Your query returned no results. Please change your search criteria and try again.
with module.fury_public_example.data.aws_ami.eks_worker_default_ami["m5-node-pool-self-managed"],
on ../../modules/eks/data.tf line 30, in data "aws_ami" "eks_worker_default_ami":
Could you check the AMI search criteria or confirm alinux2023 compatibility with the m5-node-pool-self-managed configuration?
8345b7c
to
ed47911
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice Job 💪
LGTM
FIXES:
ami_type
parameter that is calculated based on the customami_type
introduced to choose the default EKS ami OS between "Amazon Linux 2" and "amazon Linux 2023"arm64
ones and excludegpu
ones