Linux 与容器基础

本质区别：虚拟机通过 hypervisor 模拟硬件，每个 VM 有独立内核，Guest OS 和 Host OS 完全隔离；容器共享宿主机内核，隔离全部靠 Linux 内核机制（namespace+cgroups）。VM 是"硬件级隔离"，容器是"进程级隔离"。安全风险：容器隔离比 VM 弱——容器内进程直接与宿主机内核交互，内核漏洞可以逃逸；User namespace 将容器 root 映射为宿主机非特权用户可以降低风险，但默认 Docker 没开启 user namespace。生产环境多租户场景建议用 Kata Containers（轻量 VM+容器接口）或 gVisor（用户态内核）增强隔离。

--cpus=2 是硬限制，通过 CFS（Completely Fair Scheduler）带宽控制实现：设置 cpu.cfs_quota_us 和 cpu.cfs_period_us（默认 100000us=100ms），--cpus=2 对应 quota=200000us，即每 100ms 周期内最多用 200ms CPU 时间（可在多核上并行）。--cpu-shares=512 是相对权重（默认 1024），只在 CPU 竞争时生效——CPU 充裕时不限制，多个容器争抢时按 shares 比例分配。面试重点：--cpus 限制上限（类似 K8s limits），cpu-shares 控制权重（类似 K8s requests 的相对优先级）。

排查：(1) dmesg | grep -i oom 看内核 OOM 日志；(2) kubectl describe pod 看 Last State 中 OOMKilled；(3) cat /sys/fs/cgroup/memory/docker-<id>/memory.oom_control 看 oom_kill 计数。防止：(1) 设置合理的 memory limit（-m），不要太小；(2) 优化应用内存使用，避免内存泄漏；(3) K8s 中设置 memory.limit_in_bytes 足够大并配置 readiness/liveness 探针；(4) 调 oom_score_adj（越低越不容易被 kill，-1000 禁止 kill，但慎用）；(5) 注意 Page Cache 会计入 cgroup memory，大文件读写会占用容器内存额度，必要时调低 vm.dirty_ratio 或定期 drop_caches。

containerd 是高层 runtime daemon，负责镜像拉取、content store、snapshot、容器元数据、task 生命周期和 CRI 服务。runc 是 OCI low-level runtime，负责根据 OCI spec 调 Linux kernel 创建容器。containerd-shim 位于 containerd 和容器进程之间，负责托管容器进程、转发 stdio、收集 exit status 和上报事件。

如果 containerd 直接成为所有容器进程的父进程，那么 containerd 重启或升级时会影响正在运行的容器。shim 把容器进程和 containerd daemon 解耦：containerd 可以重启，shim 继续托管容器；shim 还负责保留 stdio、等待容器退出、收集 exit code、上报事件和清理资源。

Pod 不是一个容器，而是一组共享网络等 namespace 的容器。pause 容器是 Pod sandbox 的基础容器，它先启动并持有 Pod 的 network namespace、Pod IP 和部分共享 namespace。业务容器启动时加入这个 sandbox。这样业务容器重启时，Pod 的网络身份仍然可以保持稳定。

能。dockershim 移除的是 kubelet 内置的 Docker Engine 适配层，不是移除 Docker 镜像格式。只要镜像符合 OCI / Docker image spec，containerd 和 CRI-O 都能拉取和运行。变化在节点链路：以前是 kubelet → dockershim → Docker Engine → containerd，现在是 kubelet → CRI → containerd。

先看 Pod Events 里的错误类型：镜像名/tag 是否存在，registry 是否可达，imagePullSecret 是否正确，节点 DNS/代理/证书是否正常，是否触发 registry rate limit。然后到节点侧用 crictl pull 复现，用 journalctl -u containerd 看 runtime 具体错误。

kubectl describe pod  -n 
kubectl get secret -n 
crictl pull 
journalctl -u containerd -n 200

ContainerCreating 表示 Pod 已经调度到节点，但节点侧执行还没完成。排查顺序是 Events、kubelet 日志、containerd 日志、CNI 日志/配置、CSI mount、镜像拉取和 sandbox 创建。常见原因包括 CNI 分配 IP 失败、CSI 挂载超时、sandbox 创建失败、镜像拉取慢、节点磁盘压力。

镜像由多层只读 layer 组成，containerd 把这些 layer 存在 content store 中。启动容器时，snapshotter 会基于这些只读层准备 rootfs，并给容器加一个可写层。overlayfs 常用于把多个只读 lowerdir 和一个 writable upperdir 合成一个统一视图。容器内写文件时触发 copy-on-write，不会修改原始镜像层。

Kubernetes 的 requests 主要用于调度，limits 会通过 kubelet / runtime 写到 cgroup。CPU limit 常体现为 CFS quota，内存 limit 体现为 cgroup memory 上限，超过可能触发容器 OOMKilled。GPU 这类设备资源通常通过 device plugin 注入设备文件、环境变量或 runtime hook；GPU 显存本身不一定被 cgroup 原生限制，需要厂商 runtime 或平台策略配合。