Hi, great work and thank you for sharing!
A quick question if I may. It says that:
"Internet facing workloads will reside on a public node group deployed on public subnets."
But right now pods with the "public" nodeSelector cannot communicate with the internet, but pods with the "private" nodeSelector can 🤔Or am I mistaken?
I hold a passion for DevOps, Security and Networking and I love bringing these principles to my customers by empowering them with the power of the public cloud.
In this article we didn't deploy a workloads in the public nodegroup. A workload deployed in the public nodegroup could have access to the internet thanks to the internet gateway. The workloads deployed in the private nodegroup have access to the internet thatnks to the NAT GW.
Did you deploy a workload in the public nodegroup? We should deploy only ELB in the public nodegroup.
Thank you so much for your response!
I see, so with this architecture, pods and applications should be kept on the private node group and access the internet through the NAT GW. In that case, if I wanted to deploy an Nginx ingress controller, should I deploy that to the private or public nodegroups?
Thank you again for your time and your hard work 🙏
I hold a passion for DevOps, Security and Networking and I love bringing these principles to my customers by empowering them with the power of the public cloud.
Thank you again for your feedback, and for the link to that article.
I tried running a simple curl from a busybox pod deployed on a node in the public subnet earlier but it didn't seem to work, I'll try changing the ports you mentioned and test again.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, great work and thank you for sharing!
A quick question if I may. It says that:
"Internet facing workloads will reside on a public node group deployed on public subnets."
But right now pods with the "public" nodeSelector cannot communicate with the internet, but pods with the "private" nodeSelector can 🤔Or am I mistaken?
hello
thanks for your contribution :-)
In this article we didn't deploy a workloads in the public nodegroup. A workload deployed in the public nodegroup could have access to the internet thanks to the internet gateway. The workloads deployed in the private nodegroup have access to the internet thatnks to the NAT GW.
Did you deploy a workload in the public nodegroup? We should deploy only ELB in the public nodegroup.
Thank you so much for your response!
I see, so with this architecture, pods and applications should be kept on the private node group and access the internet through the NAT GW. In that case, if I wanted to deploy an Nginx ingress controller, should I deploy that to the private or public nodegroups?
Thank you again for your time and your hard work 🙏
That's a good question. Your nginx ingress controller could create a network load balancer and it will be deployed in the public subnet.
aws.amazon.com/blogs/opensource/ne...
Even if your nginx ingress controler is deployed in the public nodegroup, it's supposed to have access to the public internet
The NACL "eks-ingress-external-zone-rules" allows access to all inbound and outbound traffic.
(You can try to replace to replace
by
A route table associates the IGW with the public subnets (eks+RDS)
So the issue could be elsewhere.
Before writing this post, I tested the solution proposed on this medium post: blog.devgenius.io/create-an-amazon...
Maybe it works with his terraform?
Thank you again for your feedback, and for the link to that article.
I tried running a simple curl from a busybox pod deployed on a node in the public subnet earlier but it didn't seem to work, I'll try changing the ports you mentioned and test again.