Operate and Scale OrderFlow

Scale, troubleshoot, and roll back OrderFlow workloads on local Kubernetes.

Introduction

30 Second Summary

An online shop feels dependable when product pages keep loading through maintenance or a server failure. That confidence depends on operators who can spot an unsafe change before customers feel it.

In this project, you will turn the inherited OrderFlow cluster into a live operations lab on local Kubernetes. The finished lab proves that Catalog stays available while you disrupt it and recover it.

What You'll Build

You will watch gateway requests keep succeeding while Kubernetes scales Catalog to three replicas, replaces a deleted Pod, blocks an unsafe release from traffic, and restores the healthy revision with rollback.

By the end of this project, you'll have:

A three-replica Catalog Deployment that keeps serving product requests while Kubernetes replaces a deleted Pod.
A Service DNS lookup that resolves catalog-service.orderflow without relying on a changing Pod IP.
A cluster evidence trail that uses ReplicaSets, readiness probes, and EndpointSlices to explain a rolling restart and recover from a stalled release.
Secret Mission: Pause Catalog, batch two harmless Pod-template annotations, then resume them as one controlled rollout.

Are there any prerequisites?

You need the healthy OrderFlow cluster from Translate OrderFlow into Kubernetes before you begin. Your confirmed Linux setup also needs Docker Desktop, kubectl, and curl ready to use.

Before We Start

Before you change the healthy OrderFlow cluster, this step helps you commit to the operational proof you want to produce. You will define why Catalog must remain available while you scale, disrupt, diagnose, and recover it.

Validate the Inherited Cluster

You have committed to operating catalog-service through scaling, disruption, diagnosis, and recovery. Those tests only prove the Kubernetes controller loop when the inherited cluster starts in a healthy state.

A known baseline requires the correct Docker Desktop context. It also needs a reproducible request path through the gateway.

In this step, get ready to:

Confirm the active cluster context and its Ready node.
Validate the inherited Deployments, Services, labels, and HTTP readiness probe.
Keep a gateway port-forward running while you verify the Catalog product path.

Confirm the active cluster

The active kubectl context decides which cluster receives every operation. Checking the context first protects other clusters from accidental changes.

Check the active cluster and node health by running these commands:

kubectl config current-context
kubectl version
kubectl get nodes

What do these checks prove?

The kubectl config current-context command names the cluster that receives your commands.
The kubectl version command confirms that the client can reach the cluster API.
The kubectl get nodes command exposes the local node's readiness state.

You should see docker-desktop as the current context. The local node should report Ready.

If another context is active, switch kubectl to Docker Desktop by running this command:

kubectl config use-context docker-desktop

What does this change?

This selects docker-desktop as the active context. Future kubectl commands now target your local cluster.

Repeat the three cluster checks above if you changed the active context.

Cluster not reporting Ready?

Confirm that the local Kubernetes cluster is running in Docker Desktop. Give the node time to finish starting before repeating the checks.

If the client still cannot reach the cluster, help me diagnose my Docker Desktop Kubernetes connection.

Validate the inherited contract

Every later operation depends on exact resource names and matching Catalog labels. The readiness failure experiment also depends on the inherited probe path.

Inspect the OrderFlow resources and Catalog contract by running these commands:

kubectl get deployment,service,pod -n orderflow
kubectl get deployment/catalog-service -n orderflow -o jsonpath='selector={.spec.selector.matchLabels.app} podLabel={.spec.template.metadata.labels.app} readiness={.spec.template.spec.containers[0].readinessProbe.httpGet.path}{"\n"}'

What do these checks prove?

The resource listing shows whether the inherited application is available in the orderflow namespace.
The JSONPath output compares the Deployment selector with the Pod-template label.
The same output extracts the readiness path that controls Catalog traffic eligibility.

You should see available catalog-service, inventory-service, checkout-service, and gateway Deployments. You should also see the catalog-service and gateway Services.

The second command should print selector=catalog-service podLabel=catalog-service readiness=/health. The inherited Catalog readiness probe should target container port 8001.

Inherited contract does not match?

