openSUSE Kubic 迎来新方向

亲爱的社区：

自从 openSUSE 社区启动 Kubic 项目 以来，已经过去一年多，回顾过去几个月，评估我们的成功之处、不足之处，并与大家分享我们未来的计划，是有意义的。

未来稳定的基础

我们成功的大部分在于通常被称为 MicroOS 的领域，Kubic 堆栈中为运行容器提供稳定操作系统的那一部分，该操作系统是 原子性更新 的。

Kubic MicroOS 现在已完全集成到 openSUSE Tumbleweed 发布流程中，我们的 事务性更新堆栈也已移植 到常规 openSUSE Tumbleweed 和 Leap。

根据社区的反馈，新的 系统角色 已经进一步完善，现在包含开箱即用的完全自动更新。

这种合作正在继续，许多小的更改将很快应用于常规 openSUSE 安装过程，这些更改基于在调整 Kubic 中的安装过程中学到的经验。

回顾我们的初始前提

我们不仅仅忙于基础系统。我们对 无根容器 的努力仍在继续，现在您可以使用“Docker 替代品” Podman CRI-O 在 Kubic 和常规 openSUSE 中。但考虑到 Kubic 项目的初始前提，现在说我们没有达到最初的期望可能是安全的。

当我们于 2017 年 5 月开始时，SUSE 已经开始开发他们的第一个 SUSE CaaS Platform 版本。除了使 Kubic 成为最易于使用的社区 Kubernetes 发行版的一般目标之外，一个重要的前提是将其建立为 SUSE CaaS Platform 的“紧密上游”社区。为了以类似于 openSUSE Tumbleweed 和 SUSE Linux Enterprise 之间的关系的方式设置，计划将 SUSE CaaS Stack（包括 Velum 集群引导工具）重新基于共享的 Kubic/Tumbleweed 代码库。一年后，这个目标仍然难以实现。

这有许多原因，包括 Tumbleweed 令人惊叹的快速变化速度，以及 SUSE CaaS Platform 的初始设计方面，该设计是为 SUSE 商业客户的需求而构思的，在 Kubic 中开发的需求是事后才考虑到的。

显然，这种现状对所有参与 Kubic 的人来说都是一个难题，我们共同的感受是希望同时缩小 Kubic 和 SUSE CaaS 代码库之间的差距，同时跟上不断发展的容器格局，尤其是围绕 Kubernetes 的发展。

世界已经改变

提到 Kubernetes，值得考虑的是，自从 SUSE CaaS Platform 开发开始以来，Kubernetes 上游已经发生了多少变化。当时还没有通用的工具来设置和配置 Kubernetes 集群。这是创建 Velum 的主要动力，它是 SUSE CaaS Stack 的关键部分。然而，现在有多种工具，包括越来越流行的 kubeadm，它既可以独立使用，也可以作为许多大型解决方案的集成部分。

kubeadm 已经由 Kubic 社区中的许多人积极使用，并且也越来越受到 Kubic 团队中 SUSE CaaS 开发人员的关注，作为未来 SUSE CaaS Platform 版本的关键部分。

kubeadm 已证明自己是一个越来越成熟和灵活的平台，用于设置 Kubernetes 集群。其中包含许多令人兴奋的功能，我们真正看到了它为快速轻松地设置 Kubic Kubernetes 集群的潜力，符合我们使 Kubic 成为最易于使用的社区 Kubernetes 发行版的一般目标。

与团队讨论，我们都对将 kubeadm 作为 Kubic 的关键部分的想法感到兴奋，我们渴望将精力集中在这个方向上，这意味着 Kubic 的变化。

即将发生的变化！

这对 Kubic 用户和贡献者意味着什么？

• 我们将停止同步现有的 SUSE CaaS Stack 到 Kubic 的努力。现有的 Admin、Worker 和 Unconfigured 系统角色将很快被删除。

• 我们将专注于将 kubeadm 完全作为 Kubic 的一流解决方案。您很快就能看到这方面的新的安装选项和文档。

• SUSE CaaS Platform 团队完全支持这个想法，并将更积极地为 Kubic 做出贡献，研究将 kubeadm 用于未来 CaaS Platform 版本。

正如您可能想象的那样，这些变化可能会非常重大，因此请注意任何灰尘或干扰，因为我们正在将 Kubic 重新聚焦到这个新方向上。我们打算继续更新此博客以分享我们的进展，但最重要的是 我们不希望独自完成这项工作。

我们认为这个新方向 非常令人兴奋，我们希望更多的贡献者参与进来。因此，请考虑将第四个要点添加到上面的列表中

• 我们将做我们作为 Kubic 项目的贡献者所做的一切。作为 openSUSE 项目，首要理念 ‘行动者决定’ 适用。您可以帮助塑造 Kubic，使其成为 您 所需要的容器平台。

这个新方向只是这个更广泛故事的一部分，请不仅在您同意我们的地方做出贡献，还要分享您的想法并加入我们，以便我们可以探索我们甚至没有关注的方向。

我如何提供帮助？

鉴于我们立即的目标是 kubeadm 集成，参与其中最简单的方法之一是直接为 kubeadm 上游 做出贡献。

我们不希望维护大量的 Kubic 特定补丁，我们计划尽可能先进行上游工作，因此您在那里为 Kubic 所做的工作将大大帮助我们所有人。

加入 Kubernetes SIG Cluster Lifecycle 并直接与他们互动。您也会在那里找到我们，因为我们将减少潜伏并更多地参与其中。

在将上游代码压缩到集成解决方案时，我们将继续使用 openSUSE 构建服务 作为构建软件包、容器和 VM 镜像的首选平台。

为 Kubic 做出贡献将保持不变，遵循常规 openSUSE Factory 流程。

您将看到一些软件包从现有的 devel:CaaSP Devel 项目迁移到我们新的 Devel 项目 devel:kubic。这样我们就可以以全速在 devel:kubic 中移动这些软件包，而 devel:CaaSP 可以继续专注于 SUSE CaaS Platform 的需求。

很快还将有 devel:kubic:containers 和 devel:kubic:images 子项目，我们将在那里烘焙新的容器和 VM 镜像，因为我们弄清楚在那里需要什么。

这种新方法带来了额外的优势，即与以前相比，我们拥有更大的自由度来尝试新的方向并添加新的软件包和版本，而无需担心对我们的下游合作伙伴的影响。

所以如果您有任何想法，或者只是需要帮助开始贡献，请随时与我们联系！

• 您可以通过我们的新邮件列表联系我们 - opensuse-kubic@opensuse.org

• 要订阅，只需发送电子邮件至 opensuse-kubic+subscribe@opensuse.org

• 或者，如果您更喜欢 IRC 聊天，您可以在 irc.freenode.org 上的 #kubic 中找到我们。

我们目前正在使用此 Trello 板 来跟踪和组织我们的工作。

每个人都可以看到我们正在做什么，都可以发表评论，如果您想加入，只需在欢迎卡片上发表评论或通过其他方式与我们联系即可，以将您添加到板中。

我们很高兴将 Kubic 引入这个新方向，并希望更广泛的社区支持我们并加入，使 Kubic 成为最酷、最实用和最开放的社区 Kubernetes 平台。

谢谢，祝您玩得开心！