Projects and namespaces
Grouping applications, and why the namespace is created in the portal first.
Two terms with different jobs that are easy to confuse.
A project is a grouping for people. It sorts related work so your workspace stays legible. It is explicitly not a security boundary. Someone with access to your account does not lose it because something sits in a different project. Access is governed by members and roles.
A namespace is where your application actually runs. It is the boundary that resource quotas, network rules, monitoring and cost attribution attach to. Here the separation is real.
Why the namespace is created in the portal first
You create a namespace in the portal rather than in your repository. That is not a detour: it is the point where the platform sets up everything your application later depends on: access rights, quotas, protection rules, the connection to your Git repository, access to secrets, plus monitoring and cost attribution.
A namespace created around that step has none of it. It looks like a namespace in kubectl and behaves like one in nothing that matters.
Creating one
- Open Projekte & Namespaces in the portal.
- Select a project or create one.
- Create the namespace.
- Before saving, check whether the portal is showing a note, a quota that will not stretch, for instance.
- Wait until the namespace is reported ready.
- Use the name from the portal in your manifests, unchanged.
The last step sounds trivial and is the most common source of failure: a namespace name you chose yourself produces a deployment that quietly goes nowhere.
When the namespace does not become ready
Fix that first rather than editing manifests. A namespace still being set up will accept resources, but without the rights and connections your application needs, which produces errors that look like your application is at fault. The portal tells you the reason; usually it is a quota, or setup that has not finished.