A missing resource or mismatched value means the prerequisite cluster needs repair before this operations lab continues.

Return to the Translate OrderFlow into Kubernetes project.
Reapply its inherited manifests.
Repeat both contract checks above.

If the mismatch persists, help me compare my inherited OrderFlow resources with the required cluster contract.

Open the stable request path

The gateway gives you one stable local path for every availability check in this project. Keeping that path open makes later disruptions measurable from the application's edge.

Use your current terminal as terminal A.
Start the gateway port-forward by running this command:

kubectl port-forward service/gateway 8000:8000 -n orderflow

What does the port-forward do?

The command maps local port 8000 to port 8000 on service/gateway in the orderflow namespace. The process stays attached to terminal A while the forwarding session is active.

Terminal A should remain occupied by the forwarding process. This is the live connection that exposes the gateway at http://127.0.0.1:8000.

Leave terminal A running.
Start a second terminal window from your Linux application launcher.
Use the new window as terminal B.

Before you send the request, do you expect the inherited gateway to return Catalog data without an HTTP error?

Test the gateway request path from terminal B by running this command:

curl --fail http://127.0.0.1:8000/products

What does this request prove?

The request enters OrderFlow through the forwarded gateway. The --fail option turns an HTTP error response into a command failure.

A product response proves the gateway can reach Catalog through the inherited cluster path. That path becomes your availability signal during later Pod replacements.

You should see the Catalog product list without an HTTP error. That's your healthy baseline confirmed.

Gateway request not succeeding?

Confirm that terminal A still shows an active forwarding session. If local port 8000 is already occupied, reuse the existing gateway forward instead of starting another one.

A forwarding session ends when its selected gateway Pod terminates. Restart the port-forward command in terminal A if that happened.

If the request still fails, help me trace the gateway port-forward and Catalog request path.

That's your baseline secured. Next, you'll scale Catalog to three replicas while preserving a safe request path.

Scale Catalog and Prove Service Discovery

Your healthy OrderFlow path currently depends on one Catalog Pod. A single replica gives Kubernetes no spare Pod when that instance changes.

This step turns the catalog-service Deployment into three replicated Pods under a deterministic desired state. You will then resolve its stable Service name through cluster DNS.

In this step, get ready to:

Capture the current Catalog replica count plus one Pod name and IP address.
Scale Catalog to three replicas under a rollback-safe rollout policy.
Resolve the Catalog Service from a DNS helper inside the cluster.

Capture the one-replica baseline

A baseline records the workload before you change its desired state. It gives you a Pod name and IP address to compare with the stable Service later.

Return to terminal B and inspect the current Catalog Deployment plus its Pod details by running these commands:

kubectl get deployment/catalog-service -n orderflow
kubectl get pods -n orderflow -l app=catalog-service -o wide

What does this baseline show?

The Deployment summary shows the current desired count plus the number of available replicas.
The label selector limits the Pod listing to Catalog.
The -o wide flag adds the generated Pod name and IP address to the output.

Record the current desired replica count here: your current Catalog replica count.
Record one generated Catalog Pod name here: your current Catalog Pod name.
Record that Pod's IP address here: your current Catalog Pod IP address.

Make scaling deterministic

A Deployment keeps a desired replica count while controllers move the cluster toward that target. The rollout policy protects available traffic during replacement.

Readiness decides which Pods can receive Service traffic. The wait may sit quietly while Kubernetes starts the extra Pods.

Reach three available replicas under the safe rollout policy by running these commands:

kubectl patch deployment/catalog-service -n orderflow --type='merge' -p='{"spec":{"revisionHistoryLimit":10,"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxUnavailable":0,"maxSurge":1}}}}'
kubectl patch service/catalog-service -n orderflow --type='merge' -p='{"spec":{"publishNotReadyAddresses":false}}'
kubectl scale deployment/catalog-service -n orderflow --replicas=3
kubectl wait --for=jsonpath='{.status.availableReplicas}'=3 deployment/catalog-service -n orderflow --timeout=90s

What do these commands change?

