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