第2周：操作系统与虚拟化

本日概要

从一次程序运行建立操作系统资源链：程序装入后成为进程，进程拥有虚拟地址空间与文件描述符表，线程共享进程资源但各自保留执行上下文；调度器让可运行任务竞争 CPU，虚拟内存通过页表提供地址转换、保护与受控共享，VFS 把不同文件系统统一到 open/read/write 等接口，阻塞与非阻塞 I/O 则决定调用者等待数据时如何继续工作。今天不把 top 中的一个高数值直接当作故障，而是结合时间窗、进程状态和证据解释现象。

学习目标

• 能区分程序、进程与线程，并说明资源所有权和执行上下文的差别
• 能解释虚拟地址、页表、页缓存、匿名内存与物理内存之间的关系
• 能沿文件描述符、VFS、页缓存与设备说明一次文件 I/O 的基本路径
• 能用带时间戳的命令输出支持判断，而不是把单次资源快照当成因果结论

核心讲解

实践任务

在 Linux 学习环境中启动一个受控 CPU 任务，使用 ps、top、free 与 /proc 观察进程、线程、内存和文件描述符，并保存前后对照。

• 实验边界——平台：Ubuntu/Debian/Fedora 等 Linux；权限：普通用户，仅观察本人进程；安全：不用 sudo、sysctl 或写 /proc，kill 仅作用于本步记录的 PID；清理：结束自己启动的 yes 进程并删除临时日志。
• 运行 `yes > /dev/null & lab_pid=$!`，立即记录 PID；用 `ps -o pid,ppid,stat,%cpu,%mem,nlwp,comm -p "$lab_pid"` 和 `ps -L -p "$lab_pid"` 保存进程与线程快照。
• 运行 `free -h`、`cat /proc/$lab_pid/status` 与 `ls -l /proc/$lab_pid/fd`，把虚拟内存、驻留集、线程数和文件描述符分别映射到今天的概念图。
• 执行 `kill "$lab_pid"` 后用 `wait "$lab_pid" 2>/dev/null || true` 回收子进程；再次运行 ps 与 free，记录哪些指标变化、哪些不能由单次实验推出因果。

自测与答案

今日完成标准

• 提交含平台、时间、命令和前中后输出的实验记录，所有 PID 均来自本人启动的进程
• 概念图正确连接进程、线程、虚拟内存、页缓存、文件描述符、VFS 与 I/O
• 至少写出一条由证据支持的观察和一条当前实验不能证明的推断

常见错误与纠正提示

• 把进程等同于程序文件，或认为同一进程内线程拥有彼此完全隔离的地址空间
• 看到缓存占用就判断内存泄漏，忽略页缓存可回收性、时间趋势和工作负载
• 把一次 top 快照当作性能结论，没有记录命令、时间、平台与实验边界

分层任务

关联知识点

• 操作系统

延伸阅读

• Linux Kernel：Memory Management Concepts（Linux 内核官方文档）
• Linux Kernel：Virtual File System（Linux 内核官方文档）

本日概要

把 Linux 运维任务拆成路径、身份、进程和日志四条线：文件系统层级说明数据放在哪里，用户/组与 rwx 权限决定谁能对目录项和文件做什么，Shell 脚本把可重复观察固化为带错误处理的步骤，systemd 单元描述服务的启动条件与生命周期，journal 则提供按单元、启动批次和时间过滤的日志。练习只读取本机状态并写入个人临时目录，不修改系统服务或全局权限。

学习目标

• 能用 /etc、/var、/run、/tmp 与个人目录的职责解释文件放置选择
• 能根据所有者、组、其他用户与目录执行位判断最小必要权限
• 能编写带严格模式、参数校验和引用变量的只读 Shell 监控脚本
• 能区分 systemd 单元状态与 journal 日志证据，并记录命令失败信息

核心讲解

实践任务

编写只读监控脚本，采集时间、负载、内存、磁盘与指定用户服务日志，并证明脚本在失败路径也返回明确状态。

• 实验边界——平台：采用 systemd 的 Linux 发行版；权限：普通用户，不用 sudo；安全：只读采集且临时目录权限设为 700；清理：退出后删除 `mktemp -d` 返回的本人目录。
• 用 `lab_dir=$(mktemp -d)`、`stat -c '%A %U %G %n' "$lab_dir"` 建立安全工作区；创建 `monitor.sh`，写入时间、`uname -sr`、`uptime`、`free -h` 与 `df -h "$HOME"` 的输出。
• 为脚本加入 `#!/usr/bin/env bash`、`set -eu`、输出路径参数检查与双引号；执行 `bash "$lab_dir/monitor.sh" "$lab_dir/report.txt"`，保存退出码并检查报告非空。
• 运行 `systemctl --user --no-pager --failed` 与 `journalctl --user -n 20 --no-pager`；若用户实例不可用，如实保存错误而不切换 root；最后运行 `rm -rf -- "$lab_dir"`，先核对变量非空且路径来自本步 mktemp。

