The on-premise Kubernetes clusters are split across two zones and two environments:
Accessing the application¶
Access is controlled in part by ingresses, which define where your application will be exposed as a HTTP endpoint. You can control where your application is reachable from by selecting the appropriate ingress domain.
Make sure you understand where you expose your application, taking into account the state of your application, what kind of data it exposes and how it is secured. If in doubt, ask in #nais or someone on the NAIS team.
You can control from where you application is reachable by selecting the appropriate ingress domain.
|dev.intern.nav.no||naisdevice||development ingress for dev internal applications (supersedes dev.adeo.no). Also available in dev-gcp, use this to ease migration|
|dev.adeo.no||naisdevice||deprecated development ingress for adeo.no applications (superceded by dev.intern.nav.no)|
|intern.dev.adeo.no||internal network only||development ingress for adeo.no applications that should not be reached from naisdevice|
|dev-fss-pub.nais.io||GCP||See How do I reach an application found on-premises from my application in GCP?|
|nais.preprod.local||vdi||deprecated, use .dev.intern.nav.no instead|
|intern.nav.no||naisdevice||ingress for internal applications (supersedes nais.adeo.no). Also available in prod-gcp, use this to ease migration. Requires JITA to
|prod-fss-pub.nais.io||GCP||See How do I reach an application found on-premises from my application in GCP?|
You can also learn about how DNS is configured for these domains.
Last update: 2023-01-02