Frequently Asked Questions About Cloud Guru React-to-Kubernetes Deploy Pattern
22 answers covering everything from basics to advanced usage.
// Basics
What is the Three-Stage Pipeline?
The Three-Stage Pipeline is the ordered deployment sequence at the heart of this skill: Run Locally → Containerise with Docker → Deploy on Kubernetes. Each stage must be validated before proceeding to the next. You never skip to Kubernetes without first confirming the Docker image works locally, which catches most failures early.
What is Container Registry Parity?
Container Registry Parity is the principle that when deploying to a managed Kubernetes service, the Docker image must be built and pushed inside that provider's own Container Registry, not just Docker Hub. The build command is essentially the same — only the target registry endpoint changes, such as registry.ng.icr.io for IBM Cloud US South.
What does the Components vs. Containers architecture mean?
It's a React/Redux structural pattern where Containers hold all business logic, state, and API-call dispatches, while Components are purely presentational and reusable with no embedded logic. API calls live in the Redux Actions layer, not in components. This separation keeps components reusable across contexts and centralises where API keys and async logic live.
What is a NodePort in Kubernetes?
A NodePort is a Kubernetes service exposure type that opens a specific port on every cluster worker node, making the service externally accessible. It's recommended for initial deployments and first-timers because it's simple and sufficient. LoadBalancer is the upgrade path for production cases needing advanced traffic management.
What is the correct order of prerequisites before touching any code?
Secure the external API key from the third-party provider, install Node.js, have Docker Desktop running, and export DOCKER_USERNAME as an environment variable that persists for the whole session. You also need a pre-created namespace and cluster name in your target Kubernetes provider. Getting all prerequisites first prevents mid-pipeline blockers.
// How To
How do I insert an API key correctly in this pattern?
Locate the API call inside the Redux Actions file — not in a Component or Container — and paste the key there. This is the only place it should live. Confirm the app has distinct action types for start, success, and error states, which supports future loading and skeleton UI patterns and makes key rotation simpler.
How do I build and run the Docker image locally before deploying?
Run docker build -t $DOCKER_USERNAME/image-name:latest . and confirm the build completes. Then verify with docker images that it appears in the list. Run it with docker run -p host-port:container-port $DOCKER_USERNAME/image-name and navigate to localhost:host-port to confirm the containerised app works identically to the local version before moving to Kubernetes.
How do I build a Docker image inside IBM Cloud Container Registry?
Run ibmcloud cr build -t registry.<region>.icr.io/<namespace>/<image-name>:latest . substituting your region code (e.g. 'ng' for US South, 'eu' for Europe) and namespace. This step is structurally identical to a local docker build but targets the cloud registry endpoint, satisfying Container Registry Parity.
How do I create and expose a Kubernetes Deployment?
Create the deployment with kubectl create deployment <name> --image=registry.<region>.icr.io/<namespace>/<image>:latest, then confirm with kubectl get deployments. Expose it with kubectl expose deployment <name> --type=NodePort --name=<service> --port=<app-port>, ensuring the --port value matches the Dockerfile EXPOSE port to honour the Port Consistency Contract.
How do I find the public URL of my deployed app?
Get the worker public IP with ibmcloud cs workers <cluster-name> and copy the Public IP. Then run kubectl describe service <service-name> and locate the NodePort field value. Your app is accessible at Public-IP:NodePort — verify it in a browser.
// Troubleshooting
Why does my Kubernetes deployment show no data even though Docker worked?
The most common cause is a Port Consistency Contract violation — the Dockerfile EXPOSE port doesn't match the --port flag in kubectl expose, so the app silently fails to respond on the expected port. The second most common cause is a missing or invalid API key in the Redux Actions layer, which returns empty responses rather than errors.
Why are my styles missing after starting the app?
You likely skipped npm run build:css before npm run start. Sass won't be compiled, so styles are missing. Always run the CSS build step first during local validation. If styles are missing locally, they'll be missing in the container too — fix it before building the Docker image.
Why do my image names keep coming out inconsistent across commands?
You probably didn't export DOCKER_USERNAME as an environment variable before building. Run export DOCKER_USERNAME=<your-username> once at session start and reference it as $DOCKER_USERNAME in every build, tag, and push command. This eliminates manual typos and keeps naming aligned across the whole pipeline.
Why can't Kubernetes pull my image even though it's on Docker Hub?
Managed Kubernetes services like IBM Cloud require the image to live in their own Container Registry, not just Docker Hub. This is the Container Registry Parity principle. Rebuild the image with ibmcloud cr build targeting the registry.<region>.icr.io endpoint and reference that path in your kubectl create deployment command.
Are deprecated npm module warnings during the Docker build a problem?
No — deprecated npm module warnings during the build are acceptable as long as the build itself completes successfully. Focus on whether docker build finishes and the image appears in docker images. Don't get distracted debugging warnings that don't block the build.
// Comparisons
How does this pattern compare to a generic 'docker build and kubectl apply' workflow?
Generic workflows often skip local validation and push straight to Docker Hub, then fail silently on managed clusters. This pattern enforces staged validation, Container Registry Parity (build inside the provider's registry), and the Port Consistency Contract. These guardrails catch the exact failures — no data, image pull errors — that plain build-and-apply workflows leave you debugging in production.
How does NodePort compare to LoadBalancer for a first deployment?
NodePort is simpler and sufficient for initial deployments — it opens a port on every worker node and needs no external provisioning. LoadBalancer provisions a managed load balancer for advanced traffic management but adds cost and complexity. Start with NodePort to get your app live, then migrate to LoadBalancer when production traffic patterns justify it.
How does putting API calls in Actions compare to putting them in Components?
Placing API calls in the Redux Actions layer centralises async logic, supports start/success/error action types for loading UI, and makes key rotation trivial. Putting calls in Components scatters logic, couples presentation to data-fetching, and breaks reusability. The Components vs. Containers architecture keeps components logic-free and presentational, which is why the Actions layer is the single correct home.
// Advanced
Can I use this pattern with providers other than IBM Cloud?
Yes — the pattern works with any equivalent managed Kubernetes provider. Only the Container Registry endpoint and CLI commands change (e.g. AWS ECR, GCP Artifact Registry, Azure ACR instead of ibmcloud cr build). The three-stage flow, Port Consistency Contract, and NodePort exposure remain identical. The IBM Cloud region code input is only needed for the IBM Cloud variant.
How do I set up loading skeletons using this architecture?
Ensure your Redux Actions define distinct action types for start, success, and error states. The start action can trigger a loading or skeleton UI in your presentational Components, success renders data, and error renders a fallback. Because logic lives in Containers and Actions, your Components simply react to state changes, making skeleton patterns clean to implement.
Can I migrate from NodePort to LoadBalancer later without rebuilding everything?
Yes — the migration only changes the service exposure type. Delete the existing NodePort service and re-run kubectl expose with --type=LoadBalancer, or edit the service spec. Your Deployment, image, and Dockerfile stay untouched. This is why the pattern recommends starting with NodePort: the upgrade path is low-risk and doesn't disturb the rest of the pipeline.
What is an IBM Code Pattern and how does it relate to this skill?
A Code Pattern is IBM's term for a reference implementation repository that demonstrates a specific architectural or deployment approach, intended to be cloned and adapted. This skill is built around cloning such a pattern, inserting your API key into the Actions layer, and following the three-stage pipeline to deploy it to your own cluster.