--- title: "Cloud-Native Architecture: Containers, Schedulers and the Control Loop" description: "Containers package applications and isolate selected process views while sharing a kernel. A scheduler places new workloads on eligible machines. Controllers repeatedly compare desired and observed st" canonical: https://lightmysky.com/learn/computing/cloud-native-architecture-containers-schedulers-and-the-control-loop-mt_nV1LgSRsh_ source: https://lightmysky.com/learn/computing/cloud-native-architecture-containers-schedulers-and-the-control-loop-mt_nV1LgSRsh_.md retrieved: 2026-11-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # Cloud-Native Architecture: Containers, Schedulers and the Control Loop Containers package applications and isolate selected process views while sharing a kernel. A scheduler places new workloads on eligible machines. Controllers repeatedly compare desired and observed state and request changes. Recovery still depends on capacity, valid configuration and working software. Subject: Computing · Area: Computer Systems · Ages 23 to 24 Page: https://lightmysky.com/learn/computing/cloud-native-architecture-containers-schedulers-and-the-control-loop-mt_nV1LgSRsh_ ## Ready when they can - Explain what Linux containers isolate, what they share and what limits image portability - Describe reconciliation and explain why retries must check existing objects and concurrent changes - Compare a standing desired-state target with a one-time command list and identify conditions that can block recovery ## Lesson: Declare the state, let the loop converge The journal model addresses stored metadata after a crash. Here recovery concerns running workloads. Microservices divide an application into separately deployed services that communicate over a network. A monolith deploys as one application unit, even if it contains many modules. Either design can run in containers in the cloud. Separate deployment needs suitable release processes and compatible service contracts; small services do not automatically make an application available. An image packages an application and its user-space dependencies. In the Linux container model here, namespaces isolate selected process, file and network views. Resource controls can limit resource use. Containers share the host kernel; they do not each get their own kernel. An image still needs a compatible CPU, kernel and container runtime. A node is a machine available to run workloads. A scheduler assigns a pending workload to a node that meets its resource requests and placement rules. If no node qualifies, it can remain pending. The node's runtime starts assigned containers. Assignment is not migration of a running process. A scheduler need not rebalance running workloads whenever load changes. **Example.** A replica is a managed copy of a workload. After failure cleanup, a controller sees 1 managed replica object against a target of 4, with no creation pending. It requests 3 more objects. Scheduling and startup follow. Count existing objects, including ones not yet ready, rather than only serving processes. Capacity, placement rules, image errors or failed dependencies can block readiness. Replacement can take time and does not promise uninterrupted service. Reconciliation compares desired and observed state and requests needed changes. A new pass alone is no reason to add a replica when its count matches the target. A creation can succeed even if its response is lost. Retry using the object's stable identity and check whether it already exists. Concurrent changes can make an earlier count stale, so recheck state and handle conflicts rather than blindly creating more copies. Desired state is a standing target. After a failure, the controller can inspect current state and choose the changes still needed. A one-time command list alone does not keep checking for later drift. This makes declarative control useful for ongoing repair, but it cannot make every target reachable. Operators may still need to investigate blocked recovery. *(drawing: Each pass uses current evidence. A repeated creation must not duplicate an object that already exists.)* **Recap.** Containers share a compatible host kernel. Controllers request changes, schedulers place workloads and runtimes start them. Check existing state on retries; recovery can remain blocked. *Original lesson, questions, worked solutions and flashcards written for this dataset. Textbook question records informed assessment design; their wording is not reproduced.* ## Practice 8 questions on this page, each with its working shown. ## Optional connections - [Software Architecture: Layers, Services and Their Trade-offs](https://lightmysky.com/learn/computing/software-architecture-layers-services-and-their-trade-offs-mt_uz_OkFgysJ) - [Continuous Integration and the Build Pipeline](https://lightmysky.com/learn/computing/continuous-integration-and-the-build-pipeline-mt_z__G4nfjwh) ## Opens up - [Observability and Tail Latency Across Services](https://lightmysky.com/learn/computing/observability-and-tail-latency-across-services-mt_NT5tmumdfA)