kubelet 10250 证书（kubelet csi）

大家好，我是讯享网，很高兴认识大家。

支持开发人员和运维人员的 Kubernetes 平台应该赋予团队构建工作负载的能力，而不仅仅是基础设施。

译自，作者 Will Stewart。

正如在 2017 年所说，。Kubernetes 是为运维人员设计的，而不是为开发人员设计的。获取一个大型云托管的 Kubernetes 版本肯定会让你的运维团队感到高兴，但它也可能让你的开发团队感到不满。原因是不是开发人员需要的平台。它是一套复杂的原语，与他们的主要目标不一致：构建应用程序。

平台的定义在于你是否能够在其上构建。如果你是一名，Kubernetes 确实是一个平台。你可以在它之上构建你需要的任何东西。如果你是一名应用程序开发人员，Kubernetes 会让你感到不知所措。如果你是一名平台工程师，它也会让你感到不知所措！这可能是为什么许多基于 Kubernetes 构建的 (IDP) 项目会偏离轨道并被重新构建。尽管 Kubernetes 做了很多好事，但我们仍然缺乏一个开发人员喜欢的提交后平台。

让运维和开发都满意的目标是其他平台一直在努力解决的问题。随着我们进入，让我们重新审视它以及导致 Kubernetes 的其他一些平台。

在 2019 年，在 KubeCon 上发表了主题演讲“”。他大胆地指出。在 Kubernetes 世界中，YAML 清单意味着满屏的未定义字段和令人眼花缭乱的任务。这与的体验相去甚远。换句话说，YAML 对应用程序开发人员来说是错误的抽象。

Ruby on Rails 是一个在 (Linux、Apache、MySQL 和 PHP) 成为主导堆栈的时代构建的平台。与 Kubernetes 一样，LAMP 的问题在于如何让软件工程师能够使用它。

如今，Kubernetes 感觉就像 LAMP 中的 L。Linux 和 Kubernetes 都是其他组件构建其上的平台。Linux 绝对是一个操作系统 (OS)，而 Kubernetes 是云的操作系统。很难想象一个应用程序开发人员会处理内核级别的 Linux API。但在 Kubernetes 中，处理是现状。

讯享网

平台工程师需要一个平台，它不仅可以抽象掉复杂性，还可以让开发人员专注于编写他们获得报酬的代码。

Pivotal 的 (PCF) 是早期尝试提供一个复杂的平台即服务。他们准确地把握了简化应用程序部署和实现“你构建它，你运行它”理念的愿景。PCF 拥有像 Rails 一样的简单入门；不是，而是。体验感觉相似，但 Cloud Foundry 做出的重大飞跃是支持几乎所有语言和框架（不仅仅是 Ruby）。开发人员只需要提交他们的代码。PCF 是推动所有提交后操作的因素。

然而，该平台仍然需要大型团队来维护和运营，同时还需要大量的硬件投资，这些投资需要几个月才能完成。由于采用 PCF 所需的努力，它并没有完全发挥其潜力，也没有足够快地适应云原生时代。还记得 Kubernetes 缺少的部分是良好的开发人员体验吗？Cloud Foundry 缺少的部分是适应性和愉快的运维体验。

云原生生态系统更加健壮，问题规模也更大，考虑到与十年前相比，现在有更多软件工程师在交付工作负载——付出了相当大的努力，有时甚至不成功。

Cloud Foundry 在 2010 年代初崛起，与 Apache Mesos 处于同一时期。Mesos 与 PCF 处于光谱的另一端。它非常注重运维体验，但从未找到立足点。Heroku 来自同一时期，但专注于开发人员体验，同时隐藏了运维方面。

当 Kubernetes 崛起时，其成功部分归功于其灵活性。Kubernetes 比其他平台更成功的原因有很多。K8s 为云提供了标准 API，它是声明式的，并且其对容器的关注很好地抽象了虚拟机 (VM)。Kubernetes 成功的另一个原因是其组件可以互换。例如，发行版用更传统的关联数据库替换了。

Elastic Kubernetes Service (EKS)、 Kubernetes Service (GKS) 和 Azure Kubernetes Service (AKS) 的出现巩固了 Kubernetes 作为云的最终操作系统的定位——每个都有自己的特点和挑战。

值得记住的是，应用程序抽象仍然是平台构建者留下的任务。原因显而易见。您希望如何将代码从开发环境迁移到生产环境？每个团队和组织都会以略微不同的方式进行操作。在回忆“Kubernetes 是一个用于构建平台的平台”这句话时，这是一个需要牢记的重要细节。找到合适的数字体验 (DX) 是一项非常具有挑战性的任务。

那么，平台究竟应该是什么样子？大多数平台工程师都拥有一个共同的愿景：平台抽象了提交后的所有内容。这种抽象使开发人员能够以自助服务的方式交付工作负载。他们应该能够构建、部署和扩展工作负载，而无需成为基础设施专家。只要平台表面下方的 API 仍然可以进行调整，我们就拥有了一个成功的解决方案。

这一宏伟愿景转化为设计理念——最终转化为需求。以下是我在构建时所遵循的理念和需求：

从本质上讲，未来的平台应该使团队能够“构建工作负载，而不是基础设施”。

通过采用优先考虑开发人员体验而不影响操作灵活性的平台，组织可以加快交付周期、降低开销并保持竞争力。一个好的平台可以解放开发人员，让他们专注于自己的长处——编写代码——而运维人员则确保支持基础设施继续平稳运行。

DevOps 是关于将开发人员和运维人员团结在一起的。如果平台只迎合其中一方，那么它们就不是真正的平台。在参加 KubeCon 2024 时，我会牢记这一点。在主活动中，有超过，以及一个完整的。

我在这里分享的内容来自我在上使用 Kubernetes 构建平台的经验。如果您在 KubeCon 上看到我，我很乐意听取您的想法。是否可以构建一个成功的平台，而该平台不优先考虑 DevOps 的任何一方？您在构建 IDP 时遵循哪些理念？您认为平台工程面临的主要挑战是什么？

要详细了解 Kubernetes 和云原生生态系统，请加入我们参加 KubeCon + CloudNativeCon 北美，活动将于 2024 年 11 月 12 日至 15 日在犹他州盐湖城举行。

kubelet 10250 证书（kubelet csi）

相关推荐