转载请联系新钛云服务公众号。运行大量容器来部署应用程序需要重新考虑操作系统的作用。Google的Container-OptimizedOS和AWS的Bottlerocket采用传统的虚拟化范例并将其应用于操作系统，而容器是虚拟操作系统和充当虚拟化引擎的最小Linux。为容器优化的各种Linux版本已经存在了几年，并已迁移到集群管理层或容器作为管理和用户实用程序。当您需要以最少的设置在Kubernetes中运行应用程序并且不想担心安全性、更新或需要来自云提供商的操作系统支持时，这些容器优化的操作系统是理想的选择。ContainerOS解决了运行大型容器集群时经常遇到的几个问题，例如跟上操作系统漏洞并为可能的数百个实例打补丁，在处理潜在冲突的依赖项时更新包，大依赖树导致的性能下降以及其他OS困难。几台服务器就可以应对挑战，而如果没有支持它的基础架构，管理数千台服务器几乎是不可能的。AWSBottlerocketBottlerocket专为在Amazon基础设施上托管容器而构建。它在AmazonElasticKubernetesService(EKS)、AWSFargate和AmazonElasticContainerService(ECS)中运行。从本质上讲，Bottlerocket是一个Linux5.4内核，添加了足以运行容器化的用户界面实用程序。Bottlerocket主要用Rust编写，并针对运行Docker和开放容器计划(OCI)图像进行了优化。Bottlerocket对EKS、Fargate、ECS甚至AWS没有任何限制。Bottlerocket是一个独立的容器操作系统，任何使用过RedHat风格的Linux的人都会熟悉它。Bottlerocket与AmazonEKS等容器编排器集成以管理和编排更新，并且可以通过构建操作系统的变体来添加对其他编排器的支持，以将必要的编排代理添加到构建或自定义组件中。Bottlerocket的安全性Bottlerocket的安全方法是最小化攻击面以防止外部攻击者，最小化漏洞对系统的影响，并提供容器间隔离。为了隔离容器，Bottlerocket使用容器控制组(cgroup)和内核命名空间来隔离系统上运行的容器。eBPF（EnhancedBerkeleyPacketFilter）用于进一步隔离容器并验证需要低级系统访问的容器代码。eBPF安全模式禁止指针运算、跟踪I/O并限制容器可以访问的内核函数。通过在容器中运行所有服务来减少攻击面。尽管容器可能会受到损害，但由于容器隔离，整个系统不太可能受到损害。通过操作系统附带的Kubernetes运算符运行亚马逊提供的Bottlerocket版本时，会自动应用更新。不可变的rootfs创建rootfs块的散列，并依赖于使用dm-verity验证的引导路径，确保系统二进制文件不会被篡改。配置是无状态的，/etc/安装在RAM磁盘上。在AWS上运行时，配置是通过API完成的，并且设置在重启后仍然存在，因为它们来自AWS基础设施中的文件模板。还可以使用实现CNI和CSI规范的自定义容器配置网络和存储，并通过Kubernetes控制器将它们与其他守护进程一起部署。SELinux默认是启用的，没有办法禁用它。通常这可能是个问题，但在容器操作系统用例中没有必要放宽此要求。目的是防止其他操作系统组件或容器修改设置或容器。此安全功能正在进行中。Bottlerocket开源Bottlerocket构建系统基于Rust，考虑到除了对Docker和Kubernetes的支持之外没有其他可构建的东西，这很好。Rust刚刚闯入前20名编程语言，并且由于C++的语法和自动内存管理等优势而受到关注。Rust是MIT或Apache2许可的。亚马逊很好地利用GitHub作为其开发平台，使开发人员很容易参与其中。任何开发人员都将熟悉工具链和代码工作流程，并且通过设计鼓励最终用户创建操作系统的变体。这是为了支持多个业务流程代理。为了使操作系统占用空间尽可能小，每个Bottlerocket变体都在特定的编排平面上运行。亚马逊包括Kubernetes的变体和本地开发版本。例如，您可以通过更改容器的URL创建自己的更新操作符或控件容器。管理Bottlerocket实例Bottlerocket无法通过Shell进行管理。事实上，需要管理的操作系统很少，需要通过HTTPAPI、命令行客户端(eksctl)或Web控制台完成。要更新，需要将更新容器部署到实例。查看GitHub上的bottlerocket-update-operator（Kubernetes操作符）。Bottlerocket使用“双分区模式”进行单步更新，其中映像在磁盘上有两个可引导分区。一旦更新成功写入非活动分区，每个分区的GUID分区表中的优先级位就会交换，“活动”和“非活动”分区角色也会交换。重新启动后，系统会升级，或在出现错误时回滚到最后一个已知的良好映像。与NanoBSD和其他嵌入式操作系统一样，没有可以安装的包，只有容器和更新是基于映像的。AWS布道者JeffBarr解释了做出这一决定的原因：Bottlerocket没有使用包更新系统，而是使用了一个简单的基于图像的模型，该模型允许在必要时进行快速和完整的回滚。这消除了发生冲突和中断的可能性，并使您可以更轻松地使用EKS等协调器自信地应用整个车队范围的更新。要直接访问Bottlerocket实例，您需要运行“control”容器，该容器由单独的containerd实例管理。该容器运行AWSSSM代理，因此它可以执行远程命令或在一个或多个实例上启动shell。默认情况下启用控件容器。还有一个管理容器在实例的内部控制平面上运行（即在单独的容器实例上）。启用后，此管理容器将运行一个SSH服务器，该服务器可以使用Amazon注册的SSH密钥作为ec2用户登录。虽然这对调试很有用，但由于这些实例的安全策略，它并不真正适合进行配置更改。GoogleContainer-OptimizedOSContainer-OptimizedOS是Google基于开源ChromiumOS项目维护的操作系统。与Bottlerocket一样，Container-OptimizedOS是一种基于图像的操作系统，针对在GoogleComputeEngineVM中运行Docker容器进行了优化。容器优化的操作系统解决了类似的更新、安全和易于管理的需求。尽管开发人员可以出于测试目的在KVM上运行它，但它不能在GoogleCloudPlatform之外运行。仅支持基于Docker的图像。工作负载弹性扩展已经成为一种发展趋势，Container-OptimizedOS的既定目标之一就是快速扩展。基于图像的最小操作系统通过cloud-init和Google的CloudSDK的组合快速启动并管理大规模配置。这意味着可以快速扩展应用程序服务以响应需求高峰和工作负载变化。容器优化操作系统安全性最重要的安全规则之一是减少攻击面。容器优化的操作系统通过将所有服务移出操作系统用户/系统空间并移至容器中来实现这一点。因此，裸机操作系统安装了最少数量的包来支持容器管理，并且容器管理自己的依赖项。内核还具有与安全相关的改进，例如完整性测量架构（IMA测量）、IMA审计、内核页表隔离以及一些取自ChromiumOS的Linux安全模块。如果应用程序需要，可以通过Seccomp和AppArmor添加细粒度的安全策略。Container-OptimizedOS实例的默认设置也具有安全意识，这使得保护大型集群变得更加容易。例如，没有可访问的用户帐户，防火墙设置会丢弃除SSH之外的所有连接，从而减少攻击面。可以通过Google的IAM角色或通过在实例元数据中添加和删除SSH密钥来管理对实例的访问。不允许基于密码的登录。双因素身份验证是一种选择。安全性也在文件系统级别实现。例如，Container-OptimizedOS使用内核在启动时验证的只读根文件系统，防止任何攻击者进行永久性本地更改。虽然这对安全性有好处，但它确实使配置成为一个挑战。为了启用配置，操作系统被设置为/etc/是可写的，但只是暂时的，这样每次重新启动时，操作系统配置都会被重建。容器优化的操作系统利用谷歌的最佳实践和基础设施来构建和部署图像。该操作系统的内核和包源代码是从谷歌拥有的代码库构建的，任何错误或漏洞都通过自动升级机制进行修补和发布。默认情况下启用的自动升级功能使集群中的节点与集群主版本保持最新。这既提高了安全性又减少了维护开销。谷歌还提供漏洞扫描，因此如果在容器优化操作系统中检测到漏洞，补丁会在可用时自动推出。Container-OptimizedOS的开源Container-OptimizedOS作为ChromiumOS项目的一部分是开源的，尽管除了实验之外没有理由自己构建它。与Bottlerocket不同，Container-OptimizedOS没有预见到客户需要在集群上构建和部署自定义映像，并且由于它依赖于Google的基础架构，因此没有理由这样做。构建容器优化操作系统需要谷歌独特的Chromium工具链和脚本。这些开发映像确实允许用户访问shell，主要由Google工程师用来构建、测试和调试系统。图像可以使用KVM运行或导入到ComputeEngine实例中。管理Container-OptimizedOS实例GoogleContainer-OptimizedOS不包含包管理器，但您可以使用CoreOSToolbox安装其??他工具，它会启动一个容器并允许您使用您喜欢的调试或管理工具。在大多数情况下，容器优化的操作系统实例将作为Kubernetes管理的集群的一部分运行。对于实验，定义一个映像，然后使用CloudConsole或gcloud命令行工具在GCE实例上运行它，然后像任何其他GCE实例一样通过SSH连接到它。基础镜像支持公共容器注册表，因此您可以立即开始使用您喜欢的Docker镜像。Google提供了一些不错的功能来帮助进行生产部署。其中之一是NodeProblemDetector，它监控容器优化操作系统实例的健康状况。借助GoogleCloudMonitoring，您可以使用GoogleOperations仪表板查看容量和错误报告，并可视化集群的健康状况。时间与Linux的systemd-timesyncd同步。使用与SNTP同步的包有点不寻常，特别是如果您有长时间运行的实例需要对时间进行细粒度控制，但如果需要，您始终可以在容器中安装完整版本的NTPd。大多数情况下会自动应用升级，并且有三种滚动发布渠道可供选择：dev、beta和stable。这些通道提供了进入功能管道的窗口，并允许集群的滚动升级。通常，集群的一小部分将处于开发阶段，更多部分处于测试阶段，大部分处于稳定阶段。这降低了遇到集群范围问题的风险。使用主动/被动根分区进行自动更新，其中一个分区是“活动”分区，另一个是备份分区。来自dev/beta/stable频道的映像更新被下载到被动分区，引导管理器在引导时选择最新版本。如果出现错误，请从旧分区引导系统。可以通过CLI界面手动控制更新，但大多数情况下使用自动更新。为云构建的容器优化操作系统容器优化操作系统并不新鲜。之前回顾了CoreOS、RancherOS、RedHatAtomic等。我认为我们处于操作系统开发线的末端，其中操作系统只是整个云操作系统的一部分，就像共享库提供特定功能一样主机操作系统。操作系统是后端基础设施的一部分，这意味着开发人员可以专注于他们的应用程序，而不是它们的运行方式。Bottlerocket和容器优化的操作系统都可以做到这一点。两者都非常适合为它们开发的云。AWS的Bottlerocket融合了其前身的许多最佳创意，并增加了对多个云环境和容器编排器的支持，在用例需要时创建变体。Bottlerocket将在2020年的某个时候在GA中可用。与Bottlerocket相比，Google的Container-OptimizedOS更接近于microVM领域（例如AWSFargate下的Firecracker技术）。与许多Google技术一样，Container-OptimizedOS对事情的完成方式很坚定，这通常是一件好事。但是，如果正在考虑多云策略，Container-OptimizedOS是一个障碍，而不是优势。大多数人都在考虑多云并避免供应商锁定。如果以后要部署到多云，Bottlerocket会是更好的选择。原文链接：https://www.infoworld.com/article/3570158/review-aws-bottlerocket-vs-google-container-optimized-os.html?