自测与答案

今日完成标准

• 脚本可由普通用户在临时目录重复运行，成功和失败路径都有退出码且变量引用安全
• 报告包含平台、时间、命令、负载、内存、磁盘和用户级服务/日志证据
• 清理记录证明只删除本人实验目录，未修改系统服务、/etc 或全局权限

常见错误与纠正提示

• 为绕过权限错误直接 chmod 777 或 sudo 执行未知脚本，没有确认对象和恢复方法
• Shell 变量不加双引号，文件名含空格或通配字符时处理了错误目标
• 只抄 systemctl 的 active/failed 标签，不保留 journal 时间窗、退出码和失败上下文

分层任务

关联知识点

• 操作系统

延伸阅读

• systemd：systemctl（systemd 官方手册）
• systemd：journalctl（systemd 官方手册）
• GNU Bash Manual（GNU Bash 官方手册）

本日概要

用分层和时间线排查“服务访问失败”：先确认进程是否存在及监听地址，再确认本机连接、名称解析与路由，然后查看应用/系统日志，最后用 strace 在授权进程上观察系统调用。ss 展示套接字，ip 展示地址与路由，journalctl 关联日志，strace 揭示应用和内核接口；每个工具只回答一类问题。防火墙是潜在环节，但本日不改 iptables/firewalld 规则，以免中断主机或远程连接。

学习目标

• 能按进程—监听—名称/路由—连接—日志顺序缩小网络故障范围
• 能解释 127.0.0.1 与 0.0.0.0 监听边界以及 TCP 连接状态的含义
• 能在授权范围内使用 ss、curl、journalctl 和 strace 留存排障证据
• 能把观察、假设、验证动作和结论分栏，避免凭单个错误码猜测

核心讲解

实践任务

启动仅绑定 127.0.0.1 的临时 HTTP 服务，制造错误端口，从监听、连接、日志和系统调用四层定位并清理。

• 实验边界——平台：Linux，需 Python 3、ss、curl，可选 strace；权限：普通用户且仅跟踪本人进程；安全：只绑定 127.0.0.1，不扫描外网、不改防火墙；清理：终止临时服务并删除日志。
• 运行 `python3 -m http.server 8765 --bind 127.0.0.1 >week2-http.log 2>&1 & server_pid=$!`，用 `ss -ltnp | grep 8765` 证明监听地址，并记录 PID 与时间。
• 先执行 `curl -v --max-time 3 http://127.0.0.1:8766/` 制造错误端口，再访问 8765；对比退出码、ss 输出和 `ip route get 127.0.0.1`，写出假设如何被排除。
• 若安装 strace，运行 `strace -f -e trace=network -p "$server_pid" -o week2-strace.log` 并发起一次请求后停止跟踪；执行 `kill "$server_pid"`、`wait "$server_pid" 2>/dev/null || true`，脱敏后删除两份日志。

自测与答案

今日完成标准

• 排障记录按进程、监听、连接、日志、系统调用分层，至少包含一组失败/成功对照
• 全部命令标明平台与权限，未改防火墙且未访问未授权目标
• 临时服务已终止、敏感输出已脱敏、实验日志按清单处理

常见错误与纠正提示

• 看到 0.0.0.0 监听就宣布公网可达，忽略地址、路由、防火墙和上游网络
• 未保存监听与日志证据就修改 iptables/firewalld，既扩大故障又失去第一现场
• 对不属于自己的进程使用 strace，或提交包含令牌、路径和业务数据的原始跟踪

分层任务

关联知识点

• 网络技术

延伸阅读

• strace 官方站点与手册入口（strace 项目官方站点）
• systemd：journalctl（systemd 官方手册）

本日概要

虚拟机以虚拟 CPU、内存、块设备和网络设备提供接近完整计算机的边界，来宾运行自己的内核。Type 1/Type 2 是理解部署位置的教学分类，不能替代对实际数据路径和权限的分析。Linux KVM 提供内核虚拟化接口，QEMU 提供机器与设备模型并可结合硬件加速；qcow2 支持稀疏分配与写时复制，但快照不是独立备份。今天先核验主机能力，再对学习者自有磁盘镜像做创建、检查和清理。

学习目标

