The GCDW (GBase Cloud Data Warehouse) 9.8.0.4.1 release introduces multi‑tenant support. Compared to the previous 9.8.0.3.5 version, the configuration has changed significantly: each tenant (account) now runs in its own dedicated Kubernetes Namespace with its own management service (gcware), coordinator, and compute warehouse.
Key Changes in values.yaml
1. Multi‑Tenant Mode
The new multiTenantMode section enables tenant isolation. When enabled, each account registered in the cloud portal becomes a tenant with an independent Namespace and dedicated resources.
multiTenantMode:
enabled: true
imageRegistry:
server: "172.16.3.249:8443"
username: "admin"
password: "XXXXX"
In a multi‑tenant cluster, platform services (operator, redis, ftp, etc.) run in the default gcdw Namespace, while tenants such as gcdw401 and gcdwb5 have their own isolated Pods, StatefulSets, and Services.
2. FoundationDB Metadata
The metadata configuration has been simplified to a single fdb_cluster string, replacing the previously scattered FDB connection parameters.
metadata:
fdb_cluster: "QdBWBJdf:S6QntDRlFdhyBstGIZnnQd6vVjf0ytAB@10.0.2.81:4500,10.0.2.82:4500,10.0.2.83:4500"
3. Kerberos Authentication
A Kerberos toggle is now available, indicating that GCDW supports Kerberos authentication mode (refer to the official documentation for detailed setup).
kerberos:
enabled: true
4. Namespace Labeling
The namespaceLabel parameter allows custom labels to be added to tenant Namespaces, helping avoid conflicts with existing Namespaces.
# namespaceLabel: "Organization=gcdw"
Complete Configuration Example
Below is a full values.yaml for a multi‑tenant deployment. CPU, memory, and replica counts have been set to the minimum recommended values for production.
global:
image:
registry: "172.16.3.249:8443"
pullPolicy: Always
imagePullSecrets: "gcdw-regcred"
multiTenantMode:
enabled: true
imageRegistry:
server: "172.16.3.249:8443"
username: "admin"
password: "XXXXXX"
metadata:
fdb_cluster: "QdBWBJdf:S6QntDRlFdhyBstGIZnnQd6vVjf0ytAB@10.0.2.81:4500,10.0.2.82:4500,10.0.2.83:4500"
storage:
enabled: false
storageClass: ""
storageSize: ""
logging:
enabled: false
filebeatImage: ""
filebeatOutput:
output.elasticsearch:
hosts:
- ""
username: ""
password: ""
index: 'gcdw-${MY_POD_NAMESPACE}-${MY_POD_NAME}-log-%{+yyyy.MM.dd}'
logrotateImage: "gcdw/gcdw-logrotate"
nodeAffinitySchedule:
cloudServiceAffinity:
key: cloudService
value: gcdw
coordiantorServiceAffinity:
key: coordinatorService
value: gcdw
warehouseServiceAffinity:
key: warehouseService
value: gcdw
kerberos:
enabled: true
# namespaceLabel: "Organization=gcdw"
operator:
enabled: true
image:
repository: gcdw/gcdw-operator
tag: 9.8.0.4.1
replicas: 1
leaderElect: true
resources:
requests:
cpu: 1
memory: 1Gi
limits:
cpu: 2
memory: 2Gi
server:
image:
repository: gcdw/gcdw-server
tag: 9.8.0.4.1
gcware_replicas: 1
coordinator_replicas: 1
gcware_resource:
request:
cpu: "1"
mem: "1Gi"
limit:
cpu: "4"
mem: 4Gi
coordinator_resource:
request:
cpu: "1"
mem: 1Gi
limit:
cpu: "4"
mem: 16Gi
warehouse_resource:
request:
cpu: "1"
mem: 1Gi
limit:
cpu: "16"
mem: 32Gi
saas:
enabled: true
TZ: "Asia/Shanghai"
image:
frontend:
repository: gcdw/clound-database-frontend
tag: 9.8.0.4.1
backend:
repository: gcdw/clound-database-backend
tag: 9.8.0.4.1
redis:
repository: gcdw/redis
tag: latest
vsftpd:
repository: gcdw/vsftpd
tag: latest
replicas:
frontend: 1
backend: 1
redis: 1
vsftpd: 1
webServicePort: 32144
Summary
GCDW 9.8.0.4.1 delivers hard resource isolation between business lines through its multi‑tenant architecture, with each tenant owning a dedicated Namespace and database service instances. When upgrading, pay close attention to the multiTenantMode and FDB metadata configuration changes, and configure Kerberos and Namespace labels as required by your environment.
In a gbase database ecosystem, this multi‑tenant GCDW release is a significant step toward true cloud‑native data warehousing, allowing multiple teams to share a single K8s cluster with full data and operational isolation.
Top comments (0)