Kubernetes 是一个半空还是半满的杯子？这取决于你如何看待它！在我看来，Kubernetes 的编排功能相当复杂，即使是经验丰富的从业者，也经常会因此而撞得头破血流。与此同时，我也经常向新手用户推荐它，甚至在技术债务能力比较有限的业务案例中也推荐它，这样做的目的是为了更聪明地工作，而不是更辛苦地工作。我现在作为自由职业者从事第二份兼职工作，为一家小型非营利组织维护系统。因此，当我每天没有 8 个小时可以照看孩子时，我可以把越多的重活儿交给 K8s，我们大家的生活就越美好。更妙的是，如果我在一家大型企业工作，每天有 8 小时的保姆时间，我还是更愿意利用 K8s 的力量来替我完成大部分工作。这就是 "半杯水 "的观点--把 K8s 看作是让你的生活更轻松的盟友。说出你想要什么，让它做它最擅长的事情。
由于这种方法似乎过于简单，我还要指出我们把事情搞得过于复杂的倾向。例如，当我们为一些 "面向未来 "的解决方案过度设计，而这些解决方案甚至还没有出现在地平线上时，或者当我们重新发明轮子，而不是使用经过实战检验的工具来完成任务时。对平台工程的深入研究也不例外，但我们将在后续文章中详细介绍。
K8s 是一个强大而复杂的有机体，但请记住，我们的许多业界同行都为使其 "能够正常工作 "倾注了大量心血，就像学习驾驶汽车一样，最好的学习方式就是亲身实践。
我第一次接触 Kubernetes 要追溯到 2019 年，当时我们在 Linode 客户支持团队的第一线发布了 Linode Kubernetes 引擎（LKE）。这是一个我们无法回避的沉浮时刻，因为用户的需求实在是太庞大了。我们必须支持这个产品，这意味着我们必须学习它，更好的是......排除它的故障！尽管有时令人沮丧，但这些都是我职业生涯中最宝贵的经历。
在本文中，我们将根据像我这样的实际经验，探讨学习和管理 Kubernetes 的一些策略。
在实践中学习
真正了解平台的最佳方式是通过构建和 破坏东西。将文档和教程结合起来，是获得工作集群的好方法。把你的清单放到 Git 仓库中，你就有了一个可以永远参考的模板。接下来，找到一种有趣的方法来破坏它。这可以是让朋友或同事试一试，这样在开始诊断之前，你根本不知道问题的根源。或者，我用过的另一种方法是做一些比指南中演示的更复杂的事情。例如，假设你正在学习 Linux 基金会提供的CKAD 课程。他们可能会指导你构建一个简化的集群，其中只有一个控制平面和一个工作节点。相反，你可以尝试成功启动一个包含三个控制平面节点（用于高可用性）和三个工作节点的集群。如果这还不够具有挑战性，还可以尝试实施 VPC 并自定义群集网络寻址，以避免 IP 空间的碰撞。即使你在一段时间后感到沮丧而放弃，你也会学到很多东西。以上只是我亲身经历的两个例子。天无绝人之路。
此外，Minikube或Kind等工具对于在接触云中的任何东西之前进行本地化实验也非常有帮助。 无论您如何破解、排除故障和修复集群，都要确保留下一些文档记录。将文档写出来对你的记忆很有帮助，因为它要求你清楚地说明步骤和解决方案。如果您有时间将其公布于众，您不仅可以炫耀自己出色的故障排除方法，还能帮助同行。
将故障排除作为一种学习途径
关于排除故障的方法，本身并没有 "最佳实践"，只有 "你的实践"，也就是说，你应该找到最适合你的 "痒点"--不管是什么。重要的是，你要有意识地为自己打造这块肌肉，随着时间的推移，它会变得越来越容易。我见过的最优秀的故障排除者正是通过多年的努力才成为最优秀的，因此，我可以把任何东西扔到他们面前。因此，他们也是最有耐心的学习者。
以下是一些对我最有效的技巧：
- 分而治之：将问题一分为二，系统地排除潜在原因。对有些人来说，有条不紊地逐一排查更容易些，但我通常会直接跳到我能首先排除的问题上，从而取得成功。这是否违背了其他人的合理建议？有可能！但我更关心什么对我有用。
- Monitoring 和可观察性是你的朋友，错误也是：度量指标、日志和跟踪可以描绘出系统的整体视图，更好的是，还可以描绘出问题的整体视图！Prometheus 和Grafana 是事实上的监控工具，也是您选择日志聚合和跟踪工具的好帮手。然而，在现实世界中，你并不总能拥有一个完整的可观察性堆栈--有时，你能得到的最好的东西就是Prometheus 和Grafana以及一些远程目标来进行搜刮。幸运的是，这在很多时候还是很有用的，不管有没有，都要把错误信息当作朋友来对待！当然，有些错误信息比其他信息更有用，但无论如何，这都是系统反馈的信息，说明出了问题。
- 重现问题：尽可能在单独的环境中重现问题。这样做可以提供大量有关原因的信息，为找到解决方案打开大门。这也意味着你有了一个可以安全地进行实验的测试环境。利用基础架构即代码（IaC）的强大功能是一种很好的做法，其中一个原因就是能够根据需要快速重建或破坏这种环境。即使这意味着要自己编写，但在环境之前未编入代码的情况下，前期在这方面多花一点时间，之后就能节省大量时间。
- 保存故障排除日志：您可能对架构决策记录/日志的概念并不陌生。有什么能阻止你将类似的概念应用于故障排除呢？没有什么！而且不需要任何特殊格式或惯例。只需记录您的故障排除步骤即可。如果需要回溯或重新确认已经排除的故障，这将非常有用。最重要的是，您可以稍后查看，记录解决方案并解释您是如何达到目的的。能够清楚地说明步骤及其背后的逻辑，可以在你的记忆中留下更永久的痕迹。这也会证明对任何阅读你的文档的人都是有用的。在内部知识库平台上，甚至在面向公众的博客上向他人传授知识，都是很好的记录方式。
在遇到特别棘手的问题时，将故障排除作为一个学习机会，可以长期提高解决问题的技能，并有助于改进管理基础架构的方式。完善和迭代调试流程的团队会发现自己更有能力享受 Kubernetes 的强大功能。
使用简单可靠的技术
云原生生态系统（以及整个云环境）提供了大量可拼接的工具和框架。您可以构建的可能性几乎是无穷无尽的！然而，这种想法往往会导致一些重大陷阱：太多的工具、太复杂和太多的技术债务。幸运的是，这个陷阱很容易避免，只需一点纪律和一种心态：少即是多。最好的技术就是最易维护、最稳定的技术，你会发现你的用户也会同意这一点。如果你需要爬梯子上房顶，你不会希望梯子设计得过于复杂，以至于你怀疑自己是否正确使用了梯子。那样会让人害怕！
维护一个复杂到没人能读懂的代码库并不值得骄傲。建立一个复杂到几乎无人能用的系统，也不会获得金牌或奖杯。我们需要的是能正常工作、稳定运行、能可靠地正确使用而无需付出更多努力的系统。在这里，简单就是你的朋友。此外，请记住，云原生设计模式是一种接受快速变化的模式。随着时间的推移，您的应用架构自然会变得越来越复杂，因此没有必要强求。除了模块化的云原生设计外，采用极简的方法，团队可以拥有更精简、更安全的系统，并简化部署、维护和故障排除。
此外，保持简单还有助于降低错误配置的风险，以免造成性能瓶颈和/或增加安全漏洞的攻击面。
Kubernetes 本身就是一种抽象。如果不是这样，我们就不能称其为 "云原生"，但减少不必要的抽象意味着工程师可以花更少的时间管理底层的复杂性，而将更多的时间专注于交付价值。在这里，我坚持自己的观点，反对 "包治百病 "的方法，因为在我的职业生涯中，我所见过的最先进的创新都来自于那些体现了 "严格饮食 "方法的公司；那些专注于掌握基础知识的公司，这样他们就能安全可靠地构建一些非常尖端的产品，解决一些非常复杂的问题。
继续掌握 Kubernetes
将实践经验、强大的故障排除方法和深思熟虑的工具方法相结合，可以让 Kubernetes 更容易掌握。在实践中学习（而不仅仅是阅读）有助于培养解决问题的技能，这些技能在实际操作中至关重要。排除故障不仅仅是为了修复故障；这也是一个完善理解、改进文档和开发系统化方法的机会，使未来的挑战更容易解决。通过尽量减少不必要的抽象来简化 Kubernetes 堆栈，可以降低认知开销，使其更易于长期管理。
正如许多经验丰富的从业者所了解的那样，一个精干、结构合理的集群比一个被过多工具所累、增加了复杂性却没有带来明显效益的集群更容易维护和扩展。归根结底，Kubernetes 的成功并不在于使用市场上的所有新工具，而在于了解哪些工具能带来长期的真正价值。
如果你想了解更多有关 Kubernetes 的信息，我将在 KubeFM 播客中详细介绍，你可以在 YouTube或下面观看。
注释