.NET 6 增加了对 Windows 进程隔离容器的支持 。 如果您在 Azure Kubernetes 服务 (AKS) 中使用 Windows 容器 ， 那么您依赖于进程隔离的容器 。 进程隔离容器可以被认为与 Linux 容器非常相似 。 Linux 容器使用cgroups ， Windows 进程隔离容器使用Job Objects 。 Windows 还提供 Hyper-V 容器 ， 通过更强大的虚拟化提供更大的隔离 。 Hyper-V 容器的 .NET 6 没有任何变化 。
此更改的主要价值是现在 Environment.ProcessorCount 将使用 Windows 进程隔离容器报告正确的值 。 如果在 64 核机器上创建 2 核容器 ， Environment.ProcessorCount 将返回2. 在以前的版本中 ， 此属性将报告机器上的处理器总数 ， 与 Docker CLI、Kubernetes 或其他容器编排器/运行时指定的限制无关 。 此值被 .NET 的各个部分用于扩展目的 ， 包括 .NET 垃圾收集器（尽管它依赖于相关的较低级别的 API） 。 社区库也依赖此 API 进行扩展 。
我们最近在 AKS 上使用大量 pod 在生产中的 Windows 容器上与客户验证了这一新功能 。 他们能够以 50% 的内存（与他们的典型配置相比）成功运行 ， 这是以前导致异常的OutOfMemoryException水平StackOverflowException 。 他们没有花时间找到最低内存配置 ， 但我们猜测它明显低于他们典型内存配置的 50% 。 由于这一变化 ， 他们将转向更便宜的 Azure 配置 ， 从而节省资金 。 只需升级即可 ， 这是一个不错的、轻松的胜利 。
▌优化缩放
我们从用户那里听说 ， 某些应用程序在 Environment.ProcessorCount 报告正确的值时无法实现最佳扩展 。 如果这听起来与您刚刚阅读的有关 Windows 容器的内容相反 ， 那么它有点像 。 .NET 6 现在提供 DOTNET_PROCESSOR_COUNT 环境变量来手动控制 Environment.ProcessorCount 的值 。 在典型的用例中 ， 应用程序可能在 64 核机器上配置为 4 核 ， 并且在 8 或 16 核方面扩展得最好 。 此环境变量可用于启用该缩放 。
这个模型可能看起来很奇怪 ， 其中Environment.ProcessorCount和--cpus（通过 Docker CLI）值可能不同 。 默认情况下 ， 容器运行时面向核心等价物 ， 而不是实际核心 。 这意味着 ， 当你说你想要 4 个核心时 ， 你得到的 CPU 时间与 4 个核心相当 ， 但你的应用程序可能（理论上）在更多的核心上运行 ， 甚至在短时间内在 64 核机器上运行所有 64 个核心 。 这可能使您的应用程序能够在超过 4 个线程上更好地扩展（继续示例） ， 并且分配更多可能是有益的 。 这假定线程分配基于Environment.ProcessorCount 的值 。 如果您选择设置更高的值 ， 您的应用程序可能会使用更多内存 。 对于某些工作负载 ， 这是一个简单的权衡 。 至少 ， 这是一个您可以测试的新选项 。
Linux 和 Windows 容器均支持此新功能 。
Docker 还提供了一个 CPU 组功能 ， 您的应用程序可以关联到特定的内核 。 在这种情况下不建议使用此功能 ， 因为应用程序可以访问的内核数量是具体定义的 。 我们还看到了将它与 Hyper-V 容器一起使用时的一些问题 ， 并且它并不是真正适用于那种隔离模式 。
▌Debian 11“bullseye”
我们密切关注 Linux 发行版的生命周期和发布计划 ， 并尝试代表您做出最佳选择 。 Debian 是我们用于默认 Linux 映像的 Linux 发行版 。 如果您6.0从我们的一个容器存储库中提取标签 ， 您将提取一个 Debian 映像（假设您使用的是 Linux 容器） 。 对于每个新的 .NET 版本 ， 我们都会考虑是否应该采用新的 Debian 版本 。
作为一项政策 ， 我们不会为了方便标签而更改 Debian 版本 ， 例如6.0, mid-release 。 如果我们这样做了 ， 某些应用程序肯定会崩溃 。 这意味着 ， 在发布开始时选择 Debian 版本非常重要 。 此外 ， 这些图像得到了很多使用 ， 主要是因为它们是“好标签”的引用 。