多个容器运行在同一台 Windows 主机上时，磁盘资源争夺是最容易被忽视、却最容易引发连锁故障的问题之一。一个失控的日志写入进程可能在几分钟内填满宿主机的可用空间，或者把磁盘 IOPS 拉满，让其他容器陷入卡顿。要在 Windows 容器环境中实现稳定的资源隔离，必须同时考虑磁盘配额和 IO 限制两个维度。磁盘配额关心的是容器最多能占用多少存储容量，IO 限制则约束容器每秒可以执行多少次读写以及数据的传输速率。两者作用于不同层面，配置方式也因 Windows 容器的隔离模式而异。
一、Windows 容器存储架构与磁盘配额原理
Windows 容器有两种隔离模式：进程隔离容器（也叫 Windows Server 容器）和 Hyper-V 隔离容器。进程隔离容器共享主机内核，容器的可写层直接存储在主机文件系统上的独立目录中，这个目录默认位于 C:\ProgramData\docker\windowsfilter\ 路径下。由于文件系统是共享的，对单个进程隔离容器做严格的磁盘容量限制比较困难，Docker 的 --storage-opt size 参数在部分 Windows 容器版本中不生效，因为它主要用于 Linux 的 devicemapper 或 overlay2 驱动。进程隔离模式通常需要借助 NTFS 磁盘配额或第三方工具来实现容量约束。
Hyper-V 隔离容器则完全不同，每个容器都运行在独立的轻量级虚拟机中，容器可写层被封装成一个 VHDX 虚拟磁盘文件，同样存放在主机上的 C:\ProgramData\docker\windowsfilter\ 目录中，但文件名和容器 ID 关联。这种设计天然适合做容量限制，因为只要限制 VHDX 文件的最大尺寸即可。通过 Docker 运行参数 --storage-opt size=10GB 创建的 Hyper-V 容器，可写层虚拟磁盘最大不会超过 10GB，底层 VHDX 文件实际占用空间按需增长，但会被硬性限制在设定值以内。
理解这一存储架构是配置磁盘配额的前提。如果使用的是进程隔离容器，就需要把思路切换到 NTFS 配额：给容器进程映射的用户账户设置磁盘使用上限。进程隔离容器中的进程通常以容器管理员或 SYSTEM 身份运行，因此配额需要针对容器使用的卷或目录所在的分区进行设置。虽然这种方法不如 Hyper-V 的 VHDX 限制那样直观，但在大规模生产环境中仍然是一种可行的补充手段。
二、磁盘配额配置：Hyper-V 容器与 NTFS 配额方法
对于 Hyper-V 隔离容器，最直接的磁盘配额方式是在 docker run 命令中指定存储参数。例如创建一个最大可写层为 10GB 的 Windows Server Core 容器，可以使用如下命令：
docker run -it --isolation=hyperv --storage-opt size=10GB mcr.microsoft.com/windows/servercore:ltsc2022 powershell
容器启动后，可以在宿主机上用 PowerShell 查看对应 VHDX 文件的大小和最大容量。先通过 docker inspect 获取容器的 ID，然后在 C:\ProgramData\docker\windowsfilter\ 目录下找到以该 ID 开头或包含该 ID 的子目录，里面会有一个 sandbox.vhdx 或类似名称的虚拟磁盘文件。使用 Get-VHD 命令可以查看它的最大尺寸是否被正确限制为 10GB。
对于进程隔离容器，如果 Docker 版本的 windowsfilter 存储驱动不支持 --storage-opt size，就需要使用 NTFS 配额。NTFS 配额基于卷和用户账户，配置前必须确保目标分区已启用配额跟踪。以限制容器服务账户在 C 盘的使用量为例，可以在宿主机上打开管理员 PowerShell，执行：
# 开启 C 盘的配额管理 fsutil quota track C: # 假设容器进程以容器管理员用户运行，可先查询其 SID 或用户名 # 以下命令设置该用户配额为 5GB，警告阈值为 4GB fsutil quota modify C: 5368709120 4294967296 "容器管理员用户名"
这种方法的缺点是配额与用户账户绑定，而容器进程的用户映射在不同镜像中可能不同。实际使用时常需要结合 runas 或自定义容器启动用户来确保配额生效。此外，NTFS 配额只能限制整个分区的使用，如果多个容器共享同一个 C 盘且进程隔离容器可写层都在 C 盘上，配额会相互干扰。更稳妥的做法是给每个进程隔离容器挂载独立的卷，再对该卷启用配额。
无论是 Hyper-V 还是进程隔离模式，磁盘配额都只解决容量上限问题，无法控制写入速度。一个容器即使只有 5GB 配额，也可能在短时间内以极高速度写满这 5GB，进而引发 IO 争抢。因此还需要配置 IO 限制，从每秒读写次数和带宽两个角度进行约束。
三、IO 限制配置：Docker 设备参数与 Hyper-V 存储 QoS
Docker 提供了 --device-read-bps、--device-write-bps、--device-read-iops 和 --device-write-iops 四个参数，用于限制容器对块设备的读写速率。这些参数在 Linux 上通过 cgroup 的 blkio 子系统实现，但在 Windows 容器中支持非常有限。进程隔离容器由于没有等价的内核块设备控制器，通常无法使用这些参数生效。部分 Docker 版本在 Hyper-V 隔离容器中会忽略或抛出警告，因此不能依赖这些通用参数来限制 Windows 容器的磁盘 IO。
Hyper-V 隔离容器提供了更可靠的 IO 限制途径。每个 Hyper-V 容器对应一个轻量级虚拟机，其磁盘以 VHDX 形式挂载，因此可以利用 Hyper-V 的存储 QoS 功能限制 IOPS。首先在宿主机上找到容器对应的虚拟机名称或 ID。通常 Docker 创建的 Hyper-V 容器虚拟机会在 Hyper-V 管理器中出现，名称包含容器 ID 前缀。找到后，可以使用 PowerShell 设置该虚拟磁盘的最大 IOPS：
# 假设容器对应的 Hyper-V 虚拟机名称为 docker-<容器ID> $vmName = "docker-<容器ID>" Get-VM -Name $vmName | Get-VMHardDiskDrive | Set-VMHardDiskDrive -MaximumIOPS 300 -MinimumIOPS 0
上述命令将容器的虚拟磁盘 IOPS 限制在每秒 300 次以内，最低不设限。需要注意的是，Set-VMHardDiskDrive 的 -MaximumIOPS 参数适用于 Hyper-V 虚拟机，但 Docker 自动管理的 Hyper-V 容器虚拟机在停止或删除容器后会被清理，因此这类设置更适合长期运行或通过脚本自动化的场景。对于带宽限制，Hyper-V 的磁盘 QoS 没有直接提供类似 -MaximumBandwidth 的通用参数，通常需要结合 Windows 存储 QoS 策略或使用支持带宽限制的存储设备。
如果需要限制进程隔离容器的 IO，情况更为复杂。Windows 没有原生的容器级 blkio 控制。一种替代方案是使用 Windows 性能监视器或资源调控策略限制容器宿主进程的 IO 优先级，但这并不精确。最常见的方法还是尽量将 IO 敏感型工作负载运行在 Hyper-V 隔离模式下，利用虚拟化层完成隔离。对于 Hyper-V 隔离容器，还可以通过 Set-StorageQosPolicy 创建聚合策略并应用到虚拟机磁盘上，实现对多容器整体 IO 的控制，但配置步骤更复杂，适合对 QoS 有深入要求的团队。
四、验证配额与 IO 限制是否生效
配置完成后必须验证限制是否真正生效。对于磁盘配额，最快的检查方式是在容器内尝试写入超过配额限制的文件。Hyper-V 容器中，写入超过 VHDX 最大尺寸的数据会触发磁盘空间不足错误；通过宿主机 Get-VHD 查看 VHDX 的 Size 字段应保持为设定的最大值，而 FileSize 字段表示实际占用空间。对于 NTFS 配额，写入超过配额的数据会收到拒绝访问或空间不足的提示，同时宿主机可以使用 fsutil quota query C: 查看配额使用情况。
验证 IO 限制则需要在容器内生成可观测的磁盘负载。Windows 容器中可以使用 PowerShell 的 Get-Random 配合 Set-Content 循环写入大文件，或使用 diskspd.exe 等专业 IO 测试工具。测试期间在宿主机上打开性能监视器，添加物理磁盘的每秒读写次数和磁盘字节数计数器，观察是否被限制在设定值附近。对于 Hyper-V 容器的 IOPS 限制，可以对比设置前后同一测试脚本的执行时间变化，限制生效时 IOPS 曲线会明显趋于平坦。
最后需要强调的是，磁盘配额和 IO 限制应当被视为容器资源治理策略的一部分，而不是万能保险。它们的有效性取决于所选的隔离模式、Windows 版本、Docker 版本以及底层存储驱动。生产环境中建议优先采用 Hyper-V 隔离容器，通过 --storage-opt size 控制容量，再结合 Hyper-V 存储 QoS 控制 IOPS，同时用监控工具持续观察磁盘使用趋势，及时发现异常容器并干预。这样既能保障容器密度，也能避免单个容器拖垮整台主机的存储性能。