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

什么是 Kubernetes 认证？

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

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

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

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

为什么要认证 Kubic？

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

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

凭借 Open Build Service 和 openQA，我们已经建立了一个流程，保证我们只在软件构建和测试完毕（集体且可重现）后才发布软件。

我们对 btrfs 和 snapper 的经验意味着，即使在系统发生不受欢迎的（或者天哪，损坏的）更改的情况下，用户也可以立即回滚到他们想要的工作系统状态。

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

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

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

但我们小心谨慎，不会给用户带来风险，而是与更大的 openSUSE Tumbleweed 发行版同步发布 Kubic，共享相同的测试和发布流程，这样我们就可以确信，如果任何一个发行版做出破坏另一个发行版更改，都不会向用户发布任何内容。

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

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

而且，考虑到我们在 openSUSE 中的工作方式，事情对新手来说可能会显得更加复杂。
我们不像其他拥有公司赞助商控制权并严格控制我们所做事情的开源项目。

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

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

我们希望获得更多贡献。 我们将保持 Kubic 的开放和欢迎，接受您可能对我们的容器发行版提出的任何疯狂（或聪明，或疯狂聪明的）想法。

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

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

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

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

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