When using Kubernetes to deploy NuoDB, the following types of deployment are supported:
NuoDB recommends using namespace-scoped deployments. In a namespace-scoped deployment, each new project for a NuoDB database contains its own NuoDB Admin “domain”. For information on Kubernetes deployment options, see concepts documented here.
In a cluster-scoped deployment, a single central project contains the NuoDB admin “domain”. In a cluster-scoped deployment, the “domain name” is the name of this single cluster-wide project - and is typically called “nuodb”.
In deployments of NuoDB managed using Kubernetes, NuoDB supports multiple NuoDB domains running in one Kubernetes cluster. In these deployments, NuoDB also supports multiple projects accessing databases from one or more NuoDB domains. In a cluster deployment, a dedicated project is set up where the NuoDB database and monitoring pods (for example, Admin and Transaction Engine pods) are located. An administration domain may be shared with other application projects where Transaction Engines (TEs) can optionally be deployed.
The placement oof the NuoDB TE pods can either be in an application or in the NuoDB project; this is a logical placement not a physical one. To optimize application runtime performance, the application pod and its preferred TE should be as closely co-located as possible, thereby reducing client-side connection latency. For example, the application and TE should be in the same pod or located on the same server node.
|NuoDB provides flexible load balancer features to control this, and allows you to decide on how close or distant clients are located to/from TEs.|