0

I'm implementing a kubernetes cluster for a django-based app and I didn't found what's the best practice for namespaces.

My app will need various services like a postgresql cluster, a reverse proxy (traefik), an Elastic Search / Kibana cluster and argoCD & argo workflow for CD.

Is it better to pull all those services into an unique namespace called production? Or do I need to separate them by services?

I began to separate them by services but I face some problem. For example an argo workflow launched on argo namespace can't use a secret stored from postgresql namespace.

Thank you for your help, Tux Craft

TuxCraft
  • 11
  • 1
  • 1
  • one of the project I am aware used `dev` , `prod` like namespacing. Although I am not sure if this fits for everyone. Also, note that when you try to access service from different namespace, you need to use `FQDN`. meaning, `..svc.cluster.local` to access a service in different namespace from other namsepace. – P.... Jun 17 '21 at 14:14

3 Answers3

1

Your question is slightly opinion-based. However, I will try to figure out the topic somehow by presenting both solutions. First, an excerpt from the documentation. There you can find a paragraph when to use multiple namespaces:

Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide. Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes resource can only be in one namespace. Namespaces are a way to divide cluster resources between multiple users (via resource quota). It is not necessary to use multiple namespaces to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.

Based on this documentation, in your case, the best solution will be to create one namespace and many deployments. This will allow you to avoid problems like this:

For example an argo workflow launched on argo namespace can't use a secret stored from postgresql namespace.

Technically, you can create the same thing using multiple namespaces. However, the point of namespaces is to isolate, so it doesn't seem like a good idea in your situation. You can read very good topic about Service located in another namespace.

Mikołaj Głodziak
  • 4,775
  • 7
  • 28
  • 1
    Hello, thank you for your answer. I will use an unique production namespace for postgresql cluster, argo workflow, django app. And use an isolated namespace for argocd. – TuxCraft Jun 22 '21 at 07:54
0

I think it's better to have one namespace and few deployments like below:

> kubens airflow-test
>  airflow-test
 
> kubectl get pods
>  airflow-test-postgres 
>  airflow-test-redis
>  airflow-test-worker
>  airflow-test-webserver
>  airflow-test-scheduler

In this setup, you can easily share configmaps and secrets between pods

> kubectl get configmap
>  airflow-test-configmap 
>
> kubectl get secrets
>  airflow-test-redis-secret
>  airflow-test-postgres-secret

Worth to add that each pod should has independent deployment .yaml file to easily manage them in future

shock_in_sneakers
  • 301
  • 2
  • 6
  • Thank you for your answer. it makes sense to use an unique namespace for deployments you quotes. But for all third parties tools like CD and elasticsearch, is it good to put them in smae namespace as app ? – TuxCraft Jun 17 '21 at 14:59
  • yep, I got the point, after reading this one https://kubernetes.io/docs/concepts/configuration/secret/#details it looks like you need to create secret per namespace if I understand correctly. Also found you can easily copy secrets between namespaces `kubectl get secret airflow-secret --namespace=sandbox -oyaml | kubectl apply --namespace=test -f -` – shock_in_sneakers Jun 18 '21 at 08:43
0

For each service e.g. Argo should complete set of service within their namespace.

So, it's practical to have multiple Postgres running in each namespace.

Hlex
  • 833
  • 8
  • 16