The namespace has the same name as the
name field i
Using team namespaces instead of shared namespaces has several advantages:
- Team members have full admin access in that namespace. This includes
- Support for Kubernetes native secrets as an alternative to Vault.
- People from other teams cannot read native secrets in your team's namespace
- People from other teams does not have access to your team's namespace. This prevents accidental changes or removal of Kubernetes resources used by your team.
- Google Cloud Platform (GCP) only supports team namespaces. Migrating your application to a team namespace now makes it easier to move from on-prem to GCP later.
- No longer forces use of the
nais.io/Applicationdoesn't support your requirements, or you simply prefer handling these resources yourself, you are free to do so.
On-prem migration to team namespaces¶
Migrating an application to a team namespace is done by changing the namespace field in the naiserator yaml file and redeploying the app.
For example, if you're migrating
my-app from the
default namespace to a namespace called
my-team, your yaml previously looked like this:
apiVersion: "nais.io/v1alpha1" kind: "Application" metadata: name: my-app namespace: default
it should instead look like this:
apiVersion: "nais.io/v1alpha1" kind: "Application" metadata: name: my-app namespace: my-team
Remove the application from the old namespace when you have finished migrating.
kubectl delete app <app-name> -n <old-namespace>
If your application uses Vault, make sure the application is registered under the correct team in Vault IAC.
There are a few more steps to consider if you are integrating with other rest- or webservices.
Integration via ingress or BigIP¶
If you are calling other services through a Kubernetes ingress or BigIP such as:
no changes are required.
Service calls via api-gateway or service-gateway will also work without any changes.
Integration via Kubernetes service discovery¶
When migrating your application from either the
default namespace or from a environment namespace (e.g. t1, q1 etc.), the service URL will change and consequently break your consumer integrations.
This can be mitigated during a migration phase by creating an
ExternalName-service in the namespace you are migrating from, that points to the new service in the team namespace.
When migrating your application
my-app from the
default namespace to
my-teamnamespace, you can create the following
Service in the default namespace to keep the previous service URL, and allow for a seamless migration.
apiVersion: v1 kind: Service metadata: name: my-app namespace: default spec: type: ExternalName externalName: my-app.my-teamnamespace.svc.nais.local
This will create a CNAME DNS record that will resolve