您已经了解Kubernetes（或正在考虑探索一些Kubernetes部署）。了解它的理由有很多，而且您可能已经知道，Kubernetes负责管理容器、将工作负载调度到集群、处理可扩展性和冗余，以及自动化回滚（更新）和回滚。它是一个与基础架构无关的系统，它使用声明性语句来描述系统和应用程序应处于的状态，并驱动托管元素实现该状态。这使得管理功能强大且可扩展的系统变得更加容易。当然，这里有一个“易于管理”的学习曲线，但是收获现代基于容器的软件开发的好处是非常值得的，即提供可扩展性和基础设施可移植性的基础设施。虽然Kubernetes确实支持容器的操作可扩展性和管理，但它并不能直接帮助您管理Kubernetes本身所依赖的基础设施。Kubernetes本身是一个应用程序（或一组应用程序），需要在某处运行。尽管您可能听说过，但Kubernetes不是操作系统，它仍然依赖于在节点上安装Linux或Windows。Kubernetes可以运行在AWS或GCE等云提供商上，也可以运行在VMware等虚拟化平台上，但所有这些仍然需要先安装操作系统。（一些如AWSEKS不需要管理控制平面节点，但仍然需要为工作节点设置Linux服务器。）在操作上，重点是Kubernetes及其运行的工作负载，这是应该的，但是这导致在Kubernetes中进行部署。经常问的问题。虽然Kubernetes会定期打补丁和升级，但对底层操作系统的维护、更新、安全和操作的担忧常常被遗忘或忽视，至少在安全审计之前是这样。我经常从SRE和系统管理员那里听到，同时管理Linux和Kubernetes会导致额外的工作。就像一般的Linux操作系统一样，Kubernetes也需要打补丁、更新、保护和控制用户访问等。然而，仅仅因为这些任务是在Kubernetes级别完成的，并不意味着它们可以在操作系统级别被忽略。但是，选择合适的底层操作系统发行版，可以大大减少维护操作系统的工作量，缓解不及时更新带来的影响。那么，考虑到需要先安装Linux才能在其上运行Kubernetes，涉及到底层操作系统，你应该选择运行哪个Linux发行版呢？有很多选择，但它们通常分为两种类型，即容器优化操作系统，或通用操作系统。通用Linux操作系统这些是普通类型的Linux。大多数人都熟悉运行通用类型的Linux操作系统，例如Ubuntu、Debian、CentOS、RHEL或Fedora。这是在Kubernetes集群中运行通用操作系统的主要优势之一，您的系统管理员将熟悉如何安装、更新和强化您的Linux发行版。您可以使用现有的工具集来启动服务器、安装操作系统并将其配置为基本的安全级别。现有的补丁管理和安全检测工具应该可以在这些系统上正常工作，即使在这些系统上运行Kubernetes。然而......对于通用类型的Linux系统，通常会产生Linux管理开销。这意味着用户帐户管理、补丁管理、内核更新、服务防火墙、SSH安全、禁用root登录、禁用未使用的守护程序、内核调整等，所有这些都需要完成并保持最新。如前所述，这些任务中的大部分都可以使用Ansible、Chef、Puppet等现有工具来完成，但是，更新清单或控制文件以使服务器配置文件适合Kubernetes主节点和工作节点可以说是非常重要的事物。另一个问题是操作系统更改与Kubernetes维护的协调。通常会出现不协调，导致操作系统在安装后保持原样。Kubernetes将（希望）随着时间的推移进行升级，但底层操作系统可能会保持不变，慢慢地在各种包和安装的内核负担中积累已知的CVE（常见漏洞和暴露）。理想情况下，您希望Ansible或Puppet等自动化平台与Kubernetes协调，以便可以在不影响Kubernetes操作的情况下升级节点的操作系统。这意味着操作系统需要：将节点设置为不可调度，这样新的工作负载就不会被调度到它上面驱逐节点，以便所有正在运行的Pod可以移动到其他节点更新和修补节点将节点设置为可调度当然,系统需要保证同时更新的节点不会太多，这样才能保证集群的工作负载能力不会受到负面影响（节点数量不能太少，所以大型集群的更新速度比补丁和更新的发布速度慢）。您可能希望协调操作系统更新与Kubernetes更新以减少重启和中断，但您仍然需要在短时间内支持更多关键操作系统更新。通用Linux操作系统的最大优势在于工作人员对它的熟悉程度。这意味着他们将熟悉部署，但也具备故障排除技能。他们可以安装和使用常见的操作系统工具，如tcpdump、strace、lsof等。可以轻松更改配置以纠正错误和测试备选方案（这既是好事也是坏事！）。缺点是维护系统管理的开销以及需要协调Kubernetes基础设施和操作的更新。特定于容器的操作系统美国国家标准与技术研究院(NIST)对定义特定于容器的操作系统进行了很好的总结，列出了一些优点。“Container-only主机操作系统是一种极简主义操作系统，明确设计用于仅运行容器，禁用所有其他服务和功能，并具有只读文件系统和其他强化措施。当使用纯容器操作系统时，攻击纯容器主机操作系统的表面积通常比通用类型操作系统小得多，因此攻击和破坏纯容器主机操作系统的机会较少.总之，组织应尽可能使用纯容器主机操作系统。”引自“NIST特别出版物800-190应用程序容器安全指南”攻击面和更少的漏洞。这使得特定于容器的操作系统从一开始就更加安全，即使不经常打补丁也是如此。特定于容器的操作系统还可以采用其他安全措施，例如将根文件系统（最好是所有文件系统）设置为只读，以减轻任何漏洞的影响。纯容器操作系统通常不运行（或支持）包管理。这减少了安装或更新包导致冲突的可能性，这些冲突将使节点或服务停止运行。由于没有Chef、Puppet等管理工具，减少了操作不全影响系统运行稳定性的几率。相反，应用了所有更新和配置的完整操作系统映像安装在备用启动机制中，并在下次重新启动时启动，或者回退到以前已知的工作映像。这意味着节点的配置在任何时候都是完全已知的，并且可以从所使用的版本控制系统中恢复任何版本。一些特定于容器的操作系统更像是通用的Linux发行版。例如，VMware的PhotonOS安装的软件包比普通的Linux发行版少，但它仍然包含一个软件包管理器、SSH访问，并且不挂载文件系统。以只读方式上传。人们有时会混淆的一点是，通用Linux系统的“云优化”版本仍然是通用Linux系统，例如Ubuntu发布的“云映像”，它是“由Ubuntu定制的”。工程部门在公共云上运行”。然而，这些仍然是完整的Linux发行版，除了一个额外的cloud-init包之外，所有包都已安装，这使得配置启动更容易而无需手动干预。CoreOS是第一个普遍采用的特定于容器的操作系统，并推广了在容器中运行所有进程以提高安全性和隔离性的想法。CoreOS取消了包管理器，并使用重新启动到两个只读/usr分区之一来确保更新是原子的并且可以回滚。但是，由于CoreOS被RedHat收购，该项目已经终止。目前的容器专用操作系统都采用了最小化的姿态（操作系统中安装的包很少）；锁定（在一定程度上）；在容器中运行进程（为了更好的安全性、稳定性和服务隔离），并提供原子更新（通过引导到一个可引导分区并更新另一个分区）。这方面的例子有：Google的Container-OptimizedOS，它支持只读的根文件系统，但允许SSH，并且只在GCP中运行。RancherOS运行SSH，不使用只读文件系统来保护根分区K3OS，同样由Rancher开发，不运行完整的Kubernetes发行版。通过kubectl进行管理，但支持SSH。AWSBottlerocket是另一个具有不可变根文件系统和SSH支持的操作系统，这意味着它专注于AWS工作负载，至少在最初是这样。Talos是个例外，它是容器特定操作系统中最固执己见的操作系统之一。与其他系统一样，TalosOS是最小的，没有包管理器，并且仅使用只读文件系统（/var和/etc/kubernetes除外，以及一两个临时可写（重启时重置）的特殊文件，例如/etc/resolv.conf），通过升级controller，将升级与K8s集成。然而，TalosOS通过取消所有SSH和控制台访问并使所有OS访问和管理API驱动，将不可变基础架构的想法比其他人更进一步。在运行Kubernetes的节点上，您可以通过API调用您想要执行的所有操作、查看所有容器、检查网络设置等。但是在节点上您不能做不该做的事情，例如卸载文件系统。Talos也选择了完全重写LinuxInit系统，它做了一件事，那就是启动Kubernetes。不能管理任何用户定义的服务（这些都应该通过Kubernetes管理），这进一步提高了安全性（没有SSH，没有控制台），减少了维护（没有用户，没有补丁），并减少了任何CVE的影响（因为文件系统是不可变的并且是短暂的）。您可能不同意放弃SSH访问、限制SRE操作和强制节点完全不可变是可取的，但这也是前一段时间反对不可变容器的论点，值得探讨。拥有API管理的操作系统也非常适合大规模的运营和管理。如果需要查看某个节点、某类节点或所有节点上某个容器的日志，只是同一个API调用不同的参数而已。总结如果你采用了容器管理是“牛不是宠物（即生产软件基础设施可以随时更换）”的观点，即当部署更新或修复时，容器被销毁并提出新版本，然后确保支持容器。基础设施采用相同的方法是有意义的。采用类似容器的管理模型，销毁和重新配置节点以进行更新而不是打补丁，可能需要一些培训，但拥有特定于容器的操作系统有助于此模型，减少管理开销并提高安全性。容器专用操作系统还有助于提高运行稳定性，系统管理员或开发人员无需更改配置即可使其运行，从而消除了人为错误或配置错误导致下一次升级失败的可能性。鉴于许多企业仍处于Kubernetes采用生命周期的早期阶段，现在是熟悉这个下一代操作系统的好时机。通过将操作系统与Kubernetes紧密耦合，可以将整个Kubernetes集群视为一台计算机，从而减少开销并促进增强安全性。这使人们将注意力集中在计算基础设施提供的工作负载和价值上，并且是迈向API驱动数据中心的又一步。
