纯粹的上游Kubernetes是最好的Kubernetes

译文
云计算 云原生
Kubernetes趋于成熟后,市场已出现了合并,许多Kubernetes产品提供不同的架构、功能和接口——有些产品不如另一些开放、灵活,附有不同的限制、依赖项和许可条款。

​译者 | 布加迪

审校 | 孙淑娟

开源生态系统已从企业支持有限的小众项目迅速变成开发软件的默认方式。大大小小的组织都在使用开源软件加快创新和产品开发。

企业开源现状调查发现,95%的企业都很重视开源;75%的企业声称开源软件对IT战略极其重要;77%的企业计划在来年加大使用开源的力度。

与此同时,71%的英国政府技术员工表示,他们使用的开源软件比五年前更多。美国国防部甚至发布了一份备忘录,表明其首选是开源软件,而不是专有软件。

Kubernetes趋于成熟后,市场已出现了合并,许多Kubernetes产品提供不同的架构、功能和接口——有些产品不如另一些开放、灵活,附有不同的限制、依赖项和许可条款。

偏离开放的Kubernetes标准可能会导致问题。正如《云计算杂志》特别指出,“如果没有适当的标准化格式,就很难确保互操作性、可移植性、合规、信任和安全性。”

1、什么是纯粹的上游开源Kubernetes?

上游Kubernetes是Kubernetes的开源版本,由云原生计算基金会托管和维护,该基金会开发代码、编制文档,并贡献代码。它由核心的“普通”Kubernetes组成,用于编排容器,无需附加应用程序,一切都可以公开访问,用于检查、修改和重新分发。

免费开源软件项目都出于美好的初衷——创造有助于整个社区的技术。任何人都可以访问代码,进行协作以快速修复错误、添加补丁和优化性能。但是项目发展会导致目标和观点出现分歧,即代码中的“分叉”(fork)。

2、什么是Kubernetes的分叉?

Kubernetes的分叉是独立于主工作流开发的开源项目版本。当开发社区的一部分人或第三方供应商复制上游项目,但作了若干修改,以启动完全独立的开发路线时,就出现分叉。

分叉Kubernetes的原因可能是意见不同(技术上的或个人上的)、上游项目的开发停滞不前,或者想要不同的功能。这可能发生在开源环境或专有环境中。

开源Kubernetes分叉改进原始代码后,其他分叉可以利用它,将代码与各自的分叉结合起来,更好地满足开发人员和最终用户的需求。

但是就专有环境中的Kubernetes分叉而言,供应商或云公司将改变源代码以满足自己的需求,重新打包软件,并将其作为专有发行版提供给客户。它们可能会改变在生产环境中运行Kubernetes所需的附加组件。

这使得解决方案的管理变得很复杂,还存在供应商锁定风险。

3、分叉Kubernetes的问题

大规模部署和管理Kubernetes很困难。许多组织使用专有发行版来获得对容器平台的企业支持,但这导致了Kubernetes明显分叉的版本。

一些挑战包括如下:

(1)补丁、错误修复、升级和新功能方面很复杂

每一次新的更新都会使变更更难与自定义发行版兼容。这是一个缓慢而烧钱的过程。分叉Kubernetes的供应商常常使用较旧版本的集群API,因为它们需要花费至少6个月从上游获得改进和错误修复。

(2)供应商锁定

Kubernetes中的分叉会造成锁定,即客户无法轻松替换或迁移解决方案。它消除了在公共、私有和内部服务之间无缝移动应用程序和数据的灵活性。贵公司发展壮大后,锁定问题也无法为贵公司提供多种选择。即使源代码是开源的,供应商也可以用一些特性包装Kubernetes,这些特性防止客户迁移到其他平台。

(3)缺乏功能

Kubernetes的分叉版本可能会破坏应用程序的功能。一些自定义发行版依赖专有的API和CLI来获得完整功能,这导致了锁定现象。如果自定义发行版只在供应商的自定义Linux内核上运行,它也导致锁定现象。最终,维护这个分叉变得更困难,阻止人们在未对补丁和功能兼容方面进行重大工作的情况下将最新的上游补丁合并到分叉中。如果一种产品关停,您可能就不走运了。

(4)不太安全

Kubernetes的分叉可能会运行不太安全的代码。如果在开源代码中发现了一个漏洞,并由上游社区修复,分叉版本的代码可能不会受益,因为它与上游代码不一样。

(5)缺乏互操作性

供应商可以针对其自定义发行版或让Kubernetes在生产环境中运行所需的支撑性应用程序修改代码。虽然Kubernetes的修改版可以与特定供应商的应用程序堆栈和管理工具协同运行,但这些专有的修改会导致您被定制的组件构建束缚,让您无法与其他上游开源项目集成。如果他们的堆栈包含多个产品,很难实现互操作性,这可能会在您扩展规模时导致许多下游问题。

(6)技术债务

很难将一个与上游发生了巨大变化的分叉合并回去。我们称之为技术债务,即偏离联合开发的主分支导致的维护源代码的成本。对分叉代码的变更越多,就意味着让分叉重新回归上游项目所需的资金和时间就越多。

4、纯粹的上游Kubernetes是出路

纯粹的上游开源Kubernetes是决策制定的焦点,是贡献代码的地方,带有一个内置的社区,不断改进源代码。

纯粹的上游解决方案允许与更大的社区分享想法,并获得上游接受的新功能和新版本。每个基于上游的项目和产品在选择未来版本或合并最近(或所有)的上游补丁时,都受益于 以前的工作。

虽然任何人都可以从上游代码库复制、安装或分发Kubernetes,但大公司和大组织需要经过认证、测试和加固的产品供企业环境使用。因此,组织依赖供应商将上游Kubernetes变成满足其业务需求的下游产品。

原文链接:https://www.cncf.io/blog/2023/01/30/pure-upstream-kubernetes-is-the-best-kubernetes/

责任编辑:武晓燕 来源: 51CTO技术栈
相关推荐

2018-07-30 11:53:04

Kubernetes无服务器容器

2023-03-06 00:27:02

Kubernetesscheduler系统

2023-03-03 11:12:34

Kubernetes控制器后端

2020-02-25 17:21:40

云上游云计算企业

2021-02-26 14:40:16

Kubernetes调度器

2021-03-16 11:01:02

KubernetesCLI技术

2021-09-07 09:18:18

Kubernetes负载均衡服务发现

2022-06-27 09:00:00

Kubernetes云计算容器

2018-12-14 08:00:00

2022-06-10 18:59:53

容器Kubernetes

2023-09-21 07:24:52

2020-07-28 10:32:56

云计算容器Kubernetes

2021-11-17 09:00:00

Kubernetes集群容器

2020-06-02 10:43:54

Kubernetes容器服务

2023-06-19 15:11:39

Kubernetes开发容器

2017-01-21 10:31:01

云计算迪斯尼

2019-09-23 13:37:09

Anthos谷歌Kubernetes

2019-10-24 10:25:32

Kubernetes网络集群

2024-02-29 08:02:27

KubernetesDaemonSet集群

2023-07-04 11:06:24

Commvault
点赞
收藏

51CTO技术栈公众号