External-dns: Ability to exclude a namespace

Created on 1 Jun 2017  路  27Comments  路  Source: kubernetes-sigs/external-dns

Right now it is possible to either use all namespaces or just a single namespace - In certain scenarios, it would be nice to be able to exclude kube-system or my-ops-area or whichever name I use.

Being able to blacklist more than one, comma separated perhaps, would be ideal.

kinfeature sizM

Most helpful comment

Just my two cents: this use case (include/exclude a list of items) often appears in software and I generally prefer something with regular expressions as this allows use cases such as "only work on all namespaces ending with '-test'" (namespaces might be dynamically created and not known at deployment time of external-dns).

All 27 comments

Makes sense. How do you want to specify this?

I see two three options:

  • have two flags for --include-namespace=foo,bar and --exclude-namespace=kube-system
  • have only one flag --namespace=foo,bar,!kube-system similar to https://github.com/linki/chaoskube#filtering-targets
  • define a regexp that describes all valid namespaces

[edited]

  • added the third possibility via regexps

I prefer option 2, using ! as it flows more naturally and is more concise.

In case people are confused by that (not sure why) and you went with option one then I would use --namespace like now for inclusion

Just my two cents: this use case (include/exclude a list of items) often appears in software and I generally prefer something with regular expressions as this allows use cases such as "only work on all namespaces ending with '-test'" (namespaces might be dynamically created and not known at deployment time of external-dns).

@hjacobs while I agree with the flexibility then from experience I can say that supporting full regex can lead to weird errors and potential security issues (less here perhaps) :) For your scenario adding support for * would suffice? *-test, most languages have that and some smarts string replace + start/ends with like functions can be used.

I digress tho - Either way I would be happy but I would prefer the simple/easier to test solution ;-)

I would also just go with a regexp. However, at least in Go, excluding things turns out to be more involved. AFAIK "include all namespaces that don't have production in their name" in a single flag is tricky. If you know how to do it, let me know.

@linki @helgi @hjacobs Thank you for your inputs that's what i was looking for to "exclude the specific namespace (kube-system)" to send logs to Elastisearch so that i don't see logs from "kube-system" in Kibana. I have researched a lot and spent lot of my time but didn't get a proper answer on how to iterate the configuration in td-agent.conf to make it work. I used the below but it didn't work... appreciate any suggestions:

<match kubernetes.var.log.containers.**_kube-system_**>
  @type null
</match>

Can anyone please give me an example within using regexp.
Thanks in advance!

Any news on this? I use a FQDN template, and would like to exclude services from the kube-system namespace, as well as a few others from being sync'd.

I think this wasn't picked up, PRs are welcome.

On macOS I've been using this alias as a workaround, expanded from a stack overflow answer:

alias ka='f(){ kubectl "$@" --all-namespaces | grep -v kube-system; unset -f f; }; f'

-v inverts the grep matching, when I ka get po I generally want to see all my namespaces and exclude the system one

I looked into this issue but fixing it in code is a bit more involved than I thought.

How are others working around this? Would running multiple external-dns instances in the allowed namespaces with the --namespace flag work? Are there any anticipated side effects with this approach?

Hi @ameir
I run separate instance for every namespaces I need. It is important to use different EXTERNAL_DNS_TXT_OWNER_ID and EXTERNAL_DNS_TXT_PREFIX as I may understand. Also I use different EXTERNAL_DNS_DOMAIN_FILTER by namespaces.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Sorry to revive this stale issue - but I can not find any documentation around limiting external-dns to a particular namespace - only by source type (ingress or service). I would like to isolate the namespaces it scans to only use those in a particular namespace.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

/remove-lifecycle rotten

For multi-tenant clusters, this feature would be extremely useful.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

Was this page helpful?
0 / 5 - 0 ratings