关于Portainer 2.0和即将推出的功能的新博客文章

在接下来的几周里，我们将宣布Portainer Community Edition 2.0的可用性。我们希望在第三季度中期发布代码，但是过早宣布日期总是很危险的。

但是在我谈论2.0之前，我想先谈谈优先顺序和决策制定。

我们在Portainer的资源有限，以及长达66号公路的功能请求和机会列表。我们每天都必须做出优先决策，不可避免地，某个地方的人会因为我们没有达到他们的期望而感到不安。我们知道这一点，这是我们不愿看到的事情，但我们必须量入为出。

我们对Portainer请求的功能添加/修复做出决定的方式如下：

我们觉得这项功能会有广泛的吸引力吗？如果是，则添加；

这是一个在Github内部至少有20个“竖起大拇指”或“红心”的功能吗？如果是，则添加；

这项功能会让Portainer的专业用户受益吗？如果是，请添加它。

如果功能请求/问题只存在于特定用例中，由我们或缺乏社区“竖起大拇指”来判断，则这些功能请求/问题会一直“挂起”，直到确定有足够的需求为止(所以不要忘了竖起您关心的问题的大拇指)。此外，需要注意的是，我们不会自动保持与Docker的功能对等，因此当他们在Docker CE中推出新功能时，我们会根据上述4个标准对每个功能进行评估，然后再决定是否将其添加到Portainer中。利用我们目前的资源，我们只增加对我们认为有实际需求的功能的支持。

在Portainer支持的所有平台中，Docker和Docker Sarm是我们的根本根源；如果没有我们为这两项底层技术构建的东西，我们就不会有今天的成就，因此，只要有意义，我们就计划继续支持它们。不过，最近我们看到了几个与Sarm相关的问题，这些用户要么遇到了Spot中未记录的限制(例如，通过Inress暴露了128个最大端口)，要么就是Spot中的已知问题，这些问题已经开放了2年多，没有得到解决。这与我们有关，因为我们无法在Portainer中解决这些问题，因此这些问题/限制也成为我们的问题/限制。我们将在社区的指导下，决定需要继续将哪些功能带到Sarm部署中；我们有自己的看法，并且已经整理了符合我们4个标准的功能请求列表，这些功能请求将在下一个1-2个版本中添加。

我们将在Portainer2.0中添加的最大特性是对Kubernetes的支持。我们对Kubernetes的特性请求搁置了很长一段时间，因为我们一直在努力为它设计一个简单的UI/UX，但在去年年底破解了这个难题后，我们的开发取得了显著的进步。我们想要“毫不妥协”地增加Kubernetes，我们的意思是，我们想要提供今天为Sroom提供的功能，明天为Kubernetes提供的功能。

不过，我们还有很多工作要做，这意味着我们的大多数开发人员都专注于这个Kubernetes活动。这就是说，我们已经指派开发人员继续处理积压的集群/独立问题，从最“需求”的问题开始，从那里开始向下工作。我们还在继续为我们的“无服务器”选项添加功能(Azure ACI支持)，并计划继续构建我们的边缘计算管理功能。

在下图(单击放大)中，我们试图描述在未来6个月内我们将重点关注哪些方面的开发工作。