containers-roadmap
containers-roadmap copied to clipboard
[EKS/Fargate] Support for Wildcard * Namespaces
the problem
Today you have to specify each namespace from which you want to run pods on Fargate in a Fargate profile.
the solution
EKS with Fargate will support adding wildcard *
namespaces to the fargate profile
Will it support a *
for any workspace, so we can have selective controls through labels only?
Will this allow us to have environment specific Fargate profiles? For example:
-
prod
profile runs all pods inprod-*
namespaces -
staging
profile runs all pods instaging-*
namespaces -
dev
profile runs all pods indev-*
namespaces
I would also suggest a list syntax dev,staging,prod
. just as an example
We are running our apps in multitenancy model, which means, we e.g. have a multiple dev environments, which are running in separate namespaces:
myapp-dev1
myapp-dev2
...
myapp-devX
So in this case, it would be nice, if it is possible to define a profile with a wildcard.
myapp-dev*
So I prefer the solution of @rblaine95
We have the same setup as @kirnberger1980. So we would prefer @rblaine95's proposal too.
Also, if you want for example to link a Gitlab CICD cluster using only fargate nodes, it has managed namespaces that match repository names ... so there is needed the wildcard to match any namespace orthogonally to the labels.
Would love to see this change. Having to request Fargate Profile limits just to support something that could be done with a single profile, is kinda obnoxious.
We need this to run ci/cd pipelines isolated via namespace:
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27278#note_534085561
A wildcard would make the described workaround obsolete here.
This would be useful for development. We use Tilt and each developer gets a namespace.
There is a similar use case for review apps (per PR/MR).
We also have a use case where developers are allowed to create namespaces independently to deploy their workload and Ops can configure a common fargate profile to deploy those apps.
Is there any update on wildcard support for namespace yet?
Another vote for this feature. We want to be able to spin up dynamic namespaces that will be destroyed at the end of the day.
+1 for this feature
We have a very strong usecase for this, as we allow developers to spin up their own namespaces across our corp.
As a part of our CI/CD process, the developers get a namespace for every pull request. We need this feature.
+1 for this feature. When we deploy our app into K8s, each stack always gets it own namespace; one example of this is we deploy every new release into a separate namespace for our QA team to perform regression.
I'm finding it can take several minutes to create a new fargate profiles. It would be really tedious to create a new profile for every new environment we create. We're not currently using Fargate, but would like to.
I also need this for my CI pipelines. Currently, each pipeline has its own dynamic namespace, and like many others here I need to create a dedicated Fargate profile before I can create the k8s stack. This takes several minutes and slows the pipeline down. Additionally, only one Fargate profile can be created or deleted at a time so other pipelines must wait for any ongoing profile creation to complete before they can begin their own setup process. Wildcard namespaces for profiles woudl solve this nicely.
We started looking at Fargate yesterday and one of the first questions in our heads were "how can I just have fargate be used across our entire cluster". Really mind boggling something like this wasn't considered before even releasing. We utilize vclusters for ephemeral environments so new namespaces are continually coming and going. Is there a way to live modify selectors?
I've looked at this, but never had the chance to implement this. It might be useful for others in the interim. https://github.com/jicowan/fargate-operator
Be mindful of limits: https://docs.aws.amazon.com/eks/latest/userguide/service-quotas.html#sq-text
+1 for this feature. There are a lot of customers that are coming from K8s and they are used to have one namespace for each application.
Would love to see this feature implemented soon.
+1 for this feature. We are hopeful for this feature to use fargate on a large scale.
Suplicamos por essa funcionalidade
As it currently stands, without wildcard namespaces, Fargate-backed clusters are basically unusable:
- Fargate Profiles take considerable time to create and delete.
- Fargate Profiles cannot be modified, so new namespaces cannot be added to an existing Fargate Profile.
- Limits on the number of Fargate Profiles per cluster/region make it impossible to maintain a Profile per Namespace.
- All pods are deleted when deleting the Profile that scheduled them, so a possible workaround strategy of rolling Profile creation/deletion with a full namespace list (to stay within the Profile limit) is not possible.
I'd been considering deploying an operator to implement strategy 4 (after discovering that 3 was unworkable), until I discovered that it would require recreating all workloads every time a namespace is added/removed.
I've exhausted all ideas for working around this design deficiency, and have had to give up on the idea of using Fargate-backed EKS entirely.
Hope to see this get some attention soon. We also want to use this to make temporary test environments more managable.
@mikestef9 Any idea when this feature is coming? A timeline would really help us.
I can't give specific dates in this forum, but follow this issue for an update coming very soon.
also highly interested in this scenario. we are considering using fargate for our CI system and we use namespaces to separate concurrent CI tasks. without a wildcard, there is no way to use fargate for this.
https://aws.amazon.com/en/about-aws/whats-new/2022/08/wildcard-support-amazon-eks-fargate-profile-selectors/
(@rekcah78 beat me to it 😉)
🚀 Launch Announcement!! 🚀 More details are available on the AWS What's New Post and the new Fargate Profile Wildcards section of the EKS Fargate Profile AWS documentation.
With Fargate Profile selector wildcards, you can use simple wildcard characters, like
*
and?
, to specify that Kubernetes workloads in any matching namespace or with any matching label should run on Fargate serverless compute. For example, you can specify that all Kubernetes pods in any namespace matching*-staging
run on Fargate. This namespace selector would match bothmy-team-staging
andother-team-staging
, since * matches any number of characters, including none.