That’s correct. If you’re telling the cluster you only want to use pods running with the Fargate compatibility, there’s no need to provision nodes yourself. EKS and Fargate will work together to spin up the containers and act as nodes for as long as the container needs to run.
That's really interesting to me. Curious how it all appears... like: if I do kubectl get po -o wide
does appear to be running on "nodes" I would not recognize as mine?
Also, trying to get my head around how security-groups etc. would work. Trying to build the "big picture" diagram in my mind. Guess the only way is to try it out.
You’ll end up seeing node names like “ fargate-ip-.us-east-2.compute.internal”.
I haven’t tried it out with different security groups other than my cluster started with to be honest. If you end up trying it out, I’d love to hear your thoughts and feedback on it.
I'll definitely get back to you, but it could be a while before I try this :) . My experience has been on-prem OpenShift, but not doing much infrastructure. Currently, just got on to AWS-EKS, so learning the ropes there.
Coincidentally, just this morning, I was spec-ing out the EKS cluster, as a development cluster, and while estimating costs, it stuck me that we'd like to scale in and out quite a bit.
So, in that context Fargate seems like it would be cost-effective, while not requiring as much admin once we iron out the basics.
Do you notice any difference in deployment time, when spinning up a Pod using Fargate, compared to doing so on a node that's already in the cluster?
I haven’t seen too much of a difference. That’s taking into account that the image is already pulled and your cluster doesn’t have to download it from the internet.
Good luck!
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.
What's the big-picture, "stepping-back" picture here? Would I not need to provision nodes for k8s?
That’s correct. If you’re telling the cluster you only want to use pods running with the Fargate compatibility, there’s no need to provision nodes yourself. EKS and Fargate will work together to spin up the containers and act as nodes for as long as the container needs to run.
That's really interesting to me. Curious how it all appears... like: if I do
kubectl get po -o widedoes appear to be running on "nodes" I would not recognize as mine?
Also, trying to get my head around how security-groups etc. would work. Trying to build the "big picture" diagram in my mind. Guess the only way is to try it out.
Thanks for doing this post.
You’ll end up seeing node names like “ fargate-ip-.us-east-2.compute.internal”.
I haven’t tried it out with different security groups other than my cluster started with to be honest. If you end up trying it out, I’d love to hear your thoughts and feedback on it.
I'll definitely get back to you, but it could be a while before I try this :) . My experience has been on-prem OpenShift, but not doing much infrastructure. Currently, just got on to AWS-EKS, so learning the ropes there.
Coincidentally, just this morning, I was spec-ing out the EKS cluster, as a development cluster, and while estimating costs, it stuck me that we'd like to scale in and out quite a bit.
So, in that context Fargate seems like it would be cost-effective, while not requiring as much admin once we iron out the basics.
Do you notice any difference in deployment time, when spinning up a Pod using Fargate, compared to doing so on a node that's already in the cluster?
I haven’t seen too much of a difference. That’s taking into account that the image is already pulled and your cluster doesn’t have to download it from the internet.
Good luck!