Kubic 现在已成为认证的 Kubernetes 发行版

由 Richard Brown 于 2019年1月22日发布于 kubic.opensuse.org

openSUSE Kubic 团队自豪地宣布，自 昨天 起，我们的 Kubic 发行版已成为认证的 Kubernetes 发行版！值得注意的是，它是第一个使用 CRI-O 容器运行时 通过认证的开源 Kubernetes 发行版！

什么是 Kubernetes 认证？

容器技术，特别是 Kubernetes，正变得越来越普遍，并被全球各地的爱好者、开发者和公司广泛采用。围绕这些技术正在演进一个庞大的生态系统。越来越多的开发者首先以容器的形式构建他们的软件，通常将 Kubernetes 作为编排这些容器的预期平台。坦率地说，他们希望他们的软件能够正常工作。

但 Kubernetes 并不像其他具有这种广泛采用的软件一样。即使它被用于各种规模的场景，从小型的开发者实验室到大型的生产基础设施系统，Kubernetes 仍然是一个快速发展的项目，新版本出现频率很高，支持寿命也比其他类似项目短。这给那些希望下载、部署和运行 Kubernetes 集群并确信他们可以在其之上运行所需内容的人带来了真正的挑战。

考虑到快速移动的代码库以及提供或与 Kubernetes 集成的各种解决方案，这涉及很多活动部件，由很多人提供。这可能会让一些人感到风险，并怀疑为 Kubernetes 构建的某些东西可能无法在明天正常工作。

幸运的是，云原生计算基金会 (CNCF) 正在解决这个问题。CNCF 致力于围绕开源容器软件构建社区，并建立了Kubernetes 软件一致性认证 以进一步实现这一目标。经过 CNCF 验证的 Kubernetes 解决方案。他们检查版本、API 等是否都正确、存在并按预期工作，以便用户和开发者可以确信他们的基于 Kubernetes 的解决方案现在和将来都能轻松工作。

为什么要认证 Kubic？

openSUSE 项目在解决快速移动软件的发布问题方面有着悠久的历史。

Tumbleweed 和 Kubic 同时是两个最快且最稳定的滚动发布发行版。

借助 Open Build Service 和 openQA，我们已经建立了一个管道，保证只有在构建和集体且可重复地测试后，我们才会发布软件。

我们使用 btrfs 和 snapper 的经验意味着，即使系统发生不希望的（或天哪，损坏的）更改，用户也可以立即回滚到可以正常工作的系统状态。

通过事务更新，我们确保对正在运行的系统绝不进行任何更改。这进一步保证了任何回滚都可以将系统恢复到单个原子操作中的干净状态。

在 Kubic 中，我们利用所有这些来构建一个优秀的容器操作系统，为用户提供最新版本的令人兴奋的新工具，例如 Podman、CRI-O、Buildah 和（当然）Kubernetes。

我们正在跟上所有这些快速移动的上游项目，通常在发布上游版本后的几天甚至几个小时内发布我们的软件包。

但我们小心谨慎，不会给用户带来风险，Kubic 与更大的 openSUSE Tumbleweed 发行版同步发布，共享相同的测试和发布管道，因此我们可以确信，如果任何一个发行版进行破坏另一个发行版的更改，都不会向用户发布任何内容。

所以我们已经解决了所有快速移动软件的问题，为什么要认证？ 😉

好吧，尽管这让我很痛苦，但无论我们的代码审查、构建、测试和发布有多么出色，我们永远无法捕捉到所有内容。即使我们做到了，最终，我们所能说的就是“我们做得很棒，相信我们”

考虑到我们在 openSUSE 中的工作方式，事情对新手来说似乎甚至更加复杂。

openSUSE 是一个真正开源的社区项目，任何人都可以贡献，将我们在 Kubic 中所做的事情直接更改以适应他们想要看到的内容。

这些贡献处于平等地位，SUSE 和 openSUSE 的其他赞助商必须以与任何其他社区成员相同的方式做出贡献。

我们希望获得更多贡献。 我们将保持 Kubic 的开放和欢迎，以适应您可能拥有的任何疯狂（或聪明，或疯狂聪明的）想法，用于我们的容器发行版。

但我们也希望其他人知道，无论我们最终做什么，人们都可以依赖 Kubic 来完成任务。

通过 CNCF 认证 Kubic，现在有一个公正的第三方检查了我们的工作，检查了我们正在分发的软件，检查了我们的文档，并授予了我们批准的印章。

因此，感谢迄今为止为 Kubic 做出贡献并使之成为可能的所有人，谢谢您。

感谢所有上游项目，没有它们，Kubic 将没有可以分发和认证的内容，谢谢您，很快会在您的 issue tracker 和 pull request 队列中与您见面。

并且感谢所有其他人，谢谢您，我们希望您玩得开心下载、使用并希望为我们的容器世界做出贡献。