本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Weave 如何使用 Kubernetes 为 Scope 构建多部署解决方案

作者：Peter Bourgon (Weaveworks) |

今年早些时候，Weaveworks 推出了 Weave Scope，这是一个用于容器化应用和服务可视化和监控的开源解决方案。最近，我们将托管的 Scope 服务发布到 早期访问计划 中。今天，我们想向您介绍我们最初是如何原型化该服务的，以及我们最终如何选择并部署 Kubernetes 作为我们的平台。

云原生架构

Scope 在数据收集和用户交互之间已经有清晰的内部界限，因此很方便地沿着这条线拆分应用程序，将探测器分发给客户，并在云中托管前端。我们根据 12 因素模型 构建了一小组微服务，其中包括：

  • 用户服务，用于管理和验证用户账户
  • 供应服务，用于管理客户 Scope 实例的生命周期
  • UI 服务，托管所有精美的 HTML 和 JavaScript 内容
  • 前端服务，根据请求属性路由请求
  • 监控服务，用于内省系统的其余部分

所有服务都构建为 Docker 镜像，尽可能 基于 scratch。我们知道我们至少要提供 3 个部署环境，并且这些环境应该尽可能相同。

  • “飞行模式”本地环境，在每个开发人员的笔记本电脑上
  • 开发或暂存环境，与生产环境相同的基础设施上，但使用不同的用户凭据
  • 生产环境本身

这些是我们的应用程序不变式。接下来，我们必须选择我们的平台和部署模型。

我们的第一个原型

有看似无限的选择，以及无限的可能性组合。在 2015 年中期对情况进行调查后，我们决定使用以下组件制作一个原型：

  • Amazon EC2 作为我们的云平台，包括用于持久化的 RDS
  • Docker Swarm 作为我们的“调度器”
  • Consul 用于引导 Swarm 时的服务发现
  • Weave Net 用于我们的网络和应用程序本身的服务发现
  • Terraform 作为我们的供应器

这个设置定义和部署都很快，所以它是验证我们想法可行性的好方法。但是我们很快就遇到了问题。

  • Terraform 对 Docker 作为供应器 的支持非常基础，我们在尝试使用它来驱动 Swarm 时发现了一些 bug。
  • 很大程度上由于上述原因，使用 Terraform 管理 Docker 容器的零停机部署非常困难。
  • Swarm 的 存在理由 是将多节点容器调度的细节抽象到熟悉的 Docker CLI/API 命令之后。但是我们得出结论，该 API 对于生产规模所需的各种操作来说表达能力不足。
  • Swarm 在节点故障等情况下不提供容错能力。

我们在设计工作流程时也犯了一些错误。

  • 我们在构建时为每个容器标记了其目标环境，这简化了我们的 Terraform 定义，但实际上迫使我们通过镜像仓库管理版本。这个职责属于调度器，而不是制品存储库。
  • 结果是，每次部署都需要将制品推送到所有主机。这使得部署缓慢，回滚难以忍受。
  • Terraform 旨在供应基础设施，而不是云应用程序。这个过程比我们想要的更慢、更刻意。将新版本的东西发布到生产环境大约需要 30 分钟，包括所有步骤。

当服务显示出潜力时，我们重新评估了部署模型，着眼于长期发展。

基于 Kubernetes 重构

仅仅几个月，情况就发生了很大变化。

  • HashiCorp 发布了 Nomad
  • Kubernetes 发布了 1.0 版本
  • Swarm 即将发布 1.0 版本

虽然我们的大部分问题都可以通过不进行根本性架构更改来解决，但我们希望通过加入现有生态系统，并利用其贡献者的经验和辛勤工作，来利用行业进步。

经过内部讨论，我们对 Nomad 和 Kubernetes 进行了小规模的试用。我们非常喜欢 Nomad，但觉得现在就将其用于我们的生产服务还为时过早。此外，我们发现 Kubernetes 的开发人员对 GitHub 上的问题响应最积极。因此，我们决定选择 Kubernetes。

本地 Kubernetes

首先，我们将使用 Kubernetes 复制我们的飞行模式本地环境。因为我们的开发人员使用 Mac 和 Linux 笔记本电脑，所以本地环境必须容器化。因此，我们希望 Kubernetes 组件本身（kubelet、API 服务器等）在容器中运行。

我们遇到了两个主要问题。首先，也是最普遍的，从头开始创建 Kubernetes 集群很困难，因为它需要对 Kubernetes 的工作原理有深入的了解，并且需要相当长的时间才能将各个部分组合在一起。local-cluster-up.sh 看起来更像是 Kubernetes 开发人员的工具，并且没有利用容器，而我们找到的第三方解决方案，如 Kubernetes Solo，需要专用的虚拟机或具有平台特定性。