The Deployment patch retains 10 revisions for later rollback practice.
The RollingUpdate strategy permits 0 unavailable Pods and 1 surge Pod during replacement.
The Service patch keeps unready Catalog endpoints out of normal traffic.
The scale command sets the desired count to 3. The wait command pauses until all three replicas are available.

Scaling taking too long?

Inspect the Catalog Pod listing for a replica that is still becoming Ready.
Confirm the inherited readiness probe still checks /health on port 8001.

Help me diagnose why the Catalog Deployment has not reached three available replicas.

Before you inspect the stored policy, which values do you expect for availability, surge capacity, revision history, and traffic eligibility?

Verify the stored rollout policy plus the three Catalog Pods by running these commands:

kubectl get deployment/catalog-service -n orderflow -o jsonpath='strategy={.spec.strategy.type} maxUnavailable={.spec.strategy.rollingUpdate.maxUnavailable} maxSurge={.spec.strategy.rollingUpdate.maxSurge} history={.spec.revisionHistoryLimit}{"\n"}'
kubectl get service/catalog-service -n orderflow -o jsonpath='publishNotReadyAddresses={.spec.publishNotReadyAddresses}{"\n"}'
kubectl get pods -n orderflow -l app=catalog-service -o wide

What should you see?

The strategy output includes RollingUpdate with maxUnavailable set to 0.
The same line shows maxSurge set to 1 plus a history limit of 10.
The Service output shows publishNotReadyAddresses=false.
The Pod listing shows three Catalog Pods at 1/1 Ready.

Strong result. Catalog now has three interchangeable replicas plus a rollout policy that preserves healthy capacity.

Resolve the stable Service name

Pod names and IP addresses can change whenever controllers replace replicas. Service DNS gives workloads a stable destination that stays independent of those Pod identities.

The dnsutils helper runs inside the cluster. Its lookup tests the same DNS path that another workload can use.

Create the official DNS test Pod in the default namespace by running these commands in terminal B:

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
kubectl wait --for=condition=Ready pod/dnsutils --timeout=90s

What do these commands do?

The apply command creates the official dnsutils helper from the Kubernetes manifest.
The wait command holds the next check until the helper reports Ready.
The helper remains in the default namespace so the final lookup proves cross-namespace Service discovery.

Your next move depends on whether the helper reached Ready.

✔️ dnsutils is Ready

The DNS helper is running inside the cluster. Continue to the final lookup.

ⓧ The manifest was unavailable

A failed manifest download can leave the helper Pod absent. The first recovery command is expected to report that the Pod is missing.

Recover with the pinned helper image by running these commands in terminal B:

kubectl get pod/dnsutils
kubectl run dnsutils --image=registry.k8s.io/e2e-test-images/agnhost:2.39 --restart=Always
kubectl wait --for=condition=Ready pod/dnsutils --timeout=90s

How does the fallback work?

The first command confirms that the manifest did not create the helper Pod.
The second command creates dnsutils directly from the pinned image.
The final command waits until the replacement helper is Ready.

Helper still not Ready?

Check that Docker Desktop can pull the pinned image through your current network connection.

Help me diagnose why my dnsutils Pod is not becoming Ready.

Before you run the final check, do you expect the lookup to depend on the Pod IP you recorded earlier?

Verify the three-replica Deployment plus cross-namespace Service resolution by running these commands in terminal B:

kubectl get deployment/catalog-service -n orderflow
kubectl exec dnsutils -- nslookup catalog-service.orderflow

What should you see?

The Deployment shows 3/3 Ready. The lookup returns an address for catalog-service.orderflow.

The stable name belongs to the Catalog Service. Individual Catalog Pod IPs can change without changing that destination.

Compare the lookup address with your current Catalog Pod IP address.

You have proved that Catalog clients can use one stable Service name while Kubernetes manages three replaceable Pods behind it.

DNS lookup not resolving?

Confirm the outcome tab shows the dnsutils Pod reached Ready.
Check that the lookup uses the cross-namespace name catalog-service.orderflow.
Confirm the Catalog Service still exists in the orderflow namespace.

Help me diagnose why catalog-service.orderflow does not resolve from dnsutils.

