Kubernetes 为我们做了什么？

mitaparvin

每个系统都从基本的基础设施开始。您需要知道您在哪里拥有什么类型的机器。无论这种架构是物理的、虚拟的还是桌面上的笔记本电脑（我看到的生产服务比您想象的在笔记本上运行的要多）并不重要。您需要有关此基础设施的其他基本信息，我指的不是监控，后者稍后会提供。只是简单的事情：他们在哪里？它们可以运行吗？他们正在运行什么样的进程？这可能看起来微不足道，但在我们拥有平台之前，我们有无数的定制工具可以完成这件事。

在基础设施中达到一定数量的机器后，您可能开始使用基础设施自动化工具，例如 Ansible、Salt 和 Chef。其中每一个都有自己的运作方式。他们保持库存最新，并提供与机器交互的界面，而无需手动通过 SSH 连接到机器。您甚至可能已经编写了（至少我们做到了）自定义集成来扩展云中的工作负载或检查系统的完整性。一段时间后，其中一些机器从 电话号码列表 这种自动化中解脱出来（这就是牛服务模型开始流行的点）。他们有一个固定版本的软件。它们变得如此专业和精致，以至于在一段时间过去后，没有人敢升级或重新启动它们（在那里，看到过）。另一个长期争论的焦点是服务发现和 DNS。

在裸机基础设施上，我们有自定义 DHCP 服务器和 DNS（绑定、dnsmasq、未绑定，甚至一些自定义）实例来管理这个简单但复杂的功能。我们根据应用程序指标管理公共记录、内部记录和自定义 DNS 响应，是的，有时我们会花整晚的时间来调试出现的问题。Kubernetes 内置的 DNS 和服务概念解决了大部分问题。我们有有限但明确的（如果您考虑循环确定性）解析规则。此外，更改底层网络驱动程序现在很简单。您可以选择任何支持 CNI 接口的提供商。


更好的是，覆盖网络和网络策略为开发人员简化了网络堆栈。您不会遇到 VLAN、封装、自定义路由规则（除非您负责 Kubernetes 的操作）。默认行为是所有内容都已连接。如果您需要将事物分开，您只需定义网络策略即可。易于理解，甚至更易于审核。



作业和 Cronjobs 是遗留基础设施的另一个陷阱。通常，有一个节点（或几个节点）运行作业。它们通常连接到各种网络（最初可能不是，但从长远来看肯定是）。他们对临时资源运行垃圾收集，或者运行备份或各种其他东西。在快速发展的环境中，很难跟踪正在运行的内容以及在何处运行。根据我的经验，如果你需要快速的东西，你就不会费心去自动化它。最终，这不是问题，因为我们的工作是保持服务在线。然而，有时一项重要的工作仍处于灰色地带。有一次我们正在调试丢失的分析数据；一项工作应该将数据从 A 传输到 B。我们扫描了所有自动化操作，没有发现任何证据表明存在这样的过程。我们开始想知道这东西是如何运作这么久的。检查时间线，我们发现当数据开始枯竭时，一台不相关的机器已经重新启动。进一步调查发现，shell 脚本运行于 screen命令 负责执行任务。