Kubernetes Multi-Namespace Application
This Kubernetes application diagram groups frontend and backend resources into namespaces. An ingress controller receives public HTTPS traffic and routes it to a web service in the frontend namespace. The service selects web pods, which call an API service in the backend namespace. That service selects API pods, and only the API pods connect to PostgreSQL. The view is useful for documenting ownership and traffic boundaries in a microservices deployment. Add network policies, secrets, queues, or separate databases when they are important to the application design. Keep the diagram current when equipment, cable paths, service ownership, or security boundaries change, so it remains useful for planning and operations.
Open it in the AI editor with a prompt pre-filled — keep what works, change what doesn't.
Scenario
Namespace organization
Key decisions
- Separation: Frontend and backend resources use separate namespaces.
- Routing: Ingress reaches the frontend service.
- Data access: API pods are the only application tier connected to PostgreSQL.
When to reuse this
Use this to show namespace boundaries and calls across a two-tier Kubernetes application.
Frequently asked questions
What is a Kubernetes namespace?
Can services communicate across namespaces?
Why separate frontend and backend?
Tweak it with chat, export PNG/SVG, or fork it for your own use case.