Catalog now has redundant capacity plus a stable in-cluster address. Next, you will disrupt those Pods and watch Kubernetes restore the desired state.

Watch Controllers Repair and Replace Pods

Catalog traffic already has three Ready replicas behind a stable Service. The next operational question is whether Kubernetes controllers can restore that state after a Pod disappears.

A manual deletion reveals self-healing. A rolling restart reveals gradual replacement while the gateway keeps serving traffic.

In this step, get ready to:

Observe self-healing after deleting one Catalog Pod.
Monitor gateway requests for HTTP 200 responses during Pod replacement.
Complete a rolling restart through a new Catalog ReplicaSet.

Observe controller reconciliation

A Deployment stores the desired replica count. Its ReplicaSet creates a replacement whenever the actual Pod count falls below three.

Switch back to terminal B from earlier.
List the current Catalog Pods by running this command:

kubectl get pods -n orderflow -l app=catalog-service -o wide

What Does This Show?

The wide view shows each generated Pod name. It also shows the current IP for each Pod.

Record one generated Pod name here: catalog Pod name.
Record the IP shown for that Pod here: catalog Pod IP.

Before you delete the Pod, do you expect the Catalog replica count to remain below three?

Replace <catalog-pod-name> in the command sequence below with the Pod name you recorded.
Delete the selected Pod and start the watch by running the edited command sequence:

kubectl delete pod <catalog-pod-name> -n orderflow
kubectl get pods -n orderflow -l app=catalog-service --watch

What Is Reconciling the Change?

Kubernetes compares the actual Pod count with the Deployment's desired count. The ReplicaSet creates a replacement as soon as the count falls below three.

The watch streams each Pod change. This makes the controller response visible as it happens.

Press Ctrl+C after all three Catalog Pods show 1/1 Ready.
Compare the deleted Pod name with the replacement Pod name.
Compare the recorded IP with the replacement Pod IP.

You'll see a new Pod identity with a new IP. The Deployment returns to three Ready replicas without manual recreation.

Replacement Pod Not Becoming Ready?

Check whether the watch shows three Catalog Pods. A replacement may still be starting.

Confirm that your command targeted a Pod with the app=catalog-service label.

Need help tracing the replacement?

Monitor gateway availability

The gateway request path remains active while Catalog Pods change. A short curl loop samples that path once per second for 20 requests.

Create terminal C by opening a separate terminal session beside terminal B.
Switch back to terminal B from earlier.
Start the gateway availability loop by running this code:

i=1
while [ "$i" -le 20 ]; do
  curl --silent --show-error --fail --output /dev/null --write-out '%{response_code}\n' http://127.0.0.1:8000/products
  i=$((i + 1))
  sleep 1
done

What Does This Loop Measure?

The counter limits the check to 20 requests. Curl discards each response body.

Each successful request prints only its response code. Any connection problem remains visible in terminal B.

Restart the Deployment and inspect the rollout

A rollout restart changes the Deployment's Pod template. That change starts a new ReplicaSet for a controlled rolling update.

The status check can take up to 90 seconds while Kubernetes replaces the Pods.

Before you run this, do you expect the gateway loop to show any status other than 200?

Switch immediately to the prepared terminal C.
Trigger the restart and inspect the completed rollout by running these commands:

kubectl rollout history deployment/catalog-service -n orderflow
kubectl rollout restart deployment/catalog-service -n orderflow
kubectl rollout status deployment/catalog-service -n orderflow --timeout=90s
kubectl get deployment/catalog-service -n orderflow
kubectl get replicasets -n orderflow -l app=catalog-service
kubectl get pods -n orderflow -l app=catalog-service -o wide

What Does This Sequence Prove?

The history command captures the existing Deployment revisions.
The restart command updates the Pod template.
The template change creates a new ReplicaSet.
The status command follows the rollout until the replacement finishes.
The final inspection commands expose the Deployment state.
The final inspection commands also expose ReplicaSet ownership and current Pod identities.

Return to terminal B after the rollout completes.

You should see 20 response lines containing only 200. The gateway remained available throughout the restart.

Return to terminal C to review the final Deployment output.

