Data and AI architecture
Cloud Pak for Data v4.7 is OpenShift-native, so architecture questions almost always reduce to four layers: the cluster, IBM Cloud Pak foundational services, the Cloud Pak for Data control plane, and the individual services.
The four layers
- OpenShift Container Platform supplies compute, the ingress/router, and - critically - storage classes. Most platform components need ReadWriteMany; Db2U needs a block (RWO) class.
- Foundational services provide identity and access management, the license service, and shared operators.
- Control plane (
cpd_platform) deploys Zen - the unified UI, API gateway, and user/role store - plus common core services, the scheduler, and events. - Services are each an operator plus a custom resource: Db2U, Watson Studio, Watson Machine Learning, Watson Knowledge Catalog, Watson Query, DataStage, and so on.
Tenancy model
Installs use an operator namespace (conventionally cpd-operators) and an instance namespace (cpd-instance). One instance lives in one namespace; several instances can coexist on a cluster in separate namespaces. Inside an instance, projects, catalogs, and deployment spaces are the scopes users actually work in.
Worked example
A retailer needs governed self-service analytics for 60 users: catalogs, notebooks, and virtualized access to an Oracle warehouse. The design is one instance namespace with the control plane plus WKC, Watson Studio, and Watson Query. WKC and Studio add significant memory, so size beyond the three-worker minimum; confirm an RWX class exists for Zen and platform storage and a block class for Db2U. Because the Oracle data stays in place, Watson Query supplies the access path and the source system carries the load - state that trade-off explicitly.
Traps
Treating Zen as "just the UI" ignores that it carries authentication and the REST gateway. Forgetting the RWX requirement leaves pods stuck on unbound PVCs. Treating services as one monolith hides that each CR has its own resource profile and upgrade cadence.