> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Investigate the Namespace

> Guides debugging a Kubernetes payment namespace to find why the gateway API is down, revealing the API Deployment scaled to zero and steps to inspect and restore it.

Welcome back.

In the previous lesson we looked at the payment gateway UI and observed the error users were seeing. That user perspective is important during an incident. In this lesson we'll start debugging the cluster-side components behind the UI by inspecting the `payment` namespace—pods, Deployments, and related resources—to find anything suspicious.

Goal: confirm whether the API backend for the gateway is running, and if not, why.

## 1) Inspect pods in the `payment` namespace

List pods to see which application components have running pods:

```bash theme={null}
kubectl get pods -n payment
```

Example output:

```bash theme={null}
NAME                                   READY   STATUS    RESTARTS   AGE
payment-gateway-5dbc999f64-vn2hk       1/1     Running   0          2m18s
payment-processor-7f45c86c6d-5dnzg     1/1     Running   0          2m25s
```

What to look for

* Confirm presence of gateway UI and processor pods.
* Check whether the API pod (the backend) is present. In this example it is missing; that’s a red flag.

## 2) Check Deployments for desired state

Deployments reveal the desired replica counts and whether each service is available. Run:

```bash theme={null}
kubectl get deployment -n payment
```

Example output:

```bash theme={null}
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
payment-gateway         1/1     1            1           2m52s
payment-gateway-api     0/0     0            0           2m52s
payment-processor       1/1     1            1           2m59s
```

Observation: `payment-gateway-api` shows `0/0` — no replicas desired and none available. The gateway UI and processor are running, but the API Deployment is scaled to zero. That explains gateway failures: there are no API pods to serve requests.

## 3) Describe the Deployment for details and events

Run a describe to inspect configuration, pod template, resource requests/limits, and events:

```bash theme={null}
kubectl describe deployment payment-gateway-api -n payment
```

Relevant excerpt (truncated for clarity):

```bash theme={null}
Name:                   payment-gateway-api
Namespace:              payment
CreationTimestamp:      Sat, 04 Jul 2026 17:33:33 +0000
Labels:                 app=payment-gateway-api
                        app.kubernetes.io/name=payment-gateway-api
                        app.kubernetes.io/tier=backend
                        environment=prod
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=payment-gateway-api
Replicas:               0 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:               app=payment-gateway-api
  Containers:
    payment-api:
      Image:             nginx:alpine
      Port:              8080/TCP
      Limits:
        cpu:             100m
        memory:          128Mi
      Requests:
        cpu:             50m
        memory:          64Mi
Events:
  (no recent events)
```

Key detail: `Replicas: 0 desired` — the Deployment is intentionally configured to have zero replicas.

## Why would replicas be 0?

Common explanations:

* Someone manually scaled the Deployment down: `kubectl scale deployment payment-gateway-api --replicas=0`.
* A GitOps/CI change set the replica count to 0 in the declared manifest and the reconciler applied it.
* Automation or operational policy temporarily scaled it down (less common).
* A troubleshooting step was performed and not reverted.

## Quick reference — useful kubectl commands

| Purpose | Command |
| - | - |
| List pods in the namespace | `kubectl get pods -n payment` |
| List Deployments | `kubectl get deployment -n payment` |
| Describe a Deployment | `kubectl describe deployment payment-gateway-api -n payment` |
| See rollout history | `kubectl rollout history deployment/payment-gateway-api -n payment` |
| View live manifest (YAML) | `kubectl get deployment payment-gateway-api -n payment -o yaml` |
| List ReplicaSets for this app | `kubectl get rs -n payment --selector=app=payment-gateway-api` |
| Get recent events (sorted) | `kubectl get events -n payment --sort-by=.metadata.creationTimestamp` |
| Scale Deployment (if safe) | `kubectl scale deployment payment-gateway-api --replicas=1 -n payment` |

## Investigative next steps

1. Determine what changed the Deployment:
   * If API server audit logs are enabled, search for scale/update events targeting this Deployment.
   * If you run GitOps (ArgoCD or Flux), inspect the repo and recent commits that modify the Deployment manifest.
2. Inspect rollout history and last change:
   * `kubectl rollout history deployment/payment-gateway-api -n payment`
3. Confirm the declared desired replicas in the live manifest:
   * `kubectl get deployment payment-gateway-api -n payment -o yaml`
4. Inspect ReplicaSets and events for clues:
   * `kubectl get rs -n payment --selector=app=payment-gateway-api`
   * `kubectl get events -n payment --sort-by=.metadata.creationTimestamp`
5. If it should be running and you have verified it’s safe, scale it back up:
   * `kubectl scale deployment payment-gateway-api --replicas=1 -n payment`

If the Deployment was intentionally set to 0 (for maintenance or a planned outage), coordinate with the owning team or automation before scaling it up. If you can’t identify an owner, check your GitOps repo, CI/CD pipeline, or API audit logs for recent changes.

## Wrap-up

From the pod and Deployment checks we can explain the missing API: `payment-gateway-api` has `0` desired replicas. To restore the service you must first identify whether the scale-down was intentional and by whom. If it was accidental or unauthorized, either:

* Revert the change in the upstream manifest (GitOps), or
* Scale the Deployment back up with `kubectl scale`, after confirming it’s safe to do so.

In the next lesson we'll cover methods to discover the Deployment owner (audit logs, GitOps tools like ArgoCD/Flux, and ownership hints) and safe approaches to restore the desired state.

## Links and references

* Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/)
* GitOps: ArgoCD — [https://learn.kodekloud.com/user/courses/gitops-with-argocd](https://learn.kodekloud.com/user/courses/gitops-with-argocd)
* GitOps: FluxCD — [https://learn.kodekloud.com/user/courses/gitops-with-fluxcd](https://learn.kodekloud.com/user/courses/gitops-with-fluxcd)

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/5d434b76-bd5d-4526-b9c6-4a994c195994/lesson/6ee155b2-839f-44d9-8f60-6f71bd0a5f55)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.