Kubernetes Linux操作系统指南

你已经对Kubernetes有了一定的了解，认识到它的重要性。Kubernetes负责容器管理，调度工作负载到集群，处理可伸缩性和冗余，并自动执行滚动更新和回滚。它是一个与基础设施无关的系统，通过声明式语句描述系统和应用的期望状态，并推动所托管的元素达到该状态。这使得管理一个强大且可扩展的系统变得更为简单。

尽管Kubernetes能够提供容器的可扩展性和管理功能，但它并不直接管理其所依赖的基础设施。Kubernetes本质上是一个应用程序，必须在某个地方运行。虽然Kubernetes不是一个操作系统，但它依赖于在节点上安装的Linux或Windows系统。Kubernetes可以在AWS、GCE等云服务上运行，也可以在VMware等虚拟化平台上运行，但这些仍需先安装操作系统。

在操作层面，Kubernetes和它所运行的工作负载是重点，这本是理所当然的，但这也导致一个在Kubernetes部署中常见的问题。虽然Kubernetes会定期进行补丁和升级，但底层操作系统的维护、更新、安全性和操作常常被忽视，尤其是在安全审计之前。我经常听到SRE和系统管理员提到，管理Linux与Kubernetes同时进行会增加额外的工作量。正如一般的Linux操作系统，Kubernetes也需要补丁、更新、保护和用户访问控制等。然而，这些任务虽在Kubernetes层面完成，但并不意味着在操作系统层面可以被忽略。选择合适的底层操作系统发行版，可以显著减少维护操作系统的工作量，减轻未及时更新的影响。

因此，考虑到在运行Kubernetes之前需要先安装Linux，你应该选择哪个Linux发行版呢？有许多可供选择的方案，通常分为两种类型：容器优化的操作系统和通用操作系统。

通用Linux操作系统

这些是常见类型的Linux。

多数人对通用Linux操作系统如Ubuntu、Debian、CentOS、RHEL或Fedora非常熟悉。在Kubernetes集群中运行通用操作系统的一个主要优势是，系统管理员对安装、更新和加固Linux发行版的流程非常熟悉。可以利用现有的工具集快速启动服务器，安装操作系统，并配置基本的安全设置。现有的补丁管理和安全检测工具也能在这些系统上正常运行，即使它们上面运行的是Kubernetes。

然而，使用通用Linux系统也伴随着常见的管理开销。这意味着用户账号管理、补丁管理、内核更新、防火墙服务、安全SSH、禁止Root登录、禁用未使用的守护进程、内核调优等任务都需要完成并保持更新。如前所述，大部分任务可以通过现有工具如Ansible、Chef、Puppet来完成，但更新清单或配置文件以适配Kubernetes的主节点和工作节点并非易事。

另一个问题是操作系统变更与Kubernetes维护之间的协调。常常会出现这种不协调的情况，导致安装后操作系统未进行调整。随着时间推移，Kubernetes会（希望）进行升级，而底层操作系统可能保持不变，积累了各种包和已安装内核中的已知CVE漏洞。

理想情况下，你希望自动化平台（如Ansible或Puppet）与Kubernetes协调，以便在不影响Kubernetes操作的情况下升级节点的操作系统。这意味着操作系统需要：

• 将节点设置为不可调度，以便新工作负载不会调度到该节点
• 驱逐该节点，以将所有运行的Pod迁移到其他节点
• 更新并为节点打补丁
• 将节点设置为可调度

当然，系统需要确保在同一时间内不会有过多节点进行更新，以保证集群的工作负载能力不会受到负面影响（节点也不要过少，以免大型集群的更新速度慢于补丁和更新的发布速度）。你可能希望协调操作系统更新与Kubernetes更新，以减少重启和中断，但在短时间内仍需支持更关键的操作系统更新。

通用Linux操作系统的最大优势在于工作人员的熟悉程度。这意味着他们将更容易进行部署，并掌握故障排除技能。他们可以安装并使用常见的操作系统工具，如TCPdump、strace、lsof等。配置可以轻松更改，以修复错误和测试替代方案。缺点是需保持系统管理的开销，并需与Kubernetes基础设施协调更新。