You'll see three Ready Catalog Pods owned by the newest ReplicaSet. Prior ReplicaSets remain as retained rollout history.

Rollout or Requests Failing?

If terminal B shows a connection failure, check whether the gateway port-forward is still running in terminal A. Restart the forward using the command from Step 1 if that process ended.

If the rollout does not complete, review the final Pod output for a replacement that has not reached Ready status.

Help me diagnose the interrupted rollout.

Strong work. You now have direct evidence that the controllers restore desired state and replace Pods without interrupting gateway traffic.

Next, you'll deliberately break Catalog readiness and watch Kubernetes isolate the unsafe release.

Break Readiness and Stall a Rollout

Your last rolling restart finished with the Catalog Deployment on three Ready Pods. The availability loop returned only HTTP 200 responses.

A Kubernetes rolling update can create a running Pod whose readiness probe blocks it from becoming available. This deliberate failure exposes the difference between process state and traffic eligibility.

In this step, get ready to:

Create a new Catalog revision with a deliberately invalid readiness path.
Observe the stalled rollout while healthy replicas keep serving gateway traffic.
Inspect the EndpointSlice evidence that keeps the unready Pod out of Service traffic.

Record the healthy revision and corrupt readiness

Rollout history gives you a healthy baseline before the experiment changes the Pod template. The retained revision remains available for the recovery work in the next step.

Switch back to terminal C from the previous step.
Inspect the healthy rollout history by running this command:

kubectl rollout history deployment/catalog-service -n orderflow

What does rollout history show?

The output lists the retained Catalog revisions. Each revision represents a stored Pod template that Kubernetes can use for rollback.

Enter the latest healthy revision here: your healthy Catalog revision.
Replace the Catalog readiness path by running this command:

kubectl patch deployment/catalog-service -n orderflow --type='json' -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/path","value":"/not-ready"}]'

What does this patch change?

The kubectl patch command changes only the HTTP path in the first container's readiness probe. The probe now requests /not-ready.

The change updates .spec.template. Kubernetes responds by creating a new Deployment revision.

Confirm the terminal reports that the Catalog Deployment changed.

Patch could not find the probe?

Confirm the Catalog Deployment still has its HTTP readiness probe on /health.
Return to the prerequisite manifests if the inherited Deployment structure has drifted.

Need help tracing the inherited probe structure?

Observe the incomplete rollout

A Deployment completes when every requested replica is updated and available. The Catalog rollout policy also preserves all three healthy replicas while the new revision is evaluated.

Before you run the check, what do you expect the controller to do with the new revision?

Run the designed-obstacle checks one at a time in terminal C by using these commands:

kubectl rollout status deployment/catalog-service -n orderflow --timeout=30s
kubectl get deployment/catalog-service -n orderflow
kubectl get replicasets -n orderflow -l app=catalog-service
kubectl get pods -n orderflow -l app=catalog-service -o wide
curl --fail http://127.0.0.1:8000/products

Why is this the intended result?

The status check reaches its configured timeout because the newest revision cannot become available.
The ReplicaSet view shows a new revision beside the preceding healthy revision.
The Pod list shows at least one new Pod as Running but 0/1 Ready.
The three preceding replicas remain Ready because the rollout policy allows zero unavailable Pods.
The curl request succeeds because the gateway still reaches healthy Catalog replicas.

Seeing a different result?

Check that terminal A still shows the active gateway port-forward if the product request fails.
Inspect the Catalog readiness path if the rollout completes instead of timing out.
Confirm the new Catalog Pod belongs to the newest ReplicaSet if every Pod still appears Ready.

Help me diagnose my unexpected rollout state.

Inspect traffic eligibility

An EndpointSlice records the backends associated with a Service. Its readiness conditions show which Pod addresses can receive normal Service traffic.

Before you inspect the Service boundary, which endpoint do you expect Kubernetes to exclude?

Inspect the Catalog EndpointSlice by running this command in terminal C:

kubectl get endpointslice -n orderflow -l kubernetes.io/service-name=catalog-service -o yaml

How do EndpointSlices protect traffic?

