翻译自 Three Common Kubernetes Challenges and How to Solve Them 。
开发者生产力、多集群问题和边缘学习曲线：随着您的发展，您在 Kubernetes 方面面临哪些挑战？
Kubernetes 因其自身的复杂性而享有相当可怕的声誉（正如我们之前所讨论的）。第一次学习它并设置您的第一个集群，部署您的第一个应用程序栈……这可能会很痛苦。
但正如任何经验丰富的操作员都会告诉你的那样，当你扩展到在生产中大规模运行 Kubernetes 时，你会遇到真正的痛苦！
让我们深入研究我们在该领域看到的三个最常见的“成长的烦恼”：
- 开发人员生产力
- 多集群头痛
- 边缘学习曲线
我们不仅会探讨痛苦，还会向您展示避开这些陷阱的方法。
基础设施并不是为了自身而存在。作为运维团队，你们创建的集群是为了为所支持的开发团队提供应用程序交付服务。
尽管“DevOps”一词很流行，但大多数开发人员并不具备成为云原生基础设施或 Kubernetes 专家的技能。他们更愿意编码功能而不是管理基础设施（正如我们在这篇博文中探讨的那样）。
开发人员只想使用 Kubernetes 集群等基础设施元素，他们无法容忍延迟和障碍。不幸的是，给他们想要的东西并不总是那么容易。
让我们举一个简单的例子：在新发布的应用程序代码上运行测试套件。
开发人员想要一个原始、干净的集群——可能是多个集群，运行特定版本的 Kubernetes 和其他软件。这对于他们获得预测生产行为的准确测试至关重要。我们都知道，不可能在本地笔记本电脑上镜像生产基础设施设置，尽管这很诱人。
如果一个测试因为简单的原因失败了，开发人员可能会立即想要重复 CI/CD 流程。
但你知道这并不容易。
启动一个新的集群需要工作，要花钱，即使你有能力立即响应请求，也需要时间。这意味着您的开发人员一直在等待。
这是一个真正的难题。现在想象一下，它发生在每天推动多个代码管道的数十个开发团队中。
那么，你是如何处理的呢？一个答案是虚拟集群。在虚拟集群设置中，基础架构团队在为开发人员提供虚拟集群的同时保持主机集群稳定并处于他们的完全控制之下。虚拟集群是隔离的，对底层基础设施呈现零风险，几乎不需要时间或资源来启动，这意味着您可以为每个团队提供他们自己的集群来使用。
这个解决方案基于开源的 vcluster 项目，但在 Spectro Cloud 中，我们使这项技术变得企业级和易于消费。也就是说，我们添加了一个时尚的用户界面，在幕后实现了完全声明性方法与 Cluster API 相结合，并将所有这些连接到基于角色的访问控制，并呈现为易于消费的 SaaS 解决方案。
使用 Palette，开发人员可以根据基础设施组定义的集群配置文件为自己创建专门的集群。每个团队都可以拥有自己的测试环境。当然，整个过程也可以通过 Terraform 提供程序或 REST API 调用进行完全自动化。采用这种方法，基础设施团队仍然具有细粒度控制权，但开发人员现在具备了在生产类似条件下测试其代码的自由和能力。
每个人都从一个 Kubernetes 集群开始。但是今天很少有团队会一直保持这种状态。
当您拆分开发、暂存和生产环境集群时，这个数字会迅速增长到三个。
从哪里开始？好吧，我们的研究发现，已经有一半在生产中使用 Kubernetes 的人拥有超过 10 个集群。 80% 的人希望在明年增加集群的数量或规模。
您或许可以使用 kubectl、k9s 和其他开源工具手动管理几个集群。但是一旦你发展到几十个集群，管理 Kubernetes 就会变得不堪重负。
我们如何解决这个问题？
多集群管理的基本原则：您不应该手动使用 kubectl 并单独连接到您的集群。相反，您以声明的方式描述它们的配置。
“未来状态”的描述应该涵盖整个集群，从它的基础设施到在上面运行的应用程序工作负载。换句话说，您应该能够仅使用其描述从头开始重新创建整个集群堆栈，而无需人工干预。
当您展望越来越多的集群时，从一开始就保持云无关性是值得的。
只使用一个公共云提供商很有诱惑力。这是最简单的路径：只需学习一组产品和术语。而且，云提供商通常会尽力让您留在他们平台上，并经常通过财务激励来鼓励忠诚。
但是，您可能会发现自己处于多云环境中的原因有很多。合并和收购有时会出人意料地带来另一家供应商。您可能希望使用多个云来访问特定功能，或者分散风险并提高可用性。
我们看到一些公司正在使用混合架构方法来部署Kubernetes：一些传统的数据中心部署应用程序与基于云的应用程序相结合。
每当您处理 Kubernetes 的不同孤岛时，真正有用的是单一管理平台。如果您使用多个云提供商或在内部部署并使用云提供商，则需要能够使您对各种环境进行类似部署的工具。它有助于实现标准化并简化您的整体组织基础设施。
从数据中心和云，您可能会开始寻找更远的地方：到边缘。
组织越来越多地采用边缘计算，将应用程序放在它们可以增加价值的地方：餐馆、工厂和其他偏远地区。
但边缘带来了独特的挑战。硬件通常是低功耗的：您的集群可能是单节点设备。与站点的连接可能带宽较低或时断时续，这使得远程管理变得困难。有一个全新的安全领域需要考虑，防止硬件篡改。
而且还有一个问题：当我们谈论餐厅连锁店或工业建筑时，计算机可能需要部署到数百甚至数千个站点。每个站点都不会有 Kubernetes 专家——甚至没有常规的 IT 人员——来帮助接入新设备或在本地修复任何配置问题。
这些都是巨大的挑战，但有一些解决方案可以帮助您。
低接触或无接触入职技术意味着没有 IT 或 Kubernetes 知识的人应该能够拿起设备，插入电源和以太网，并自动完成配置，无需任何人为干预。 （查看此处的演示。）
此部署的先决条件之一是能够一次性从头开始配置整个集群，包括在底层设备上配置操作系统。当您可以以声明方式进行此类配置时，这会显着简化大规模部署。这里的想法是，供应应该自动开始并构建系统，直到它能够到达总部，您可以从那里集中管理部署。
一旦您的集群准备就绪，如果您的操作系统是不可变的，您可以进一步降低风险。它需要破坏的元素更少，因此它为您的集群提供了更可靠的基础。因此，请注意您选择的操作系统。市场上有许多开源和商业产品。查看这里比较以开始使用。
作为平台团队，在生产中扩展 Kubernetes 时，您几乎肯定会面临这些挑战。他们是令人生畏的，当然。但是您可以采取一些方法来取得成功。
云原生、开源 Kubernetes 生态系统非常庞大，您知道您并不孤单。您可以申请许多不同的项目。在 KubeCon 等活动中，您也可以借鉴丰富的社区经验。
但也许我们能提供的最重要的建议是：如果你想要扩展规模，不要 DIY 。
尽管可以从 DIY 开始学习和证明概念，但你应该知道，“自己动手做”的路径随着时间的推移变得越来越困难。我们已经不需要“用最艰难的方式实现 Kubernetes ”了。
下一个是什么？如果您有兴趣更深入地了解随着 Kubernetes 使用的增长您可能会遇到的挑战，请加入我们 4 月 27 日的网络研讨会。在这里注册！