• 能区分虚拟机来宾内核、VMM/Hypervisor、主机内核与硬件职责
• 能解释 KVM 与 QEMU 的协作关系以及硬件加速不可用时的影响
• 能区分快照、克隆和备份，说明写时复制链对恢复与删除顺序的约束
• 能记录 CPU、内存、磁盘、网络和时间条件，形成可复核 VM 实验边界

核心讲解

实践任务

检查 /dev/kvm 与 QEMU 能力，创建小型 qcow2 实验盘，记录稀疏文件证据并设计虚拟机快照恢复验证。

• 实验边界——平台：x86_64 Linux 主机，安装 qemu-img；本步骤的 `qemu-system-x86_64` 探针不适用于 AArch64/ARM 主机，其他架构应改用对应的 QEMU system binary 并在记录中注明；权限：普通用户读取 /dev/kvm 权限并只操作本人目录；安全：不用系统 VM 或未知镜像；清理：仅删除本次创建的 qcow2 文件和临时目录。
• 在 x86_64 Linux 上运行 `uname -m`、`test -e /dev/kvm && ls -l /dev/kvm || printf 'KVM device unavailable\n'`、`qemu-system-x86_64 --version`（若已安装）与 `qemu-img --version`；若 `uname -m` 不是 x86_64，停止这条探针并选择与主机/来宾架构相符的 QEMU binary，如实记录不可用项，不用 sudo 改设备权限。
• 用 `lab_dir=$(mktemp -d)` 和 `qemu-img create -f qcow2 "$lab_dir/week2.qcow2" 2G` 创建实验盘；比较 `qemu-img info "$lab_dir/week2.qcow2"`、`ls -lh` 与 `du -h` 的逻辑/实际占用。
• 画出基础镜像—快照/增量—来宾写入关系和恢复检查表；确认 `lab_dir` 是本步创建且只含实验盘后执行 `rm -rf -- "$lab_dir"`，保存清理前后的目录证据。

自测与答案

今日完成标准

• 层次图准确区分主机、KVM、QEMU、虚拟设备、来宾内核和应用
• 实验记录含版本、/dev/kvm 结果、镜像格式、逻辑/实际占用及命令退出状态
• 能够说明快照限制并证明只清理本人创建的实验镜像

常见错误与纠正提示

• 把 KVM、QEMU 和虚拟机当作同一层组件，无法说明内核接口与设备模型职责
• 把快照称为备份，忽略基础镜像链、宿主故障域和恢复演练
• 为访问 /dev/kvm 随意 chmod 或 sudo，扩大主机虚拟化管理权限

分层任务

关联知识点

• 云计算

延伸阅读

• Linux Kernel：KVM（Linux 内核官方文档）
• QEMU System Emulation Introduction（QEMU 项目官方文档）
• QEMU Disk Image Utility（QEMU 项目官方文档）

本日概要

容器把一个或多个进程放进 Linux 命名空间（namespaces）、cgroups 和文件系统层所形成的受限视图中，仍与主机共享内核；镜像是不可变内容与配置的分层制品，容器是在其上增加可写层的运行实例，仓库存储和分发镜像。Dockerfile 描述构建步骤，但可复现性还取决于固定基础镜像标识、构建上下文、依赖和架构。Docker daemon 或 docker 组通常拥有高权限，练习使用 Docker Desktop 或 rootless 环境并限制端口、挂载与清理目标。

学习目标

• 能区分镜像、容器、仓库、Dockerfile 与构建上下文的职责
• 能解释容器共享主机内核以及 namespaces/cgroups 提供的隔离边界
• 能构建、运行、检查并精确清理一个仅绑定回环地址的容器
• 能记录镜像 ID/digest、平台、命令和限制，避免把能运行等同于安全或可复现

核心讲解

实践任务

构建只含静态页面的 Nginx 镜像，运行到回环端口，检查镜像层、容器进程与挂载后完成精确清理。