The label selector returns EndpointSlices owned by the Catalog Service.
The failed new Pod has a conditions.ready value of false.
The healthy endpoints retain a true readiness condition.
The Service keeps publishNotReadyAddresses set to false. The failed endpoint stays outside normal Service traffic.

Cannot find the unready endpoint?

Compare the readiness condition under each endpoint in the returned YAML.
Confirm the label selector uses kubernetes.io/service-name=catalog-service.
Check that the newest Catalog Pod still shows 0/1 Ready.

Help me interpret the Catalog EndpointSlice output.

You have trapped a bad release without dropping Catalog traffic. The failed Pod remains visible for diagnosis while the healthy replicas continue serving requests.

Next, you'll trace the failed signal to /not-ready. Then you'll restore the preceding healthy revision.

Diagnose and Roll Back

The stalled Kubernetes Deployment now has one Running Catalog Pod that cannot become Ready. Three healthy replicas are keeping gateway traffic alive while you investigate.

This step follows the failure from controller conditions to the failed readiness probe. A rollback through retained history then restores the last healthy Pod template.

In this step, get ready to:

Trace the failed readiness signal through Deployment conditions and Pod evidence.
Restore the preceding healthy revision from rollout history.
Prove that Catalog readiness and gateway traffic have recovered.

Trace the failed readiness signal

Deployment conditions show the controller's progress. Pod descriptions expose the probe that blocks readiness.

Inspect the stalled rollout from a terminal outside terminal A by running these commands:

kubectl describe deployment/catalog-service -n orderflow
kubectl describe pods -n orderflow -l app=catalog-service

What does this evidence show?

The Deployment description connects the stalled rollout to its ReplicaSets.
The Pod descriptions show readiness status plus probe events for each selected Catalog Pod.
Together, the outputs link the newest revision to the failed readiness path.

Read the Deployment conditions to identify the ReplicaSet that has not become available.
Locate the newest Pod that is 0/1 Ready.
Match that Pod's failed probe path to /not-ready.

You should find that the newest Pod is Running but 0/1 Ready. Its probe events point to /not-ready as the failed Pod-template change.

Can't find the failed probe?

Make sure the Pod command still uses app=catalog-service in orderflow. Focus on the Pod showing 0/1 Ready.

Help me trace the stalled Catalog rollout.

Roll back the bad revision

The retained rollout history contains the healthy Pod template from before the probe change. The undo operation restores that preceding revision.

Before you run these commands, predict which readiness path the preceding revision restores.

Restore the preceding healthy revision by running these commands:

kubectl rollout history deployment/catalog-service -n orderflow
kubectl rollout undo deployment/catalog-service -n orderflow
kubectl rollout status deployment/catalog-service -n orderflow --timeout=90s

How does the rollback work?

The history output confirms that previous Deployment revisions remain available.
The undo operation restores the preceding Pod template without changing the desired replica count.
The status check waits for the restored rollout to finish.

The rollout status check should complete successfully. New Pods then pass the restored /health readiness probe.

That is the recovery point: the preceding healthy Pod template is active again.

Rollback still waiting?

Confirm the undo command targeted deployment/catalog-service in orderflow.
Review the Pod descriptions again if a restored Pod remains unready.
Check that terminal A still has the gateway port-forward running.

Help me diagnose a Catalog rollback that is still waiting.

Prove readiness and traffic recovered

Controller recovery is complete when workload state matches Service traffic eligibility. The EndpointSlice plus the gateway request provide that proof.

Before you run the final checks, predict whether the failed endpoint remains eligible for Service traffic.

Verify the recovered Catalog workload from end to end by running these commands:

kubectl get deployment/catalog-service -n orderflow
kubectl get replicasets -n orderflow -l app=catalog-service
kubectl get pods -n orderflow -l app=catalog-service -o wide
kubectl get endpointslice -n orderflow -l kubernetes.io/service-name=catalog-service -o yaml
curl --fail http://127.0.0.1:8000/products

What do these checks prove?

The Deployment, ReplicaSets, and Pods show whether the controller restored three healthy replicas.
The EndpointSlice shows which Catalog endpoints are eligible for Service traffic.
The gateway request confirms that the complete request path still reaches Catalog.

