Chapter 8 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Processors and memory"]
N2["8.2 Memory and isolation"]
N3["8.3 Storage hierarchy"]
N4["8.5 Architecture and responsibility"]
N5["8.6 Measuring"]
N6["Node images"]
N7["Dedicated hosts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Processors and memory"]
N2["8.2 Memory and isolation"]
N3["8.3 Storage hierarchy"]
N4["8.5 Architecture and responsibility"]
N5["8.6 Measuring"]
N6["Node images"]
N7["Dedicated hosts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Processors and memory]
|
v
[8.2 Memory and isolation]
|
v
[8.3 Storage hierarchy]
|
v
[8.5 Architecture and responsibility]
|
v
[8.6 Measuring]
|
v
[Node images]
|
v
[Dedicated hosts]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) describe CPUs, memory and storage as they appear in virtual machines and containers; (2) understand virtualisation's hardware support; (3) relate architecture to isolation; (4) reason about resource limits.
8.1 Processors and memory
Virtual machines run on physical CPUs with hardware virtualisation support, which lets a hypervisor isolate guests. Containers share the host kernel and are isolated by kernel features instead.
Hardware virtualisation gives each guest its own virtual processors and memory, with the hypervisor enforcing boundaries. Containers are lighter because they share one kernel, but that also means a kernel flaw can affect every container on the host. For meterhub, the choice affects how strongly workloads from different teams are separated on the same node.
8.2 Memory and isolation
Each process has its own virtual address space. Hardware memory management enforces separation; flaws in this area, such as speculative execution issues, are why providers patch hosts and why sensitive workloads may use dedicated hosts.
Speculative execution flaws showed that even hardware-enforced separation can leak information through subtle timing effects. Providers responded with microcode updates, kernel patches and options for dedicated hosts. Customers handling highly sensitive data can choose such hosts to avoid sharing hardware with unknown tenants, at higher cost.
8.3 Storage hierarchy
Caches, memory, local disks and network storage differ in speed by orders of magnitude. meterhub keeps recent readings in memory and older ones on network storage.
Memory is thousands of times faster than network storage, so keeping the most recent readings there lets dashboards respond quickly. Older readings are needed less often and can tolerate slower access. Choosing what lives where balances speed against cost, and the boundary moves as usage patterns change. Elena checks how often older readings are actually requested before moving the boundary.
8.4 Resource limits
Kubernetes requests and limits map to kernel controls (cgroups) on CPU time and memory. Without limits, one pod can starve others on the node, an availability risk.
A request tells the scheduler how much a pod needs; a limit caps what it may use. A pod with a memory leak and no limit could consume the node's memory, causing other pods to be killed. Setting limits keeps one faulty workload from taking down its neighbours, which is a security concern as well as a reliability one.
8.5 Architecture and responsibility
The provider secures physical hardware and hypervisors; the customer chooses instance types, node images and pod settings.
The split is called the shared responsibility model. Solent cannot patch the provider's hypervisors, but it chooses node images and must keep them updated. Pod settings, such as running as non-root, are entirely Solent's responsibility. Knowing where the line falls prevents gaps where each side assumes the other is handling something. Elena lists each layer of meterhub with its owner in a single table, which Rosa's team reviews and keeps with the platform documentation.
8.6 Measuring
Node metrics show CPU, memory and I/O pressure, which help size limits correctly.
Without measurements, limits are guesses: too low and pods are throttled or killed, too high and nodes are underused. Watching metrics over a week of normal use, including evening peaks, shows how much each pod actually needs. Elena sets limits at the observed peak plus a margin, and reviews them as load grows. Throttling events are watched too, since they show a limit set too low even when averages look fine.
Node images
Nodes run a minimal operating system image maintained by the provider. Elena checks that automatic node upgrades are enabled, since kernel fixes for isolation flaws arrive through those images.
Dedicated hosts
For the most sensitive workloads, providers offer dedicated hosts that are not shared with other customers. Solent decides meterhub does not need them, but records the reasoning.
Worked example
Elena finds that the 6 pods without limits from chapter 4 include a report generator that occasionally uses 12 GB of memory, evicting meterhub ingest pods on the same node. Setting a limit and moving reports to a separate node pool fixes the evictions.
Synthetic case. Figures are synthetic.
Errors and limits
Limits set too low cause their own failures; base them on measured use.
Exercises
- EX022 — VM vs container. How do VM and container isolation differ? Rubric: 3 = hypervisor vs shared kernel features; 2 = partial; 1 = vague; 0 = none.
- EX023 — Limits mechanism. What enforces pod limits? Rubric: 3 = cgroups; 2 = partial; 1 = vague; 0 = none.
- EX024 — Eviction fix. How were evictions fixed? Rubric: 3 = limit and separate node pool; 2 = partial; 1 = vague; 0 = none.
Synthesis
Architecture explains isolation and resource behaviour.
Continue studying — chapter 08 of 50
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →