DockerHub 将停止个人免费版 Team 的功能

想必很多人都用过 DockerHub，Docker 刚面世的时候，不仅仅提供了资源隔离的能力，还可以通过 DockerHub 进行镜像的构建和分发。这也是后来 Docker 能快速流行的原因之一。

目前 DockerHub 仍然是全世界最大，使用最为广泛的容器镜像仓库，并且也提供了非常丰富的能力。

在 2019 年 Docker Inc. 将其企业服务出售给 Mirantis 后，Docker Inc. 也在大力发展旗下的两个主要产品： DockerHub 和 DockerDesktop。通过一系列的措施和改进后，也成功的通过这些产品和服务让 Docker Inc. 重新回到大众视野。

比如：

2019 年 DockerHub 推出双因素身份认证功能，用于提升安全性，这也是付费用户/企业较为看重的一环。我在 K8S 生态周报| Helm v3 最后一个beta版本发布 | MoeLove 有具体介绍。
2020 年 DockerHub 修改定价和 TOS ，被一些标题党带歪了，带来了一阵恐慌。同时也引入了新的限流措施（Rate limit），我也在突破 DockerHub 限制，全镜像加速服务 | MoeLove 文章中进行了具体介绍，以及如何应对它。
2020 年，作为修改定价的后续，也发布了新的 hub-tools 工具，可用来查看和管理账号和资源，我也写了文章 Docker 新发布的 hub-tool 可直接查看账户配额 | MoeLove。
2021 年 Docker Inc, 发布了一份报告，显示出 DockerHub 在 2021 第二季度有 420 亿次下载，表现出了强劲的增长趋势。
2021 年 DockerHub 上也增加了应对 Log4j 漏洞的安全扫描，以及增强了对多架构的支持。
2022 年 DockerHub 增加了 OCI artifacts 的支持，可以同时在 DockerHub 上托管容器镜像和 Helm chart 等内容。

然后时间就来到了今年，Docker Inc. 宣布要停止个人免费版 Team 的功能。 Docker Inc. 提供了多种订阅计划，以满足不同用户的需求和预算。其中，Docker 免费版 Team 订阅计划是一个遗留的计划，它允许用户免费创建组织并访问私有仓库。

Docker Inc. 对这个计划的重大改变，引起了用户和开源社区的关注和不满。

在本文中，我将解释 Docker Inc. 为什么要废弃这个计划，以及这对用户和开源社区有什么影响。

Docker 为什么要废弃免费团队订阅计划？

根据 Docker Inc. 的官方公告，他们在 2023 年 3 月给所有属于免费团队组织的账户发送了电子邮件，通知他们如果不在 2023 年 4 月 13 日之前升级到其他支持的免费或付费的服务计划，他们将失去一些付费功能，比如私有仓库和无限制的协作者，并且他们的组织数据将被删除。

这个改变影响了不到 2% 的 Docker 用户，并且不影响其他服务计划，比如 Docker Personal、Docker Pro、Docker Team 或者 Docker Business。它也不影响 Docker Hub 上的公共镜像，除非它们的维护者决定删除它们。

那么，Docker 为什么要做出这样一个决定呢？根据 Docker 的首席营销官 Tim Anglade 的道歉信，主要有以下几个原因：

免费团队订阅计划是一个过时的计划，它没有很好地服务于开源社区。相反，Docker 最近更新了他们的 Docker-Sponsored Open Source (DSOS) 计划，这个计划提供了超过免费团队订阅计划的一些优惠和支持。
免费团队订阅计划是一个成本高昂且难以维护的计划。由于该计划提供了无限制地创建组织和私有仓库等功能，在过去几年中导致了大量无效或重复账户、垃圾数据、滥用行为等问题。
免费团队订阅计划与其他服务计划不一致且容易混淆。由于该计划是在几年前推出时设计的，并没有考虑到现在 Docker 的产品线和定价策略。因此，在与其他服务计划进行比较时会产生一些矛盾或歧义。

总结来说，就是这个过时的免费版团队计划提供的功能和特性太多了，不利于 Docker Inc. 继续推进其现有的产品和定价策略，而且付费用户也会提出意见，既然有这么好用且方便的免费版，为什么要升级到 Docker Team 计划呢？

这对用户和开源社区有什么影响？

尽管 Docker Inc. 声称他们废弃免费团队订阅计划是为了提供更好地服务给用户和开源社区，并且只影响了少数用户，但实际上这也确实让很多人觉得不满意。

最主要的是一开始发送的通知邮件含糊不清，而且邮件内容也缺少了为用户的考虑。当然，也有可能在制定这个计划的时候，确实考虑的没有那么充分。（这种时候让 ChatGPT 帮忙写下邮件效果都能比这好一点）在经过社区和用户反馈后，该变了一些策略的细节。

