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.
What a learner can do afterwards
- 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
1 · Read
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.
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.
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.
Both readings and the flashcards were written for this dataset. Textbook question records were consulted for topic selection; no imported textbook wording is retained.
More to read
An image and a service boundary
Packaging and application architecture answer different questions. An image packages an application and its user-space dependencies. A service boundary divides the application into units that communicate with one another.
In the Linux container model, the application uses the host kernel. Namespaces isolate selected process, file and network views. Resource controls can limit resource use. The container does not receive its own physical server or a separate kernel. Running the image elsewhere still requires a compatible CPU, kernel and runtime.
A monolith deploys as one application unit and can run in a container. Microservices deploy as separate networked services and can use containers too. Separating services can allow separate releases when contracts and release processes support them. It also adds communication and partial-failure concerns.
When reviewing a design, identify its deployment units first. Then check what each image needs from its host. Neither the number of code files nor the presence of a container establishes that services can deploy independently.
From a missing replica to a ready process
Suppose a controller wants six managed replica objects. After failure cleanup, four exist and no creation is pending. With no concurrent changes, the observed shortfall is two. Requesting two objects is one part of recovery; getting their processes ready requires further work.
The scheduler checks resource requests and placement rules. A workload can stay pending when no node qualifies. Once assigned, its containers must start through the node's runtime. An unavailable image or failed dependency can still prevent readiness. Count existing managed objects, including those not yet ready, rather than replacing every process that is not serving traffic.
Retries need care too. A creation can succeed while its success response is lost. Checking the requested object's stable identity can reveal that it already exists. Creating a new object under a different name could duplicate the successful work. Concurrent changes can also make an earlier count stale, so the controller must recheck state and handle conflicts.
A standing desired-state target supports later repair decisions. It does not supply missing capacity, repair every configuration problem or promise that users see no interruption.
2 · Watch
به انگلیسیTake it off screen
Where it sits
Learn first
Nothing; this is a starting point.
Optional connections
This opens up
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.