亲爱的社区成员：

自从我们开始 Kubic 项目以来已经一年多，值得回顾过去几个月，评估我们的成功之处、不足之处，并与大家分享我们未来的计划。

面向未来的稳定基础

我们大部分的成功都集中在通常被称为 MicroOS 的领域，这是 Kubic 堆栈的一部分，它提供了一个稳定的操作系统，可以原子性地更新以运行容器。

Kubic MicroOS 现在已完全集成到 openSUSE Tumbleweed 发布流程中，我们的 事务性更新堆栈也已移植到常规的 openSUSE Tumbleweed 和 Leap。
根据您的反馈，新的系统角色 已进一步完善，现在默认情况下包含完全自动化的更新。

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

回顾我们的初始前提

我们不仅仅忙于基础系统。我们对 Rootless Containers 的努力仍在继续，现在您可以在 Kubic 和常规 openSUSE 中使用“Docker 替代品” Podman CRI-O。但是，在考虑 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 用户和贡献者意味着什么？

• 我们将停止同步 Kubic 上的现有 SUSE CaaS Stack。现有的 Admin、Worker 和 Unconfigured 系统角色将很快被删除。
• 我们将专注于将 kubeadm 完全用作 Kubic 上的第一类解决方案。您可以期待看到这方面的新的安装选项和文档 很快。
• SUSE CaaS Platform 团队完全支持这个想法，并将更积极地为 Kubic 做出贡献，研究将 kubeadm 用于未来 CaaS Platform 版本的潜力

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

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

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

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

我如何提供帮助？

鉴于我们立即的目标是 kubeadm 集成，参与其中最简单的方法之一是直接为 kubeadm 上游 做出贡献。
我们不希望维护大量的 Kubic 特定补丁，我们计划尽可能先在 upstream 完成我们的工作，因此您在那里为 Kubic 所做的工作将极大地帮助我们所有人。
加入 Kubernetes SIG Cluster Lifecycle 并直接与他们互动。您也会在那里找到我们，因为我们将减少潜伏并更多地参与其中。

在将 upstream 代码压缩成集成解决方案时，我们将继续使用 openSUSE Build Service 作为我们构建软件包、容器和 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 平台。

谢谢，祝您玩得开心！