> ## 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. # Section Overview > Improving a WebApp Kubernetes controller to report observed state via status fields, conditions, events, and explicit reconcile requeue decisions so users see health and progress. The WebApp controller already creates the child resources defined by a WebApp custom resource: a Deployment, a Service, and a ConfigMap. However, from the user's perspective the controller remains largely silent — it builds the children but does not report what it observes. The image shows a diagram illustrating a "WebApp controller" that generates "Deployment," "Service," and "ConfigMap" components, with the caption "It Builds the Children, but Stays Quiet."

The image shows a diagram illustrating a "WebApp controller" that generates "Deployment," "Service," and "ConfigMap" components, with the caption "It Builds the Children, but Stays Quiet."

When you run kubectl get on the WebApp resource, the output doesn't indicate whether the Deployment is ready, whether the controller is still working, or whether anything noteworthy occurred during reconcile: ```bash theme={null} $ kubectl get webapp web-app-sample -o yaml spec: image: nginx:1.27 replicas: 3 status: {} ``` Kubernetes resources are more helpful when they report observed state where users already look for it. Built-in controllers routinely separate intent and observation: * `spec` holds the user's desired intent. * `status` records observed facts. * `conditions` summarize readiness and progress in a structured, machine-readable way. * `events` provide a concise timeline of important actions. For comparison, `kubectl describe` on a Deployment shows both intent and observed state: ```bash theme={null} $ kubectl describe deploy web-app spec.replicas 3 status.readyReplicas 2 conditions Available=False events ScalingReplicaSet ``` This lesson upgrades the WebApp API so it moves from silent creation to visible operation. The controller will populate `status` with facts it observes from the cluster — for example, how many pods are ready behind the Deployment — and will also publish conditions and events so users get immediate, actionable feedback. The image illustrates a two-step process for custom resources: "Silent creation," which builds and says nothing, followed by "Visible operation," which reports what it sees.

The image illustrates a two-step process for custom resources: "Silent creation," which builds and says nothing, followed by "Visible operation," which reports what it sees.

Spec is an input: it declares what the user asked for. Status is observational: it reports what the controller has seen. Conditions attach structured names, statuses, and reasons to that observation so humans and other controllers can quickly assess health and progress. Treat `spec` as the desired state (user intent) and `status` as the controller's observed facts. Conditions are a concise, machine-readable summary of that observed state. Conditions let the controller communicate higher-level health states directly instead of forcing users to infer them from raw numbers. For a WebApp you might expose types such as Ready, Progressing, and Degraded with `True`/`False` statuses and machine-friendly `reason` and `message` fields. That creates a compact health report other tools can read without scraping logs. The image displays a table of conditions with types (Ready, Progressing, Degraded), statuses (True, False), and corresponding reasons.

The image displays a table of conditions with types (Ready, Progressing, Degraded), statuses (True, False), and corresponding reasons.

Events add short-lived contextual information. When the controller creates a child object, encounters unexpected input, or reaches an operational milestone, emitting an Event makes that action visible through `kubectl describe`. Logs remain essential for deep debugging, but Events surface the most relevant actions to resource owners. Requeue behavior completes the observable story: the reconcile loop should make explicit decisions about whether to * check again after a delay, * return an error (so controller-runtime retries), or * stop cleanly because the current state already matches the desired state. Explicit requeue decisions ensure status updates and events reflect intentional controller behavior rather than accidental timing. The image describes three types of deliberate reconcile decisions: "Check again" (re-run after a delay), "Return error" (controller-runtime retries), and "Stop cleanly" (state is already correct) in a reconcile loop.

The image describes three types of deliberate reconcile decisions: "Check again" (re-run after a delay), "Return error" (controller-runtime retries), and "Stop cleanly" (state is already correct) in a reconcile loop.

Summary of what this section adds to the WebApp controller: | Feature | Where recorded | Example / purpose | | ----------------------- | ---------------------- | ------------------------------------------------------------------------ | | Observed replica counts | `status.readyReplicas` | Show how many pods are actually ready | | Structured readiness | `status.conditions[]` | `Type=Ready/Progressing/Degraded`, with `Status`, `Reason`, `Message` | | User-visible timeline | Events | Short-lived notes that appear in `kubectl describe` | | Intentional retries | Requeue decisions | `RequeueAfter`, return error, or no requeue to reflect controller intent | By the end of this section, the WebApp controller will still create and manage child resources, but it will also explain what it sees and why it made particular reconcile decisions — directly where users look for that information.

Links and references * Kubernetes API conventions for `status` and `conditions`: [https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) * Best practices for kubectl and resource visibility: [https://kubernetes.io/docs/reference/kubectl/overview/](https://kubernetes.io/docs/reference/kubectl/overview/)