其次，容器化的 Kubernetes 仍然缺少几个重要的部分。遵循 官方 Kubernetes Docker 指南 会产生一个没有证书或服务发现的裸机集群。我们还遇到了几个可用性问题（#16586、#17157），我们通过 提交补丁 并从主分支构建我们自己的 hyperkube 镜像 来解决这些问题。

最后，我们通过创建自己的供应脚本使其正常工作。它需要做一些事情，例如 生成 PKI 密钥和证书 和 供应 DNS 附加组件，这花了几次尝试才弄对。我们还了解到有一个 提交，将证书生成添加到 Docker 构建中，因此在不久的将来情况可能会变得更容易。

AWS 上的 Kubernetes

接下来，我们将 Kubernetes 部署到 AWS，并将其与其他的 AWS 组件连接起来。我们希望快速在生产环境中启动服务，并且我们只需要支持 Amazon，所以我们决定不使用 Weave Net，而是使用一个预先存在的供应解决方案。但我们肯定会在不久的将来重新审视这个决定，通过 Kubernetes 插件利用 Weave Net。

理想情况下，我们会使用 Terraform 资源，我们找到了几个：kraken（使用 Ansible）、kubestack（与 GCE 耦合）、kubernetes-coreos-terraform（过时的 Kubernetes）和 coreos-kubernetes。但它们都基于 CoreOS，这是我们一开始想避免的额外移动部件。（在我们的下一次迭代中，我们可能会试用 CoreOS。）如果您使用 Ansible，主仓库中提供了 playbooks。还有社区驱动的 Chef cookbooks 和 Puppet modules。我预计社区在这里会快速发展。

唯一其他可行的选择似乎是 kube-up，它是一组将 Kubernetes 部署到各种云提供商的脚本。默认情况下，kube-up 将主节点和从属节点部署到 AWS 上的独立 VPC（虚拟私有云）中。但我们的 RDS 实例是在区域默认 VPC 中部署的，这意味着 Kubernetes 从属节点与数据库的通信只能通过 VPC 对等连接 或手动打开 RDS VPC 的防火墙规则来实现。

为了让流量通过 VPC 对等链路传输，您的目标 IP 需要在目标 VPC 的私有地址范围内。但 事实证明，从同一个 VPC 之外的任何地方解析 RDS 实例的主机名都会得到公共 IP。执行解析很重要，因为 RDS 保留更改维护 IP 的权利。这在以前的基础设施中从未成为问题，因为我们的 Terraform 脚本只是将所有内容放在同一个 VPC 中。所以我尝试在 Kubernetes 上做同样的事情；kube-up 脚本表面上支持通过指定 VPC_ID 环境变量安装到现有 VPC，所以我尝试将 Kubernetes 安装到 RDS VPC。kube-up 似乎成功了，但是 通过 ELB 的服务集成中断，并且 通过 kube-down 拆除停止工作。一段时间后，我们认为最好让 kube-up 保持其默认设置，并在 RDS VPC 中开一个口子。

这是我们遇到的几个小问题之一。每个问题都可以单独修复，但使用 shell 脚本来提供远程状态固有的脆弱性似乎是实际的根本原因。我们完全期望 Terraform、Ansible、Chef、Puppet 等软件包继续成熟，并希望尽快切换。

除了供应之外，Kubernetes/AWS 集成还有很多优点。例如，正确类型的 Kubernetes 服务 会自动生成 ELB，并且 Kubernetes 在生命周期管理方面做得非常出色。此外，Kubernetes 领域模型——服务、Pod、复制控制器、标签和选择器模型 等等——是连贯的，并且似乎为用户提供了恰到好处的表达能力，尽管定义文件确实 倾向于不必要地重复。kubectl 工具很好用，尽管 乍一看令人望而生畏。特别是 滚动更新 命令非常出色：这正是这种系统我所期望的语义和行为。事实上，一旦 Kubernetes 启动并运行，它就能正常工作，并且完全符合我的预期。这是一个巨大的进步。

结论

经过几周与机器的搏斗，我们解决了所有的集成问题，并成功将一个相当健壮的基于 Kubernetes 的系统部署到生产环境。

  • Kubernetes 的供应很困难，这归因于复杂的架构和尚处于发展初期的供应方案。这显示出所有改进的迹象。
  • Kubernetes 的非可选安全模型需要时间才能正确设置。
  • Kubernetes 的领域语言与问题领域非常匹配。
  • 我们对操作应用程序更有信心了（而且速度也快了很多）。
  • 我们非常高兴能成为不断壮大的 Kubernetes 用户群的一员，尽可能地贡献问题和补丁，并受益于驱动当今最激动人心的软件开发的开源良性循环。

Weave Scope 是一个用于容器化应用和服务可视化和监控的开源解决方案。如需托管的 Scope 服务，请访问 scope.weave.works 申请早期访问计划邀请。