DevOps 与云 面试题库

开发容器把容器镜像或 Compose 项目与开发期元数据组合起来，包括工作区挂载、远程用户、编辑器设置、端口转发、Feature 和生命周期命令。它面向编写、构建和调试代码，通常包含编译器、shell 与编辑器服务。生产镜像则是发布制品，需要更小的运行时攻击面、生产入口点，以及独立的秘密与部署控制。两者可以共享基础构建阶段和构建命令，但直接发布开发镜像，往往会把多余工具与权限带进生产环境。

镜像是不可变输入，由文件系统层与默认运行配置组成。创建容器时，引擎把镜像与命令、环境变量、网络、挂载、资源限制和可写层组合起来。多个容器可以共享同一镜像，删除容器不会删除镜像。容器被移除后，可写层中未挂载的数据会消失。命名卷由 Docker 独立管理，可以挂载到替换后的容器，因此适合持久数据。但持久化不等于备份；卷被删除、数据损坏或操作失误时，仍要依靠经过验证的备份与恢复流程。

WebAssembly 容器通常是通过 OCI 工具分发，并由接入容器栈的 Wasm 运行时执行的模块或组件。它复用注册表、摘要、Pod 与部署控制器，但不代表其中存在 Linux 用户空间或原生进程。宿主访问来自显式提供的导入，例如 WASI 接口。Linux 容器则运行面向内核 ABI 的原生二进制，主要依靠 namespace、cgroup 与安全策略隔离。应用需要任意系统调用、shell 工具、设备或尚未移植的原生库时，Wasm 不是直接替代品。

需要在源码所在宿主机上进行可重复准备时，使用 initializeCommand。首次创建时，容器内阶段依次是 onCreateCommand、updateContentCommand 和 postCreateCommand；新容器所需的安装应放在这里，如果连接必须等待后续阶段，再设置 waitFor。已有容器每次启动都会运行 postStartCommand，因此它应当快速且可重复。每次工具连接后都会运行 postAttachCommand，不应在其中修改共享项目状态。测试要覆盖首次创建、重启、重新连接和重建，因为这些路径执行的命令子集不同。

仓库控制的文件可能被支持工具执行。initializeCommand 在宿主机运行，生命周期脚本与 Feature 则会在创建或构建期间执行。绑定挂载可能暴露宿主机文件，转发的代理可能暴露凭据，Docker 套接字还可能让容器代码控制宿主机引擎。privileged 模式、设备与额外 capability 会进一步削弱隔离。打开不可信项目之前，应评审整个 .devcontainer 目录和 Feature 来源；默认使用非 root 用户、范围有限的只读挂载，不提供 Docker 套接字与无关凭据。

首先使用非 root 镜像用户、只读根文件系统、范围有限的挂载、明确的资源限制，以及工作负载必需的 capability 与设备。不要把 Docker 套接字或特权模式当作通用权限修复手段。只发布必要端口，并尽量明确宿主机绑定地址。使用 exec 形式的 ENTRYPOINT 或 CMD，让应用成为主进程并直接接收停止信号。随后测试最终镜像：检查实际用户和挂载，发送配置的停止信号，确认应用停止接收新工作、在有限时间内完成清理，并在引擎强制终止前退出。

应从完整输入图入手，而不是只看 devcontainer.json。需要精确内容时用摘要固定基础镜像，提交 Dev Container Feature 锁文件，并冻结语言依赖锁文件。还要审查 Dockerfile 使用的下载地址与操作系统软件源。CI 应记录 CLI 和容器引擎版本，因为实现差异与宿主机架构会影响结果。用冷缓存构建找出只存在于旧镜像层的依赖，再运行项目测试。版本固定应通过受审查的自动化流程更新，不能让可复现性无限期阻止安全修复。

用摘要固定基础镜像可以锁定所引用的清单，锁文件则约束语言依赖。缩小构建上下文、精确编写 COPY、执行冻结安装并记录构建参数，可以减少其他变化。但除非逐项控制，否则操作系统软件源、远程下载、秘密值、宿主机架构和构建器行为仍会漂移；多平台引用还会按平台选择不同清单。应定期进行冷缓存构建，因为热缓存可能掩盖未声明依赖。通过受审查的自动化更新固定项，再重新构建、扫描和测试；可复现的旧镜像仍可能包含已知漏洞。

Compose 通常把项目服务放在共享网络中，并按服务名提供 DNS，因此应用应通过 db:5432 访问数据库，而不是使用 localhost。只有宿主机或外部客户端需要连接时才发布端口；服务间流量留在项目网络中。数据库状态应放在命名卷或外部存储，而不是容器可写层。depends_on 只控制顺序，要等待就绪还需健康检查与 service_healthy 条件。先验证渲染后的配置，再启动服务栈并测试真实连接，因为语法正确的 YAML 不能证明运行时已经就绪。

应从组件二进制而不是说明文档开始，检查其 world、导入、导出和固定的 WIT 版本。对每项导入，从运行时绑定追踪到宿主实现，再追踪到预打开目录、允许的 HTTP 主机、环境变量或秘密等具体资源。还要继续检查 Pod 卷、ServiceAccount 权限、网络策略和节点配置，因为 Wasm 沙箱位于这些控制之内。最后执行负向测试，尝试读取禁止路径、连接拒绝主机、请求缺失接口并耗尽执行预算，把实际拒绝结果和审计事件保存为部署证据。

应测试完整消费链。常规镜像可以把 .wasm 文件放入文件系统 tar 层，与更多现有注册表和镜像工具兼容，但入口路径与命令约定由 shim 决定。CNCF Wasm OCI Artifact 布局使用 application/vnd.wasm.config.v0+json 和 application/wasm，能直接描述 Wasm，却要求注册表、客户端、扫描器、containerd 与运行时都保留并支持这些媒体类型。无论选择哪种格式，都要重算全部描述符，按摘要部署，发布后重新拉取，并用生产环境完全相同的 containerd 与 shim 组合启动。

应按名称与边界顺序排查。先确认 pod.spec.runtimeClassName 等于某个现有 RuntimeClass 的 metadata.name，再检查其 handler 与调度约束。在合格节点上验证对应的 CRI 运行时配置、shim 二进制、引擎版本和服务重载状态。随后从事件中查找调度、认证、媒体类型、拉取、解包和 shim 错误。用生产工具按摘要拉取制品，比较清单、配置、层大小与哈希，最后通过同一 RuntimeClass 运行已知正常的冒烟制品。不要把宿主架构改标为 wasm32，应使用独立标签表示运行时可用性。