容器专用操作系统

美国国家标准与技术研究所（NIST）对容器专用操作系统的定义进行了很好的总结，列出了一些优点。

显而易见的一点是，操作系统运行的软件和包越少，攻击面越小，漏洞也越少。这使得容器专用操作系统在安全性上具有明显优势，即使不进行频繁的打补丁。

容器专用操作系统还可以采取其他安全措施，比如将根文件系统设为只读，从而缓解漏洞可能带来的影响。

通常情况下，容器专用操作系统不运行包管理。这减少了因安装或更新包而导致节点或服务中断的风险。由于没有Chef和Puppet等管理工具，运行不完整对系统稳定性的影响也减少。相反，完整的操作系统镜像会在备用启动机制中应用所有更新和配置，在下一次重启时启动，或回退到之前已知的良好镜像。

一些容器专用操作系统更接近于通用Linux发行版，例如VMware的PhotonOS，相较于普通Linux发行版，其安装的包数量较少，但仍包括包管理器、SSH访问，并且其文件系统不会被挂载为只读。

CoreOS是第一个被广泛接受的容器专用操作系统，推广了在容器中运行所有进程以提高安全性和隔离性的理念。CoreOS取消了软件包管理器，并通过重启到两个只读/USR分区中的一个，确保更新的原子性和可回滚性。可惜自从CoreOS被RedHat收购后，该项目就被终止了。

如今的容器专用操作系统都采用最小化设计（在操作系统中安装的软件包极少），并锁定（在一定程度上）；它们在容器中运行进程（以增强安全性、稳定性和服务隔离），并提供原子更新（通过启动到一个可启动分区并更新另一个分区）。

Google的Container-Optimized OS支持只读根文件系统，但允许SSH，只在GCP中运行。RancherOS运行SSH，但不使用只读文件系统来保护根分区。K3OS同样由Rancher开发，但并不运行完整的Kubernetes发行版。管理通过kubectl进行，但也支持SSH。AWS Bottlerocket是另一个具有不可变根文件系统和SSH支持的操作系统，至少在初期，它专注于AWS的工作负载。

Talos是容器专用操作系统中一个特别的例子。与其他系统类似，Talos操作系统同样是最小化的，没有包管理器，并使用只读文件系统，通过升级控制器与K8s集成进行升级。

然而，Talos操作系统在容器专用操作系统中更进一步，提出了不可变基础设施的理念，取消了所有SSH和控制台访问，所有的OS访问和管理通过API进行。在运行Kubernetes的节点上，你可以通过API调用完成所有操作，如查看所有容器、检查网络设置等。但在节点上无法进行不该做的操作，例如卸载文件系统。Talos还选择完全重写Linux init系统，仅执行启动Kubernetes的任务。

无法管理任何用户定义的服务，这进一步提升了安全性，减少了维护，降低了CVE的影响。拥有一个由API管理的操作系统也非常适合大规模的操作和管理，如果你需要检查某个节点、一类节点或所有节点上的某个容器日志，只需使用不同参数的相同API调用即可。

如果你已经接受了容器管理是“牛而非宠物”的理念，即在部署更新或修复时，销毁容器并启用新版本，那么确保支持容器的基础设施采用相同的方法是合理的。采用类似于容器的管理模式，销毁并重新配置节点进行更新，而不是打补丁，这可能需要一些培训，但采用容器专用的操作系统有助于实现这种模式，减少管理开销并提高安全性。

鉴于许多企业仍处于Kubernetes采用生命周期的早期，现在是熟悉这种下一代操作系统的好时机。通过将操作系统与Kubernetes紧密结合，可以将整个Kubernetes集群视为一台计算机，从而减少开销并提升安全性。这使得人们的注意力继续集中在计算基础设施所提供的工作负载和价值上，向API驱动的数据中心迈出了又一步。