• 实验边界——平台：Linux rootless Docker 或 macOS/Windows Docker Desktop；权限：当前用户的 Docker 权限，不用特权容器；安全：只绑定 127.0.0.1 且不挂载敏感目录；清理：只删除同时匹配本次记录 ID 与 `aiknow.exercise` 归属标签的对象，禁用全局 prune。
• 在 `lab_dir=$(mktemp -d)` 工作区创建 `index.html`、`.dockerignore` 与 Dockerfile，再令 `lab_token=$(basename "$lab_dir" | tr -cd '[:alnum:]' | tr '[:upper:]' '[:lower:]')`、`image_ref="aiknow-week2-static:lab-$lab_token"`、`container_name="aiknow-week2-static-$lab_token"`；使用官方 nginx:alpine 基础镜像并记录 `docker version` 与基础镜像解析结果。
• 先分别用 `docker image inspect "$image_ref"` 与 `docker container inspect "$container_name"` 做碰撞检查：任一对象已存在就报告“创建失败：名称已被占用”并停止，绝不清理既有资源。检查通过后执行 `docker build --label "aiknow.exercise=$lab_token" -t "$image_ref" .`，成功后保存 `image_id=$(docker image inspect --format '{{.Id}}' "$image_ref")`；再执行 `container_id=$(docker run -d --label "aiknow.exercise=$lab_token" --name "$container_name" -p 127.0.0.1::80 --read-only --tmpfs /var/cache/nginx --tmpfs /var/run "$image_ref")`，用 `docker port "$container_id" 80`、curl 和 inspect 保存证据。只有命令成功且变量非空才登记为本练习所创建；创建失败不得触发对同名既有对象的删除。
• 清理前分别核对当前容器/镜像的完整 ID 等于记录的 `container_id`/`image_id`；再运行 `docker container inspect --format '{{ index .Config.Labels "aiknow.exercise" }}' "$container_id"` 和 `docker image inspect --format '{{ index .Config.Labels "aiknow.exercise" }}' "$image_ref"`，两项都必须返回 `lab_token`。任一对象参数、ID 或归属标签不匹配就停止并报告，不删除。全部通过后才按记录 ID 执行 `docker rm -f "$container_id"`，再按本次唯一标签执行 `docker image rm "$image_ref"`；确认对象消失后删除本次 `lab_dir`，不删除基础镜像或他人资源。

自测与答案

今日完成标准

• 静态镜像可在指定平台构建，容器只绑定回环地址且 curl 返回预期页面
• 记录包含 Docker 版本、Dockerfile、基础镜像身份、镜像/容器 ID 和隔离限制
• 清理记录证明容器/镜像 ID 与归属标签均匹配本次 lab_token；碰撞或创建失败时没有删除既有资源，也没有执行全局 prune

常见错误与纠正提示

• 把镜像与运行中的容器混为一谈，或认为容器拥有独立内核
• 把密钥复制进构建上下文或镜像层，事后删除文件却仍留在历史层
• 使用固定共享名称、--privileged、宿主根目录挂载或 docker system prune 完成基础练习

分层任务

关联知识点

• 云计算

延伸阅读

• Docker Docs：Writing a Dockerfile（Docker 官方文档）
• Docker Engine Security（Docker 官方文档）

本日概要

Docker Compose 用一份声明式 YAML 描述本机多容器应用的服务、网络、卷和依赖；Kubernetes 将目标状态进一步组织为 Pod、Deployment 与 Service：Pod 是最小可部署单元并共享部分网络/存储上下文，Deployment 管理副本与滚动更新，Service 为动态 Pod 集合提供稳定网络抽象。二者都不自动解决数据备份、密钥管理和应用就绪性，入门练习以配置校验和受控本地部署为主。

学习目标

• 能说明 Dockerfile 与 Compose 文件分别描述构建制品和运行拓扑
• 能区分 Kubernetes Pod、Deployment 与 Service 的职责和生命周期
• 能用 config/dry-run 在创建资源前发现语法与默认值问题
• 能为多容器练习记录镜像身份、网络、数据边界、验证和完整清理步骤

核心讲解

实践任务

用 Compose 启动一个只绑定回环端口的前端服务并验证/清理，再用 kubectl 客户端 dry-run 生成 Deployment 与 Service 清单。

• 实验边界——平台：Docker Compose v2；kubectl 可选且只做 client dry-run；权限：普通 Docker 用户，无集群管理员权限；安全：回环随机端口、无真实密钥；清理：只对 ID 清单和 `com.docker.compose.project` 归属标签都匹配的本次项目执行 down，不删除卷。
• 创建只含 `web` 服务的 compose.yaml，使用 nginx:alpine、端口 `127.0.0.1::80` 和只读运行设置；令 `lab_dir=$(mktemp -d)`、`lab_token=$(basename "$lab_dir" | tr -cd '[:alnum:]' | tr '[:upper:]' '[:lower:]')`、`project_name="aiknow-week2-$lab_token"`，再执行 `docker compose -p "$project_name" config` 检查最终端口、镜像和卷。
• 启动前分别列出带 `com.docker.compose.project=$project_name` 归属标签的容器、网络和卷；任一已存在就报告“创建失败：项目资源已存在”并停止，绝不执行 down。检查通过后执行 `docker compose -p "$project_name" up -d`；仅在成功后保存包含容器和项目网络完整 ID 的 `project_ids`，再用 `docker compose -p "$project_name" ps`、`docker compose -p "$project_name" port web 80` 与 curl 留证。
• 清理前重列项目容器/网络，确认每个当前 ID 都在 `project_ids` 中且每项 `com.docker.compose.project` 归属标签都精确等于 `project_name`；创建失败、出现额外 ID 或标签不符时停止并报告，不执行清理。核验通过后只运行 `docker compose -p "$project_name" down --remove-orphans`。本练习不声明卷，因此不使用 `--volumes`；若扩展出卷，须单独记录卷 ID 和所有权标签，并只按已核验的精确 ID 删除。
• 如已安装 kubectl，运行 `kubectl create deployment week2-web --image=nginx:alpine --dry-run=client -o yaml` 和 `kubectl create service clusterip week2-web --tcp=80:80 --dry-run=client -o yaml`；检查 Deployment 标签与 Service selector，不执行 apply。