我这里就只说一下目前最终的结果吧。

如果是开源社区/开源项目，需要继续使用团队版的话，可以申请 Docker 赞助的开源计划 - DSOS，这个计划比之前的版本要好的多，放宽了很多限制，而且更容易审核通过。在之前的 DSOS 版本中，存在一些比较严苛的限制，现在已经都删掉了。而且可以获得不受限制的下载次数和流量。
如果是开源社区/开源项目，不打算申请 DSOS 的话，则可以通过提交工单，将账号转换为免费个人账户。
如果是个人用户，则需要升级 Docker team 才能使用相关功能，否则只能继续使用 Docker Personal 账户了。

其他

Docker Inc. 这些年确实做了很多改变，也做了很多决策。有些是让用户很容易接受且欣然接受的。但也做过一些决策，让用户和社区都比较反感。幸好绝大多数决策在收到反馈后，都进行了调整。

目前来看，Docker Inc. 尽管最近拿到了一笔投资，但是它进行了一些买买买的收购，准备扩展自己的版图。但它当前最为核心的收入还是来自于 DockerHub 和 DockerDesktop 。随着它的一步步动作，整体的收费模式 & 策略将会更加清晰，类似本次这种调整应该会比较少了。

Azure AKS Edge Essentials 达到 GA

Azure Kubernetes Service Edge Essentials 是 Azure Kubernetes Service（AKS）的本地 Kubernetes 实现，可自动化运行规模化容器化应用程序。

AKS Edge Essentials 包括一个由 Microsoft 支持的 Kubernetes 平台，其中包括具有小占用空间和简单安装体验的轻量级 Kubernetes 分发版，可以在 PC 级或轻型边缘硬件上部署 Kubernetes。

AKS Edge Essentials 使得启动容器化应用程序更加容易，并将云原生最佳实践带到您的边缘应用程序中。

与其他 Microsoft 支持的平台（如托管在 Azure 上的服务（AKS）和服务器级硬件（AKS-HCI））不同，AKS Edge Essentials 旨在进行静态、预定义配置，并且不允许动态 VM 创建/删除或集群生命周期管理。

AKS Edge Essentials 集群中每个机器只能有一个 Linux 和/或 Windows VM。 Linux VM 作为控制节点和工作负载节点，在 Kubernetes 集群中运行 Linux 工作负载。每个具有 AKS Edge Essentials 功能的机器都具有受限制 RAM、存储和物理 CPU 核心数量的VM，这些资源根据安装时分配给静态分配。此类应用程序配置方式使传统 Windows 应用程序可以并排运行；也就是说，在AKS Edge Essentials VM 旁相互操作。

整体看起来是这样：

K8S 生态周报| 别慌，DockerHub 不会清退开源组织和开源项目第1张

aks edge windows

感觉还挺不错的，我打算改天试试看。

上游进展

Release Kubernetes v1.27.0-beta.0 · kubernetes/kubernetes ，正式版也很快将会发布。
Promote whoami kubectl command by nabokihms · Pull Request #116510 · kubernetes/kubernetes

kubectl auth whoami 从 alpha 子命令中移出，可以直接使用了。

大家想必都知道，Kubernetes 中并没有 User（用户）的资源，但是 Kubernetes 中有权限校验的方式，比如我们常用到的利用 x509 证书进行用户权限相关的校验，或者通过外部的 OIDC 和 webhook 等进行校验。

之前有一个 Add auth API to get self subject attributes by nabokihms · Pull Request #111333 · kubernetes/kubernetes实际上是为了添加一个新的接口，以便于用户身份通过校验后，获取其所具有的属性。这样就可以简单的通过增加一个 kubectl auth whoami 的命令，来了解当前用户的相关信息了。这功能比较类似于我们做 OAuth 的时候，可能会做个 UserInfo 之类的接口，用来查看用户相关的属性。

该功能是通过在 authentication.k8s.io Group 下添加了 SelfSubjectReview 资源来实现的，具体如下：

// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.
type SelfSubjectReview struct {
 metav1.TypeMeta `json:",inline"`
 // Standard object's metadata.
 // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
 // +optional
 metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
 // Status is filled in by the server with the user attributes.
 Status SelfSubjectReviewStatus `json:"status,omitempty" protobuf:"bytes,2,opt,name=status"`
}

// SelfSubjectReviewStatus is filled by the kube-apiserver and sent back to a user.
type SelfSubjectReviewStatus struct {
 // User attributes of the user making this request.
 // +optional
 UserInfo v1.UserInfo `json:"userInfo,omitempty" protobuf:"bytes,1,opt,name=userInfo"`
}