在这篇博客中，我将评论怎么经过专心于 Kubernetes 的 API 来释放其潜力，一起尽量防止或许遇到的复杂性。了解怎么以及是否能够让 Kubernetes 为您发挥作用。
译自Why Kubernetes? Focus on the API， not the servers。作者 Tibo Beijen 。
跟着咱们从 2023 年进入 2024 年，现在是进行反思的好时机。无可争议，上一年最大的话题之一是 AI 的鼓起。但是离我的日常作业更近一些，有一些作业特别有目共睹:
- 亚马逊Prime 从无服务器微服务转向“单体”的博文。随后有许多的温吞吞的点击诱导文和“我的技能栈比你的好”类型的评论。从Jeremy Daly 的这篇文章开端，挑选关于这个主题的一些必读和防止的文章。
- 交际媒体便是交际媒体: 关于简直所有技能主题的辩论，包含“Kubernetes 单枪匹马让咱们的职业倒退了十年”，正如 Kelsey Hightower所说。或许 37signals退云并避开 Kubernetes 的举动。
- Datadog 的宕机。由多种要素一起导致，能够用关键词概括: Kubernetes、Cilium、eBPF、Systemd、OS 更新。Gergely Orosz(The Pragmatic Engineer)对此进行了很好的解释。
运用并喜欢Kubernetes，阅览所有上述内容，很简略会反思这个问题“我卷入了什么？”。或许在更广泛的意义上: “咱们这个职业卷入了什么？”。
在我看来，评论Kubernetes的价值和本钱不该仅仅局限于“服务器与无服务器”或“简略与复杂”。而应该重视在什么时候(假定这一点的确存在)，Kubernetes的优点开端超越其带来的应战。
因而，让咱们重视Kubernetes现状，它的优势，并寻找防止其复杂性的方法。
声明: 呈现一些供货商的称号或标志。我不为任何厂商效能，也不该将其解释为建议优于或许存在的类似处理方案。
多功能性
Kubernetes无所不在: 它能够促进各种作业负载在各种环境中运转:
Kubernetes无所不在
如上图所示，能够在从大型云到小型云，再到内部数据中心甚至边际核算的各种环境中运转Kubernetes。
重视作业负载类型，Kubernetes能够做许多作业。但也存在Kubernetes或许不特别适合的作业负载类型。在单体方面，能够想象(遗留)的大型机。或难以容器化的依据VM的应用程序。
大型云渠道供给许多保管服务，包含数据库、内存存储、音讯组件以及专心于AI/ML和大数据的服务。关于这些服务，你_能够_在Kubernetes内运转与云和渠道无关的原生云替代方案。但这需求更多前期作业，潜在收益因情况而异。
然后在微的另一端，大型云渠道供给“无服务器”: 函数即服务，一般与 API 网关等组件严密集成，并具有用于作业驱动架构的构建块。例如，能够决议在 Kubernetes 中运转这些函数，运用Knative。但这需求先设置和支撑这些组件，而在这方面，云更简略上手。另外，无服务器以快速扩展和缩放到零作为差异特征。
Kubernetes 能够为其用户供给标准化的作业方式(大致是:将 YAML 放入集群)，为渠道团队供给共同的方式来支撑工程团队(大致是:帮助拟定适当的 YAML 并帮助将 YAML 放入集群)。它能够经过利用和集成大型云渠道的保管服务来做到这一点，而不是试图替换它们悉数。
关于这种标准化我将在后边具体阐明。
为什么以及怎么
作为一个安排，重要的是要很好地舆解为什么挑选一个(技能)战略以及期望是什么。
如本博客文章的标题所示，清晰回答“咱们为什么运用 Kubernetes？”这个问题很重要。但假如“Kubernetes”是安排面对的各种应战的逻辑答案，那么这或许会更好。例如:
- 咱们怎么有效运转许多容器化的作业负载？
- 咱们怎么让一个云专家团队经过供给黄金路径和防护栏来赋能许多工程团队？
- 咱们怎么以与咱们现已有的软件交付流程坚持共同的方式在边际运转应用程序？
- 咱们怎么答应工程团队在咱们内部的数据中心布置应用程序？
- 咱们怎么在为咱们重要的当地供给灵活性的一起，标准化咱们的作业方式？
- 咱们怎么保证咱们出资的常识和东西尽或许广泛适用(例如不限于单一云供货商)？
是的，终究一点听起来有“多云”和“供货商确定”的意思。清晰一点: 仅仅由于其他当地核算更廉价就切换云，简直从不划算。仅仅为了“多云”而运用多云的公共部分，也简直从不划算。供货商确定无处不在，不仅仅是在挑选云时。但是，从多年的时刻跨度来看，安排或许会看到专心于跨供货商鸿沟适用的技能的优势。
制作摩天大楼
采用 Kubernetes 的进程中，在 Kubernetes 开端产生价值之前，需求设置许多东西。咱们正在制作一个渠道。让咱们用物理国际修建的类比来阐明:
建立渠道
在底部，咱们找到了根底。它之所以在那里，是由于它需求在那里，但没有人单纯为了有个根底而建立根底。在 Kubernetes 的术语中，根底包含网络(CNI)、存储(CSI)、容器运转时(CRI)、虚拟机或裸机服务器以及操作系统等组件。
接下来是地下室。与根底类似，这不是终究目标(除非你在建地下停车场且上面是一个公园)。它包容了你一般以为理所当然的东西。设备、保护间、管道等等。在 Kubernetes 中，这对应于在上线之前需求的一些基本要求: 可观测性和安全性。证书办理。或许是一个战略引擎。
终究，咱们进入地上以上。这便是咱们要制作的: 有目的的修建！在 Kubernetes 的术语中，这些显然是被布置的应用程序。但也包含增强咱们渠道才能的组件。例如 ArgoCD/Flux(运用 GitOps 进行高效布置)、Argo Workflows(作业流引擎)和 KEDA(更智能的扩展)。
现在，关于每个组件，能够争论它是根底、地下室仍是修建。也许 ArgoCD 和 KEDA 更像地下室而不是修建。或许 CSI 也是地下室，而不是根底，由于你能够相对简略地添加或删去存储类。
重要的是，从地下向地上以上，咱们能够观察到组件:
- 变得越来越明显
- 一般来说跟着时刻的推移变得更简略习惯
- 从仅仅本钱变为产生价值
重视点: 不要无处不在
安排需求当心，不要花费许多时刻在根底和地下室上，一起缺乏资源在地上以上制作好东西。
与此一起，你只能在坚实的根底之上制作。地下室也不该该坍塌。
咱们需求重视点。假如在大型云中运转，所有根底组件以预制的方式存在。咱们应该首先考虑这些。
相同，在地下室层面，咱们能够花许多时刻建立一个可观测性渠道。但存在各种 SaaS 处理方案或云供给商供给的处理方案。安全性也是如此。假如预制组件不满意要求，仔细检查这些要求。咱们确定拟议的更简略的处理方案是否“足够好”吗？咱们能否现在满意于一些简略的东西，以后再改善？
在边际运转时，重视操作系统和网络至关重要:咱们需求能够在不破坏网络和确定自己的情况下安全地更新长途设备。另一方面，在云中运转时，优先考虑云供货商供给的处理方案，就此打住。
在私有环境运转时，咱们或许需求高功能的存储处理方案和有状况作业负载的备份处理方案。但是在云中运转时，咱们不需求在Kubernetes中自己搭建数据库。考虑运用保管数据库，供给您需求的所有巨细调整选项和点时恢复。运用与S3兼容的对象存储来存储文件。运用SaaS进行可观测性，防止存储所有日志，指标和追踪。这样能够使存储需求最小化，使咱们的设置坚持简略。
复杂性预算
向集群添加的任何自界说或组件都会添加复杂性。它需求第1天的设置和第2天的保护，并且经过这种方式，它需求资源。这意味着咱们能够接受的复杂性数量是有限的。
尽管依据您问询的人，界说的鸿沟或许会有所不同，但咱们能够将咱们渠道上的每项自界说或添加视为本钱开销: 这是咱们期望从中取得出资报答的前期费用。
只需咱们在本钱开销上的花费终究削减或许至少稳定咱们的全体运营开销，咱们的运营便是可继续的。假如不是，假如运营开销占了优势，咱们就会遇到问题。
才能
这并不意味着咱们永久不该该向咱们的渠道添加任何组件。当咱们的运营范围扩大时，复杂性也会添加。咱们需求应对这一点的方法。顺便说一句，这不仅仅是Kubernetes所特有的。
这的确意味着咱们应该考虑什么时候添加组件以及它们对未来的全体作业量有何影响。
当避开了地表以下的一些复杂性陷阱时，Kubernetes 供给的共同 API 和作业方式就能够开端产生报答。让咱们举个比如:
应战: 咱们有一个 Kubernetes 设置。团队正在布置应用程序。但是，咱们注意到作业负载有时无法接受重新调度。此外，共同的标记也有点问题。
改善: 咱们添加了一个战略引擎。这有助于咱们实施良好的实践。
新状况: 团队将 YAML 放入集群。集群有时会说不。
应战: 咱们注意到咱们开端有许多布置流水线。并且它们都略有不同。咱们越来越难以将咱们集群中应运转的内容与这些流水线相关起来，而这些流水线首要由各个工程团队办理。
改善: 咱们添加了 GitOps。咱们现在有一个单一的窗口，依据拉取请求的作业流程来布置更新。咱们现已有依据 PR 的作业流程，所以这很适宜。当然，咱们能够自动化某些更新，以防止不必要的拉取请求。相同值得注意的是，经过别离 CI 和 CD 流水线，咱们的流水线能够变得十分简略。
新状况: 团队将 YAML 放入 git。GitOps 将 YAML 放入集群。集群机制使作业产生。
应战: 一些团队注意到他们需求比依据 CPU 的作业负载缩放更“智能”的东西。
改善: 渠道团队设置 KEDA。由于现已有了一个战略引擎，所以很简略为 KEDA 缩放器配置设置一些防护栏。
新状况，就像曾经相同: 团队将 YAML 放入 git。GitOps 将 YAML 放入集群。集群机制使作业产生。
应战: 渠道团队注意到大多数需求为工程团队完结的更改归结为相同的作业:为新服务供给命名空间、工件存储库、数据库、Redis、流水线、IAM 标识或队列。
改善: 在 POC 之后，渠道团队决议设置 Crossplane，调整战略引擎以答应一组受控的 Crossplane 资源，并供给防护措施。现在，团队能够自己设置资源。与此一起，渠道团队能够继续重视供给和保护这种才能，而不会被“许多类似使命”淹没。
新状况，就像曾经相同: 团队将 YAML 放入 git。GitOps 将 YAML 放入集群。集群机制使作业产生。
应战: 渠道团队注意到跟踪组件更新需求越来越多的努力。
改善: 在 POC 之后，他们设置了Renovate。现在，渠道团队不再需求检查渠道中运转的每个组件的发布页面。
新状况，与曾经十分类似: Renovate 将 YAML 放入 git。GitOps 将 YAML 放入集群。集群机制使作业产生。
上述更改不是一夜之间就能完成的。此外，它们有时触及改变一个安排中的作业方式，这一般比技能部分更难。但是，它们的确展示了，在一个当地谨慎地承担额定的复杂性，能够削减安排内的全体运营作业量。
API 思维方式
在采用 Kubernetes 时，依据安排、经验和文明的不同，或许会有不同的视角:
- 自下而上: “咱们运转服务器，并在其上面布置 Kubernetes”
- 自上而下: “咱们运转 Kubernetes，可巧需求服务器”
前者倾向于防止更改并专心于正常运转时刻。
后者将频频的受控更改视为满意各种需求的一种手段。
这是一个纤细的差异，但你或许现已猜到了，在运用 Kubernetes 时，自上而下的思维方式更适宜。长时间来看，它将带来一个更易于保护的渠道。一些比如:
不要: 设置对服务器的 shell 拜访以用于办理目的。
而要: 重视怎么防止登录(生产)服务器的需求。咱们需求发送出什么可观测性数据？咱们怎么在实验室设置中重现过错场景？
不要: 研讨怎么就地修补节点，以及随同而来的整个编排、检查和重启进程。
而要:考虑不可变的根底设施。经常用打了补丁的节点简略替换旧节点。这是一个易于重现(在非生产环境中测验)和可逆的进程。额定收益:混沌工程。
**不要:**运用Ansible在服务器上“做作业”
**而要:**重视不可变根底设施和cloud-init，履行肯定必要的少量安装步骤。
**不要:**运用可观测性代理、EDR代理等扩展VM镜像
**而要:**更青睐daemonsets，依据需求具有安全上下文，来运转这些进程。记住飞轮效应:咱们现已有方法能够轻松地将作业负载放入集群，并具有监控组件的所有可观测性。此外，Renovate 将帮助咱们坚持组件的更新。
上述的重点是，咱们需求防止终究落入十年前的状况(办理许多VM)，另外，还要办理许多Kubernetes的移动部件。咱们需求利用Kubernetes使VM办理部分变得更简略，或完全消除。这将留出空间来重视渠道和开发人员体验。
结论(也称 TL;DR)
在必定规划下，跟着团队数量的添加，安排将面对以下应战:
怎么供给防护栏而不会终究造就门槛?
合规、安全、本钱效益、功能和灾难恢复等主题都需求处理。将这些问题委托给每个团队处理既没有功率，对团队也是一个搅扰，并且要求每个团队对这些主题有足够的常识。因而，安排需求一种方法来整合这些常识，并将其应用于所有团队。简而言之，这便是为什么“DevOps”这个流行词语现在被“渠道工程”所替代的原因。
大规划运转时，Kubernetes在2024年也能够成为构建这种渠道工程的适宜技能栈。但危险很高:或许带来巨大报答，但在开端回馈之前需求前期投入。这对进入构成了必定的危险和障碍。
比较技能栈
如上图所示，在技能栈之间，存在出入平衡点。请注意，这是概括性的: 是否存在以及出入平衡点在哪里取决于安排是否成功操控总体作业量在限制范围内。咱们能够了解到的是，由于其本质，Kubernetes十分适合缩放初始作业量到许多团队。
假如不首要重视规划: 在边际运转时，Kubernetes或许会成为一个风趣的挑选，它自然地集成到您运转集中式应用程序的方式中。
但是，Kubernetes或许根本不适合您的安排:
- 需求在云中运转“一些”应用程序的创业公司?除非您对此有清晰目标，否则不要首先构建 Kubernetes。
- 没有集中式渠道团队的自治团队?您需求_一些东西_来防止每个团队略微不同地重造 DevOps 车轮。能够是 Kubernetes。
- 实际上并没有运转太多容器，而是运用无服务器?太棒了，建立您的安排以继续改善_那个_技能栈。不要由于“人们正在运用 Kubernetes”而考虑 Kubernetes。
明智地花费您的复杂性预算。挑选 Kubernetes 时，重视 API，您甚至或许会忘掉服务器。
只需防止陷入外表以下而忘掉享用阳光即可。
- 防止过滤泡沫，过滤无意义的噪音和仅为了引发互动的随机事物列表，交际媒体上仍有许多洞见和观点能够获取。
- 幸运的是，现在有足够的东西能够满意任何人对纯 YAML、模板化 YAML、编程 YAML 或转换为 YAML 的 JSON 的偏好。
- 检查团队拓扑，当我说到“渠道团队”或简略的“团队”时，它们别离指“渠道团队”和“流共同型团队”。
- 罪行，去过那里。与办理 daemonset 比较，扩展 AWS AMI 十分费事。
本文在云云众生（yylives.cc/）首发，欢迎我们拜访。