You'll see the Deployment report 3/3 Ready with three controller-managed Catalog Pods.

The EndpointSlice should contain healthy Catalog endpoints with conditions.ready=true.

The final curl request should return the Catalog product list without an HTTP error.

Recovery checks still failing?

Confirm the rollout status command completed before checking the Pods.
Check terminal A for the active gateway port-forward if the product request fails.
Describe any remaining unready Catalog Pod to inspect its current probe events.

Help me diagnose a failed Catalog recovery check.

You recovered Catalog from a bad release while healthy replicas kept serving requests. Your operator workflow now covers diagnosis, rollback, readiness, and end-to-end traffic verification.

Secret mission

Batch a Controlled Release

Pause the Catalog Deployment so two harmless Pod-template annotations stay queued without a new ReplicaSet. Resume once to release both changes through one completed rollout.

Clean Up Your Resources

Choose whether to keep the lab running, pause it for later, or delete it entirely. This lab runs on your local Docker Desktop Kubernetes cluster with no ongoing cloud costs.

Resources you used:

Your active gateway Service port-forward in terminal A.
Your Ready dnsutils Pod in the default namespace.
Your inherited orderflow namespace containing the application Deployments, Services, and ReplicaSets.
Your Catalog rollout state with three Ready replicas, retained revision history, and batched Pod annotations.

Keep everything running

No action needed. Choose this if you want to continue testing OrderFlow or practising Kubernetes operations.

Leave terminal A running to keep the gateway available at http://127.0.0.1:8000/products.
Keep the dnsutils Pod available for more Service DNS checks.
Keep the orderflow namespace available with three Ready Catalog replicas.
Press Ctrl+C in terminal A when you no longer need local gateway access.

Pause - I'll come back to this later

Shut down the running processes to free local resources. Keep the cluster definitions for your return.

Switch back to terminal A.
Press Ctrl+C to stop the gateway port-forward.
Return to terminal B.
Pause the local lab by running these commands:

kubectl delete pod/dnsutils --ignore-not-found
kubectl scale deployment --all --replicas=0 -n orderflow
kubectl scale statefulset --all --replicas=0 -n orderflow

What does this pause do?

The first command removes the temporary DNS helper Pod from the default namespace.

The scaling commands set every Deployment plus any StatefulSets in orderflow to zero replicas. Their definitions remain in the cluster.

Reapply the manifests from Translate OrderFlow into Kubernetes when you are ready to restore their declared replica counts.

Your lab is now paused. Its Kubernetes definitions remain ready for your return.

Delete - I don't want to use this again

This option removes the helper Pod plus the complete OrderFlow namespace. Deleting the namespace is permanent, but the prerequisite manifests can rebuild it later.

Switch back to terminal A.
Press Ctrl+C to stop the gateway port-forward.
Return to terminal B.
Delete the complete local lab by running these commands:

kubectl delete pod/dnsutils --ignore-not-found
kubectl delete namespace orderflow

What does this deletion remove?

The first command removes the temporary dnsutils Pod if it still exists.

The second command removes the orderflow namespace plus every resource inside it. This includes the inherited application resources from the prerequisite project.

The local Docker Desktop cluster remains available. The OrderFlow application and its rollout history are gone.

Nice Work!

You did it! The inherited OrderFlow cluster is now a Kubernetes operations lab where Catalog stays available through deliberate disruption.

What you learned:

Scaled Catalog to three Ready replicas under a zero-unavailable rollout policy. You used Kubernetes DNS to reach its stable Service name while Pod IPs changed.
Proved controller reconciliation against the desired state by deleting one managed Pod. You watched Kubernetes replace it while a rolling restart kept gateway requests returning 200.
Isolated a failed release with readiness evidence from Pods plus an EndpointSlice. You traced /not-ready to the bad revision. A rollback restored three Ready Catalog replicas.
Secret Mission: Paused Catalog while you batched two harmless Pod-template annotations without creating a ReplicaSet. Resuming the Deployment released both changes through one controlled rollout.

Ready to quiz yourself?