Solution design and troubleshooting
Design questions ask for a defensible architecture under constraints; troubleshooting questions ask for a diagnostic order.
Design inputs
Capture users and concurrency, data volume and growth, latency SLA, data residency, HA/DR targets (RTO/RPO), and source systems. Then select services, size worker nodes against per-service requirements, choose storage per class and capacity, and pick a topology (single cluster versus multiple instances). HA means at least three control-plane nodes, at least three workers spread across zones, and replicated storage. DR for 4.7 is backup and restore of the instance, so RTO tracks restore time rather than failover seconds.
Troubleshooting order
cpd-cli manage get-cr-status- is the operator reporting a bad CR?oc get podsandoc describe pod- image pulls, PVC binding, OOMKilled, scheduling.oc get events- quota, taints, storage provisioning failures.- Logs: operator logs in the operator namespace, service logs in the instance namespace.
- Capture
must-gatherbefore changing anything.
Worked example
Watson Studio pods stay Pending after install. describe pod shows an unbound PVC, and the only storage class is RWO. Zen and Studio components request RWX. Fix by provisioning an RWX class (ODF, Portworx, or NFS-based), patching the CR, and letting the operator reconcile - reinstalling would produce the same failure.
Traps
Reinstalling before reading events; sizing for today's data rather than 12-month growth; assuming DR is automatic failover; skipping must-gather so support cannot see the failed state; blaming storage for a CrashLoopBackOff whose logs show a bad connection string.