containers-roadmap icon indicating copy to clipboard operation
containers-roadmap copied to clipboard

[EKS/Fargate] Support for Wildcard * Namespaces

Open tabern opened this issue 5 years ago • 27 comments

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

tabern avatar Dec 03 '19 17:12 tabern

Will it support a * for any workspace, so we can have selective controls through labels only?

apogrebnyak avatar Feb 18 '20 20:02 apogrebnyak

Will this allow us to have environment specific Fargate profiles? For example:

  • prod profile runs all pods in prod-* namespaces
  • staging profile runs all pods in staging-* namespaces
  • dev profile runs all pods in dev-* namespaces

rblaine95 avatar Mar 12 '20 10:03 rblaine95

I would also suggest a list syntax dev,staging,prod . just as an example

goraxe avatar Mar 13 '20 22:03 goraxe

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

kirnberger1980 avatar Aug 26 '20 12:08 kirnberger1980

We have the same setup as @kirnberger1980. So we would prefer @rblaine95's proposal too.

walkermundo avatar Aug 26 '20 15:08 walkermundo

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.

Guillermogsjc avatar Dec 28 '20 11:12 Guillermogsjc

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.

booleanbetrayal avatar Feb 16 '21 16:02 booleanbetrayal

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.

martinspaeth avatar Mar 21 '21 06:03 martinspaeth

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).

matthewhembree avatar May 21 '21 17:05 matthewhembree

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?

rakeshgohel01 avatar Sep 22 '21 15:09 rakeshgohel01

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.

jtprom avatar Oct 04 '21 21:10 jtprom

+1 for this feature

savil avatar Oct 11 '21 17:10 savil

We have a very strong usecase for this, as we allow developers to spin up their own namespaces across our corp.

gbvanrenswoude avatar Nov 19 '21 07:11 gbvanrenswoude

As a part of our CI/CD process, the developers get a namespace for every pull request. We need this feature.

itaymelamed avatar Dec 22 '21 07:12 itaymelamed

+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.

kflavin avatar Jan 03 '22 19:01 kflavin

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.

isaiahh avatar Jan 09 '22 02:01 isaiahh

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?

mariocarta64 avatar Feb 11 '22 19:02 mariocarta64

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

matthewhembree avatar Feb 11 '22 23:02 matthewhembree

+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.

coragi avatar Feb 15 '22 17:02 coragi

Would love to see this feature implemented soon.

DaliborLabudovicGP avatar Mar 15 '22 14:03 DaliborLabudovicGP

+1 for this feature. We are hopeful for this feature to use fargate on a large scale.

augustoamormino avatar Mar 25 '22 13:03 augustoamormino

Suplicamos por essa funcionalidade

Elcioo avatar Apr 07 '22 14:04 Elcioo

As it currently stands, without wildcard namespaces, Fargate-backed clusters are basically unusable:

  1. Fargate Profiles take considerable time to create and delete.
  2. Fargate Profiles cannot be modified, so new namespaces cannot be added to an existing Fargate Profile.
  3. Limits on the number of Fargate Profiles per cluster/region make it impossible to maintain a Profile per Namespace.
  4. 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.

pdf avatar Apr 13 '22 00:04 pdf

Hope to see this get some attention soon. We also want to use this to make temporary test environments more managable.

kncesarini avatar Apr 27 '22 08:04 kncesarini

@mikestef9 Any idea when this feature is coming? A timeline would really help us.

nilroy avatar Jul 27 '22 21:07 nilroy

I can't give specific dates in this forum, but follow this issue for an update coming very soon.

mikestef9 avatar Jul 27 '22 21:07 mikestef9

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.

gilbahat avatar Jul 30 '22 18:07 gilbahat

https://aws.amazon.com/en/about-aws/whats-new/2022/08/wildcard-support-amazon-eks-fargate-profile-selectors/

rekcah78 avatar Aug 18 '22 03:08 rekcah78

(@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 both my-team-staging and other-team-staging, since * matches any number of characters, including none.

akestner avatar Aug 19 '22 19:08 akestner