用过 Kubernetes 的用户都知道 Kubernetes API 真的非常庞大。在最新的版本中，从 Pods 和 Deployments 到 Validating Webhook Configuration 和 ResourceQuota，超过 50 个一级对象。如果您是开发人员，我确信这会很容易导致群集配置时出现紊乱。因此，需要一种简化的方法（如 Swarm CLI / API）来部署和管理在 Kubernetes 集群上运行的应用程序。
&
在 Dockercon 的第二天，Docker 在 Kubernetes 项目上开源了 Compose。这个工具无疑可以简化 Kubernetes。如果您不知道，Docker 企业版已经在 Compose File 3.3 版本中启用了这个功能，它可以让您使用相同的 docker-compose.yml 文件进行 Swarm 部署，也可以在部署应用栈时指定 Kubernetes 工作负载。
让我来解释一下这究竟意味着什么？想象一下，您正在使用 Macbook 上运行的 Docker Desktop。 Docker Desktop 提供了为您的开发环境运行单个节点 Swarm 以及 Kubernetes 集群的功能。您可以选择从本地群集切换到云平台上运行的远程 Swarm 或 Kubernetes 群集，如 GKE / AKS。在本地单节点群集（可能是 Minikube 或 Docker Desktop for Mac）中开发代码后，您可能希望在远程云平台上对其进行测试。之前，所有这一切都需要“点击”将环境从本地群集切换到 GKE 或 AKS。现在，您可以使用相同的 Swarm CLI 命令在相同的 Docker Compose 文件中将应用程序部署到云平台。
在我们演示如何实现之前，让我们花一些时间来了解从 Swarm 到 Kubernetes 的映射是如何实现的？从根本上说，Swarm 到 Kubernetes 的1：1映射并不简单。由于应用栈本质上只是 Swarm 服务的列表，因此映射是基于每个服务完成的。根据官方文档，映射 Swarm 服务基本上需要两类 Kubernetes 对象：一类用于部署和扩展容器，另一类用于处理栈内和栈外网络。在 Kubernetes 中，不是操纵单个容器，而是操作一组称为 pod 的容器。Pods 可以根据需要使用不同的控制器来进行部署和扩展。如果声明服务是全局的，则 Kubernetes 上的 Compose 使用 DaemonSet 来部署 pod。
注意:此类服务不能使用持久化卷。如果服务使用卷，则需要使用 StatefulSet。谈到栈内网络，基本上 Kubernetes 没有像 Swarm 那样的网络概念。相反，命名空间中存在的所有 pod 都可以相互联网。为了使 pod 之间的 DNS 名称解析起作用，需要使用 HeadlessService。
点击文尾处“阅读原文
”进一步详细了解从 Swarm 到 Kubernetes 的映射。
架 构
Kubernetes 上 Compose 是由服务器端和客户端组件组成。选择此架构是为了能够管理应用栈的整个生命周期。下图是该架构的结构图：
REST API 使用 API 服务器聚合向 Kubernetes 客户端公开自定义 API 服务器。
客户端使用声明性 REST API 与服务器通信。它通过将序列化应用栈结构（v1beta2）或 Compose 文件（v1beta1） POST 到 API 服务器来创建应用栈。此 API 服务器将应用栈存储在 etcd 键值存储中。
服务器端架构
在 Kubernetes 上的 Compose 中有两个服务器端组件：
-
Compose API 服务器；
-
Compose 控制器；
Compose API 服务器通过添加用于创建和操作应用栈的路径来扩展 Kubernetes API。它负责将应用栈存储在 etcd 键值存储中。 它还包含将 v1beta1 代表转换为 v1beta2 的逻辑，因此 Compose 控制器只需要处理应用栈的一个代表。
Compose 控制器负责将堆栈结构（v1beta2 模式）转换为 Kubernetes 对象，然后将当前的集群状态与所需的集群状态进行协调。它通过与 Kubernetes API 交互来实现这一点，它是一个 Kubernetes 客户端，可以监视有趣的事件并操纵较低级别的 Kubernetes 对象。
