Docker、CoreOS 和基于队列的部署
Docker, CoreOS and fleet based deployments
我正在努力思考 CoreOS and I perused their official docs, some random articles, and even watched this excellent presentation by their CTO。
- 我对 CoreOS 的 理解 是它是一个精简的、基本的 Linux 发行版，需要 任何东西 运行 它是一个 OCF-compliant container， 而不是 只是一个 Docker 容器。
- 我对fleet的理解是它的
systemd在集群级别
- 我的理解 flannel is that its a network layer that is used by both etcd 和 fleet 将网络请求路由到集群中的容器
所以首先，如果我的上述断言不正确或以任何方式被误导，请首先纠正我！假设我或多或少走上了正轨，我在这里有一些担忧：
- CoreOS 提供 Docker 包含的应用程序有哪些具体的好处，而其他 Linux 发行版（例如 Ubuntu 或 Debian）不存在这些应用程序？换句话说，objective 相比 Docker/CoreOS 与 Docker/Ubuntu 相比，我获得了什么 objective 好处？
- Fleet 就像一个调度引擎，就像 Mesos 或 Kubernetes。它是这些项目的直接竞争对手，还是它们处理不同 "layers"（不同类型的职责）的调度？如果有，这些区别是什么？
是的，你的理解很正确。
Coreos 被设计为一个更安全的操作系统，默认情况下会自动更新自身，运行s 是减少任何攻击向量的最低限度服务。 http://www.activestate.com/blog/2013/08/alex-polvi-explains-coreos
一切都需要 运行 在容器中，静态编译（例如 golang 二进制文件），或者是 shell 脚本。没有安装 python 或 ruby。
Containers/systemd 由 Fleet 启动的单元可以在另一个节点上重新安排，如果它的服务器发生故障（假设你的容器是临时的）并且应该在集群上保持请求的实例数量 运行，同时服从部署约束。 https://coreos.com/using-coreos/clustering/
Mesos 更像是一个调度程序框架，您仍然需要其他东西 (chronos/marathon) 来提供要执行的作业，但它在这方面非常灵活，并且可以更好地利用服务器资源。
我对 Flannel 没有太多经验，但是 Docker 未来版本中的新网络插件可能会为您提供更多容器网络选择。 http://blog.docker.com/2015/06/networking-receives-an-upgrade/
这里有很多活动部件。已经 posted 的答案非常好。我认为你得到的任何答案都会有意见。我以为我会在尝试获得 100 个赏金点数时通过你的打孔清单:-)
我现在每天都使用 CoreOS/Flannel/Kubernetes/Fleet 大约 6 个月了。当您 post 编辑了 url 的介绍时，我决定观看它。哇，很棒的介绍。我认为 Brandon Philips 是一位非常好的老师。我喜欢他在介绍每项技术时所采用的方式。我会向任何人推荐该教程。
CoreOS 是一个基于 linux 的操作系统。它非常简洁，没有多余的东西 运行ning。对我来说，它做了这些事情：
- 自动更新。做得好。双分区，非活动更新，活动交换，回退（我想，我从未经历过回退）。他们已经解决了 'how to update your operating system after you deploy' 问题并使其相对轻松。
- systemd 初始化系统。我花了更长的时间才喜欢这个（作为一个 /etc/init.d 的人）但是，过了一会儿它就对你产生了影响。有一个非常陡峭的学习曲线。一旦你了解了正在发生的事情，你会喜欢 systemd 如何保持机器 运行 特定的东西、依赖、重启（如果你想要的话）、监听套接字（比如 super initd）和生成进程、d-bus（尽管我对这部分了解不多）。 systemd 允许您指定 'units' 并且单元可以具有依赖项、pre 和 post 进程等
- 基本服务。我已经从 运行ning 在我的 CoreOS 系统上的每个服务中复制了简短描述行。
- systemd - 它提供了一个系统和服务管理器，运行s 作为 PID 1 并启动系统的其余部分
- docker - Docker 是一个开源项目，用于将任何应用程序作为轻量级容器进行打包、运输和 运行
- etcd - etcd 是用于共享配置和服务发现的分布式、一致的键值存储
- sshd - sshd（OpenSSH 守护程序）是 ssh(1) 的守护程序。这些程序共同取代了 rlogin 和 rsh，并通过不安全的网络在两个不受信任的主机之间提供安全的加密通信。
- locksmithd - locksmith 是 CoreOS 更新引擎的重启管理器，它使用 etcd 来确保在任何给定时间只有机器集群的一个子集正在重启。 locksmithd 运行s 作为 CoreOS 机器上的守护进程，负责控制更新后的重启行为。
- journald - systemd-journald 是一种收集和存储日志数据的系统服务。
- timesyncd - systemd-timesyncd 是一种系统服务，可用于将本地系统时钟与远程网络时间协议服务器同步
- update_engine
- udevd - systemd-udevd 监听内核事件。对于每个事件，systemd-udevd 执行 udev 规则中指定的匹配指令。见 udev(7).
- logind - systemd-logind 是管理用户登录的系统服务。
- resolved - systemd-resolved 是管理网络名称解析的系统服务。它实现了一个缓存 DNS 存根解析器和一个 LLMNR 解析器和响应器。
- hostnamed - 这是一个小型守护进程，可用于控制用户程序的主机名和相关机器元数据。
- networkd - systemd-networkd 是一种管理网络的系统服务。它检测并配置出现的网络设备，以及创建虚拟网络设备。
CoreOS 不一定要求您想要 运行 的所有内容都必须是容器。它会 运行 unix 机器会 运行 的任何东西。 yum 和 apt-get 明显缺失，但包含 wget。因此，您可以 'install' 程序、库，甚至可以通过 wget 获取 apt-get，并开始污染 CoreOS 基础。不过那可不好。你真的想让它保持原样。为此，它们包括一个 'toolbox'，它可以让你 运行 一个像沙箱这样的容器来完成你的工作，当你退出时它就会消失。
我最喜欢 CoreOS 的部分是云配置。在首次启动时，您可以提供 user_data 称为云配置。它是一个 yaml 文件，它告诉基本 CoreOS 在第一次启动时要做什么。这是您安装 fleet、flannel、kubernetes 等东西的地方。这是一种真正简单的方法，可以在 VM 上重复安装您选择的组合。在典型的云配置中，我将编写配置文件，从其他机器复制文件以安装到新机器上，并创建单元文件来控制我们希望 CoreOS 的 systemd 管理的其他进程（如 flannel、fleet 等）。而且是完全可重复的。
这是关于 CoreOS 的另一件有趣的事情。您可以修改现有单元的依赖和配置。例如，CoreOS 启动 docker。但是，我想修改 docker 的启动顺序，因此我可以添加一个插入式配置来增强现有系统 docker 配置。我用它来插入 flannel before docker 启动的依赖项，这样我就可以配置 docker 使用 flannel 提供的网络。这不一定是 CoreOS，但是，它确实使它们结合在一起。
我认为您可以将 cloud-config 与 Ubuntu 以及 CoreOS 一起使用，并且可以做同样的事情。所以，我认为你从 CoreOS 获得的好处超过 Ubuntu 是你经常获得新版本，操作系统是自动更新的，而且你没有任何东西 'extra' 运行ning（它很精简，减少的攻击向量是 fallout）。 CoreOS 针对 docker 进行了调整（它已经是 运行ning），而 ubuntu 还没有 运行ning。虽然，您可以创建一个云配置文件，使 ubuntu 运行 docker...总之，我认为您已经了解 CoreOS。
您可以通过 CoreOS 获得的另一件事是支持，直接来自公司，有偿或无偿。 CoreOS 的人通过这个论坛和 CoreOS Dev/CoreOS 用户 Google 组回答了我很多问题。
你的舰队描述也不错。 Fleet 管理一个集群。集群是一台或多台 CoreOS 机器。所以，如果你要使用 fleet，你 必须 使用 CoreOS，我想这将是 CoreOS 相对于 Ubuntu.
的另一个好处
很像 systemd 的单元文件如何控制 运行在主机上运行进程，fleetd 的单元文件如何控制 运行在集群上运行进程。有一点语法糖，但 fleet 的单元文件与 systemd 的单元文件大致相同。他们很合得来。 Fleet 的单元文件保存在 etcd 的 数据库 中，因此一旦被摄取，单元就会持久存在，即使托管单元服务的机器出现故障，单元描述也存在于 etcd 中。
Fleet 也有用于在我的集群中列出我的机器的命令，列出一个单元文件，显示 运行ning 的单元等。基本上你可以将单元提交到集群上的 运行 （或所有机器，或在特定类型的机器上（如 ssd 驱动器），或与其他机器在同一台机器上 运行ning（亲和力）等）。
Fleet 保留它 运行ning。如果机器离开，它的单元将在集群中的其他机器上运行。
在您引用的教程中，Brandon 使用 Fleet 启动 Kubernetes。这很简单。通过使舰队单元文件将 Kubernetes 放置在舰队集群中的所有机器上，当机器从舰队集群中添加和减去时，Kubernetes 会自动使用该机器并将 Kubernetes 调度到 运行 上。我也有 运行 我的 Kubernetes 集群。但是，我不再那么做了。我确信有一个我看不到的好处，但是，我觉得在我的环境中没有必要。由于我已经使用云配置文件启动我的机器，因此将 Kubernetes 节点服务直接放在其中是微不足道的。事实上，使用 cloud-config，如果我想使用 Fleet 来启动 Kubernetes 的东西，我将不得不编写 Fleet 单元文件，启动 Fleet，将我写的单元文件提交给 Fleet，当我可以只写一个单元文件时启动 Kubernetes 节点。但我离题了...
Fleet是一种调度机制，就像Kubernetes一样。但是，Fleet 可以通过单元文件启动任何可执行文件，就像 systemd 一样，其中 Kubernetes 面向容器。 Kubernetes 允许定义：
- 复制控制器
- 服务
- pods
- 容器
（还有其他东西）。
因此，Fleet 只是一种不同的 'layer' 调度的断言是一个很好的断言。您可能会补充说 Fleet 安排了不同的事情。在我的工作中，我不使用 Fleet 层，我只是直接跳转到 Kubernetes，因为我只使用容器。
最后，关于flannel的说法是不正确的。 Flannel 使用 etcd 作为其数据库。 Flannel 为它在它们之间路由的每个主机创建一个专用网络。 flannel 网络交给 docker，docker 被告知使用该网络分配 IP 地址。因此，docker 使用 flannel 的进程可以通过 ip 相互通信。由于每个容器都有自己的 IP 地址，因此可以跳过所有端口映射内容。这些 docker 进程可以在 flannel 网络上进行基础设施和机器内部通信。我可能是错的，但我认为 Fleet 和法兰绒之间没有任何联系。另外，我不认为 etcd 或 Fleet 使用法兰绒来路由他们的数据。 Etcd 和 Fleet 路由是否正在使用法兰绒。 Docker 容器通过 flannel 路由它们的流量。
-g
what objective benefits do I gain by going Docker/CoreOS vs.
Docker/Ubuntu?
技术优势
CoreOS 吸引我的特点是：
- 是集群，不是单机，OS
- 它是为失败而构建的
- 它是自我更新的
CoreOS是集群，而Ubuntu是单机。使用 CoreOS，当容器所在的机器消失时，集群会在其他地方启动容器。当那个 Ubuntu 服务器发生故障时，它的容器也会随之崩溃。 CoreOS让机器可以一次性使用，这是好事
话虽如此，请记住 CoreOS 不处理数据持久性；存储在容器中的数据不存在！ ;) 在我的例子中，我在需要的地方动态附加 EBS 卷。
设计优势
对我来说更重要的是，上述技术优势带来了设计优势。了解系统设计后，"this process will randomly disappear," 非常适合构建弹性。从一开始，服务就是 stateless 并且因为你根本不知道依赖服务在哪个系统上，所以它们也必须是 discoverable。 CoreOS 的 etcd，一种分布式配置存储，可用于发现服务所在的位置。最后，由于进程可能不在同一台机器上，网络可访问服务——水平可扩展系统的必要条件——是唯一的出路。
总而言之，我发现 CoreOS 非常适合免费构建 Twelve-Factor Apps and you get Chaos Monkey。
Fleet just seems like a scheduling engine, like Mesos or Kubernetes.
Is it a direct competitor to these projects, or do they handle
scheduling at different "layers" (different types of
responsibilities)? If so, what are these distinctions?
是的，Fleet 调度一个容器并确定它在集群中的运行位置。如果该机器消失，Fleet 还负责在工作机器上重新启动它。
我没有深入研究 Kubernetes，但似乎确实存在重叠。到目前为止，我的理解是 Fleet 处理 运行 单个容器（"unit"），而 Kubernetes 是互补的，并协调组成系统的多个单元。例如，Fleet 确保 Postgres 保持 运行； Kubernetes 确保您的应用程序，例如由 Postgres、Redis 和 Django 组成，都在嗡嗡作响。
我正在努力思考 CoreOS and I perused their official docs, some random articles, and even watched this excellent presentation by their CTO。
- 我对 CoreOS 的 理解 是它是一个精简的、基本的 Linux 发行版，需要 任何东西 运行 它是一个 OCF-compliant container， 而不是 只是一个 Docker 容器。
- 我对fleet的理解是它的
systemd在集群级别 - 我的理解 flannel is that its a network layer that is used by both etcd 和 fleet 将网络请求路由到集群中的容器
所以首先，如果我的上述断言不正确或以任何方式被误导，请首先纠正我！假设我或多或少走上了正轨，我在这里有一些担忧：
- CoreOS 提供 Docker 包含的应用程序有哪些具体的好处，而其他 Linux 发行版（例如 Ubuntu 或 Debian）不存在这些应用程序？换句话说，objective 相比 Docker/CoreOS 与 Docker/Ubuntu 相比，我获得了什么 objective 好处？
- Fleet 就像一个调度引擎，就像 Mesos 或 Kubernetes。它是这些项目的直接竞争对手，还是它们处理不同 "layers"（不同类型的职责）的调度？如果有，这些区别是什么？
是的，你的理解很正确。
Coreos 被设计为一个更安全的操作系统，默认情况下会自动更新自身，运行s 是减少任何攻击向量的最低限度服务。 http://www.activestate.com/blog/2013/08/alex-polvi-explains-coreos
一切都需要 运行 在容器中，静态编译（例如 golang 二进制文件），或者是 shell 脚本。没有安装 python 或 ruby。
Containers/systemd 由 Fleet 启动的单元可以在另一个节点上重新安排，如果它的服务器发生故障（假设你的容器是临时的）并且应该在集群上保持请求的实例数量 运行，同时服从部署约束。 https://coreos.com/using-coreos/clustering/
Mesos 更像是一个调度程序框架，您仍然需要其他东西 (chronos/marathon) 来提供要执行的作业，但它在这方面非常灵活，并且可以更好地利用服务器资源。
我对 Flannel 没有太多经验，但是 Docker 未来版本中的新网络插件可能会为您提供更多容器网络选择。 http://blog.docker.com/2015/06/networking-receives-an-upgrade/
这里有很多活动部件。已经 posted 的答案非常好。我认为你得到的任何答案都会有意见。我以为我会在尝试获得 100 个赏金点数时通过你的打孔清单:-)
我现在每天都使用 CoreOS/Flannel/Kubernetes/Fleet 大约 6 个月了。当您 post 编辑了 url 的介绍时，我决定观看它。哇，很棒的介绍。我认为 Brandon Philips 是一位非常好的老师。我喜欢他在介绍每项技术时所采用的方式。我会向任何人推荐该教程。
CoreOS 是一个基于 linux 的操作系统。它非常简洁，没有多余的东西 运行ning。对我来说，它做了这些事情：
- 自动更新。做得好。双分区，非活动更新，活动交换，回退（我想，我从未经历过回退）。他们已经解决了 'how to update your operating system after you deploy' 问题并使其相对轻松。
- systemd 初始化系统。我花了更长的时间才喜欢这个（作为一个 /etc/init.d 的人）但是，过了一会儿它就对你产生了影响。有一个非常陡峭的学习曲线。一旦你了解了正在发生的事情，你会喜欢 systemd 如何保持机器 运行 特定的东西、依赖、重启（如果你想要的话）、监听套接字（比如 super initd）和生成进程、d-bus（尽管我对这部分了解不多）。 systemd 允许您指定 'units' 并且单元可以具有依赖项、pre 和 post 进程等
- 基本服务。我已经从 运行ning 在我的 CoreOS 系统上的每个服务中复制了简短描述行。
- systemd - 它提供了一个系统和服务管理器，运行s 作为 PID 1 并启动系统的其余部分
- docker - Docker 是一个开源项目，用于将任何应用程序作为轻量级容器进行打包、运输和 运行
- etcd - etcd 是用于共享配置和服务发现的分布式、一致的键值存储
- sshd - sshd（OpenSSH 守护程序）是 ssh(1) 的守护程序。这些程序共同取代了 rlogin 和 rsh，并通过不安全的网络在两个不受信任的主机之间提供安全的加密通信。
- locksmithd - locksmith 是 CoreOS 更新引擎的重启管理器，它使用 etcd 来确保在任何给定时间只有机器集群的一个子集正在重启。 locksmithd 运行s 作为 CoreOS 机器上的守护进程，负责控制更新后的重启行为。
- journald - systemd-journald 是一种收集和存储日志数据的系统服务。
- timesyncd - systemd-timesyncd 是一种系统服务，可用于将本地系统时钟与远程网络时间协议服务器同步
- update_engine
- udevd - systemd-udevd 监听内核事件。对于每个事件，systemd-udevd 执行 udev 规则中指定的匹配指令。见 udev(7).
- logind - systemd-logind 是管理用户登录的系统服务。
- resolved - systemd-resolved 是管理网络名称解析的系统服务。它实现了一个缓存 DNS 存根解析器和一个 LLMNR 解析器和响应器。
- hostnamed - 这是一个小型守护进程，可用于控制用户程序的主机名和相关机器元数据。
- networkd - systemd-networkd 是一种管理网络的系统服务。它检测并配置出现的网络设备，以及创建虚拟网络设备。
CoreOS 不一定要求您想要 运行 的所有内容都必须是容器。它会 运行 unix 机器会 运行 的任何东西。 yum 和 apt-get 明显缺失，但包含 wget。因此，您可以 'install' 程序、库，甚至可以通过 wget 获取 apt-get，并开始污染 CoreOS 基础。不过那可不好。你真的想让它保持原样。为此，它们包括一个 'toolbox'，它可以让你 运行 一个像沙箱这样的容器来完成你的工作，当你退出时它就会消失。
我最喜欢 CoreOS 的部分是云配置。在首次启动时，您可以提供 user_data 称为云配置。它是一个 yaml 文件，它告诉基本 CoreOS 在第一次启动时要做什么。这是您安装 fleet、flannel、kubernetes 等东西的地方。这是一种真正简单的方法，可以在 VM 上重复安装您选择的组合。在典型的云配置中，我将编写配置文件，从其他机器复制文件以安装到新机器上，并创建单元文件来控制我们希望 CoreOS 的 systemd 管理的其他进程（如 flannel、fleet 等）。而且是完全可重复的。
这是关于 CoreOS 的另一件有趣的事情。您可以修改现有单元的依赖和配置。例如，CoreOS 启动 docker。但是，我想修改 docker 的启动顺序，因此我可以添加一个插入式配置来增强现有系统 docker 配置。我用它来插入 flannel before docker 启动的依赖项，这样我就可以配置 docker 使用 flannel 提供的网络。这不一定是 CoreOS，但是，它确实使它们结合在一起。
我认为您可以将 cloud-config 与 Ubuntu 以及 CoreOS 一起使用，并且可以做同样的事情。所以，我认为你从 CoreOS 获得的好处超过 Ubuntu 是你经常获得新版本，操作系统是自动更新的，而且你没有任何东西 'extra' 运行ning（它很精简，减少的攻击向量是 fallout）。 CoreOS 针对 docker 进行了调整（它已经是 运行ning），而 ubuntu 还没有 运行ning。虽然，您可以创建一个云配置文件，使 ubuntu 运行 docker...总之，我认为您已经了解 CoreOS。
您可以通过 CoreOS 获得的另一件事是支持，直接来自公司，有偿或无偿。 CoreOS 的人通过这个论坛和 CoreOS Dev/CoreOS 用户 Google 组回答了我很多问题。
你的舰队描述也不错。 Fleet 管理一个集群。集群是一台或多台 CoreOS 机器。所以，如果你要使用 fleet，你 必须 使用 CoreOS，我想这将是 CoreOS 相对于 Ubuntu.
的另一个好处很像 systemd 的单元文件如何控制 运行在主机上运行进程，fleetd 的单元文件如何控制 运行在集群上运行进程。有一点语法糖，但 fleet 的单元文件与 systemd 的单元文件大致相同。他们很合得来。 Fleet 的单元文件保存在 etcd 的 数据库 中，因此一旦被摄取，单元就会持久存在，即使托管单元服务的机器出现故障，单元描述也存在于 etcd 中。
Fleet 也有用于在我的集群中列出我的机器的命令，列出一个单元文件，显示 运行ning 的单元等。基本上你可以将单元提交到集群上的 运行 （或所有机器，或在特定类型的机器上（如 ssd 驱动器），或与其他机器在同一台机器上 运行ning（亲和力）等）。
Fleet 保留它 运行ning。如果机器离开，它的单元将在集群中的其他机器上运行。
在您引用的教程中，Brandon 使用 Fleet 启动 Kubernetes。这很简单。通过使舰队单元文件将 Kubernetes 放置在舰队集群中的所有机器上，当机器从舰队集群中添加和减去时，Kubernetes 会自动使用该机器并将 Kubernetes 调度到 运行 上。我也有 运行 我的 Kubernetes 集群。但是，我不再那么做了。我确信有一个我看不到的好处，但是，我觉得在我的环境中没有必要。由于我已经使用云配置文件启动我的机器，因此将 Kubernetes 节点服务直接放在其中是微不足道的。事实上，使用 cloud-config，如果我想使用 Fleet 来启动 Kubernetes 的东西，我将不得不编写 Fleet 单元文件，启动 Fleet，将我写的单元文件提交给 Fleet，当我可以只写一个单元文件时启动 Kubernetes 节点。但我离题了...
Fleet是一种调度机制，就像Kubernetes一样。但是，Fleet 可以通过单元文件启动任何可执行文件，就像 systemd 一样，其中 Kubernetes 面向容器。 Kubernetes 允许定义：
- 复制控制器
- 服务
- pods
- 容器
（还有其他东西）。
因此，Fleet 只是一种不同的 'layer' 调度的断言是一个很好的断言。您可能会补充说 Fleet 安排了不同的事情。在我的工作中，我不使用 Fleet 层，我只是直接跳转到 Kubernetes，因为我只使用容器。
最后，关于flannel的说法是不正确的。 Flannel 使用 etcd 作为其数据库。 Flannel 为它在它们之间路由的每个主机创建一个专用网络。 flannel 网络交给 docker，docker 被告知使用该网络分配 IP 地址。因此，docker 使用 flannel 的进程可以通过 ip 相互通信。由于每个容器都有自己的 IP 地址，因此可以跳过所有端口映射内容。这些 docker 进程可以在 flannel 网络上进行基础设施和机器内部通信。我可能是错的，但我认为 Fleet 和法兰绒之间没有任何联系。另外，我不认为 etcd 或 Fleet 使用法兰绒来路由他们的数据。 Etcd 和 Fleet 路由是否正在使用法兰绒。 Docker 容器通过 flannel 路由它们的流量。
-g
what objective benefits do I gain by going Docker/CoreOS vs. Docker/Ubuntu?
技术优势
CoreOS 吸引我的特点是：
- 是集群，不是单机，OS
- 它是为失败而构建的
- 它是自我更新的
CoreOS是集群，而Ubuntu是单机。使用 CoreOS，当容器所在的机器消失时，集群会在其他地方启动容器。当那个 Ubuntu 服务器发生故障时，它的容器也会随之崩溃。 CoreOS让机器可以一次性使用，这是好事
话虽如此，请记住 CoreOS 不处理数据持久性；存储在容器中的数据不存在！ ;) 在我的例子中，我在需要的地方动态附加 EBS 卷。
设计优势
对我来说更重要的是，上述技术优势带来了设计优势。了解系统设计后，"this process will randomly disappear," 非常适合构建弹性。从一开始，服务就是 stateless 并且因为你根本不知道依赖服务在哪个系统上，所以它们也必须是 discoverable。 CoreOS 的 etcd，一种分布式配置存储，可用于发现服务所在的位置。最后，由于进程可能不在同一台机器上，网络可访问服务——水平可扩展系统的必要条件——是唯一的出路。
总而言之，我发现 CoreOS 非常适合免费构建 Twelve-Factor Apps and you get Chaos Monkey。
Fleet just seems like a scheduling engine, like Mesos or Kubernetes. Is it a direct competitor to these projects, or do they handle scheduling at different "layers" (different types of responsibilities)? If so, what are these distinctions?
是的，Fleet 调度一个容器并确定它在集群中的运行位置。如果该机器消失，Fleet 还负责在工作机器上重新启动它。
我没有深入研究 Kubernetes，但似乎确实存在重叠。到目前为止，我的理解是 Fleet 处理 运行 单个容器（"unit"），而 Kubernetes 是互补的，并协调组成系统的多个单元。例如，Fleet 确保 Postgres 保持 运行； Kubernetes 确保您的应用程序，例如由 Postgres、Redis 和 Django 组成，都在嗡嗡作响。