自测与答案

今日完成标准

• Compose 配置可解析、服务可从回环地址访问，镜像与项目身份均有记录
• 能准确解释 Pod、Deployment、Service 和 selector 关系及 client dry-run 的证据边界
• 项目容器、网络和实验卷按清单清理，无真实凭据和共享集群变更

常见错误与纠正提示

• 把 Dockerfile 当运行多个服务的拓扑文件，或把 Compose 当镜像构建格式
• 认为 depends_on 等同于业务就绪，忽略健康检查、重试与失败传播
• 把 Pod、Deployment、Service 混为同一对象，或在共享集群直接使用 default namespace 和管理员凭据

分层任务

关联知识点

• 云计算

延伸阅读

• Docker Compose Quickstart（Docker 官方文档）
• Kubernetes Pods（Kubernetes 官方文档）
• Kubernetes Deployments（Kubernetes 官方文档）
• Kubernetes Services（Kubernetes 官方文档）

本日概要

把本周知识收束为同一工作负载的三种边界：裸机/主机直接进程使用主机内核与硬件，虚拟机通过 KVM/QEMU 等栈获得虚拟硬件并运行独立来宾内核，容器把进程置于 namespaces/cgroups 与分层文件系统中而共享主机内核。比较必须固定任务、输入、CPU/内存限制、版本、测量方法与重复次数，同时观察启动、资源、隔离、可移植性、运维和清理；不能用一次更快的结果宣布某种形态普遍优胜。

学习目标

• 能沿硬件、内核、进程、文件与网络层比较裸机、虚拟机和容器
• 能设计同输入、同测量口径且重复执行的三环境实验，并识别不可控变量
• 能用命令输出、版本、时间和官方来源支持结论，区分观察与推断
• 能从隔离、性能、可移植性和运维成本反思技术选择而非寻找万能赢家

核心讲解

实践任务

完成“VM、容器与裸机可复现实验”草稿，用同一只读任务比较三种环境，提交证据、隔离矩阵、来源与反思。

• 实验边界——平台：授权物理 Linux、其上的学习 VM 与 rootless Docker/桌面容器；权限：普通用户操作本人资源；安全：只读 CPU/文件任务、无公网暴露；清理：逐环境按资源清单停止并删除实验项。
• 建立环境清单：运行并记录 `uname -a`、`systemd-detect-virt || true`、CPU/内存限制与工具版本；只有 systemd-detect-virt 和资产记录均支持时才把物理主机标为裸机。
• 在三种环境运行同一固定输入的校验/压缩或教师脚本，各重复至少三次；记录冷/热条件、耗时、最大内存、退出码和原始输出，不跨口径计算所谓加速比。
• 完成内核、PID、文件、网络、资源、管理面六维隔离矩阵与来源映射；停止 VM、删除本人容器/镜像/临时文件，保留清理后检查和限制反思。

自测与答案

今日完成标准

• 三环境身份、版本、资源与虚拟化层次均有证据，未把虚拟主机伪标为裸机
• 同一任务至少三次重复，原始输出、时间口径、异常和不可比项完整保留
• 六维隔离矩阵、官方来源与实际访问日期、清理记录和反思均可由同伴复核

常见错误与纠正提示

• 把运行在云 VM 或桌面虚拟化中的主机误标为裸机，隐藏真实环境层次
• 只运行一次或混用冷启动、热缓存和不同资源限制，仍给出普遍性能排名
• 把隔离写成产品标签，不检查内核、权限、挂载、网络和管理面配置

分层任务

关联知识点

• 操作系统
• 云计算

延伸阅读

• Linux Kernel：KVM（Linux 内核官方文档）
• Docker Engine Security（Docker 官方文档）
• Kubernetes Pods（Kubernetes 官方文档）