Weave Scope是Weaveworks公司推出的一个面向容器化App和服务的虚拟化及监测的开源解决方案。本文介绍了通过Kubernetes构建Weave Scope的整个历程。

今天，我们听到Peter Bourgon的（Weaveworks公司软件工程师）介绍，Weaveworks为软件开发人员提供在Docker容器中的基于微服务的网络、监测和控制服务。Peter告诉我们这涉及到选择和部署Kubernetes。

今年的早些时候，Weaveworks发布了Weave Scope，这是一个为容器化App和服务提供虚拟化与监测的开源解决方案。最近我们在早期的访问程序当中发布了一个托管服务。今天，我们要介绍该服务的最初原型，以及我们怎样最终选择和部署Kubernetes作为我们的平台。

一个原生云架构

Scope已经有一个内部的界限来分离数据收集和用户交互，因此在这个界限上就可以直接的分离应用，为用户分配接口，在云上托管前端。我们使用12-factor model（用于创建SaaS app的一种模型）创建了一系列小的微服务，包括：

• 一个用户服务，管理和授权用户帐户
• 一个供应服务，管理用户Scope实例的生命周期
• 一个UI服务，托管所有华丽的HTML和JavaScript内容
• 一个前端服务，根据属性来发送请求
• 一个监测服务，来监测系统其余部分

所有的服务从头开始都被创建为Docker镜像。我们想要提供至少3个近乎完全相同的开发环境。

• 一个“飞行模式”的本地环境，可以部署在每一个开发者的个人电脑上
• 一个开发或者临时环境，不同的用户凭证可以在同一个基础设施上管理生产
• 生产环境

这些是我们应用的约束条件。接下来，我们需要选择平台和开发模式。

我们的第一个原型

看起来我们有无数种不同的选择，并且还有无数种不同的组合，但在2015年年终进行市场调研之后，我们决定使用的技术栈包括：

• Amazon EC2作为云平台，包括RDS来确保稳定性。
• Docker Swarm作为我们的“调度器”。
• 在引导Swarm时，利用Consul实现服务搜寻。
• Weave Net作为应用自身的网络和服务搜寻。
• Terraform作为我们的供应者（Provisioner）。

这个架构能够快速定义和快速部署，可以很好的来验证我们思路的可行性。但是很快我们遇到了问题。

• Terraform对于Docker作为Provisioner的支持是比较薄弱的，当我们利用它来驱动Swarm时发现了一些bug。
• 主要由于上述的原因，通过Terraform管理部署零宕机的Docker容器是非常困难的。
• Swarm的存在理由是为了抽象多节点容器调度的细节（particulars），它是在我们熟知的Docker CLI/API背后完成的。但是我们给出的结论是，这些API不足以表现出在量化生产当中的需求操作能力。
• Swarm没有提供容错机制，比如节点故障。

我们在设计工作流（workflow）的时候也犯了很多错误。

• 在构建时，我们用每个容器的目标环境标识了容器节点，这样简化了Terraform的定义，但是实际上妨碍了我们通过镜像仓库来管理架构的版本。
• 因此，每一个配置都需要人工的push到所有的宿主机。这会使得配置过程非常缓慢，而且根本无法接受回滚（rollback）。
• Terraform设计的目的是提供基础设施，而并不是云应用。这个过程比我们想象的更加的缓慢和严谨。传递一个新的激励事件版本需要花费30分钟，并且要全力以赴。

当我们清楚的认识到这个服务的前景时，我们着眼于长远来重新评估部署模型。

重新将重点定于Kubernates上

虽然只经历了几个月，但是Kubernetes的景观已经发生了很多的变化。

• HashiCorp发布了Nomod
• Kubernetes达到了1.0版本
• Swarm也快到了1.0版本

目前我们遇到的许多问题可以在不改变原有基础架构的条件下解决，所以我们想通过加入一个现有的生态系统以及利用贡献者在该领域的经验来在工业上应用这些优势。

经过一些内部审议，我们针对Nomad和Kubernetes做了一个小规模的实验。我们相对更喜爱Nomad，但是感觉他太简单了所以难以确信它是否能在我们的量产服务中胜任。而且我们发现Kubernetes开发者在我们的GitHub论题当中表现得比较突出。因此，我们决定使用 Kubernetes。

本地化Kubernetes

首先，我们要用Kubernetes重构飞行模式的本地化环境。因为开发者们有的使用Mac系统，有的使用Linux系统，所以本地化环境容器化是非常有必要的。于是我们希望将Kubernetes组件（kubelet，API server，等等）自身在容器中运行。

我们遇到了两个主要问题。第一，也是最常见的，从头开始构建Kubernetes集群比较困难，因为这需要很深的关于Kubernetes工作机理的知识，而且需要相当一段时间才能使各个小的组件全部构建成功。local-cluster-up.sh似乎是Kubernetes开发者的合理工具，而且不需要利用容器和我们找到的第三方解决方案（比如Kubernetes Solo，需要一个专用的VM或者一个特定的平台）。

第二个问题，容器化的Kubernetes仍然缺少几个重要的组件。根据官方的Kubernetes Docker指南构建的是不完善的集群，没有认证或者服务搜寻。我们还遇到了一些可用性问题(#16586, #17157)，这些问题可以通过提交补丁解决，或者是我们自己在主节点构建hyperkube image来解决。

最后，我们通过构建自己的供应脚本来使得这些应用能够正常工作。这需要尝试做很多工作，像生成PKI keys和certificates，以及提供DNS扩展等等。我们还学到了如何将证书生成提交到Docker构建当中，所以下一个阶段会更简单。

Kubernetes on AWS

接下来，我们要将Kubernetes部署到AWS上，并且接通其他的AWS组件。为了让这个服务快速的在生产环境上实现，而且我们仅仅需要该服务支持Amazon就可以了，因此我们决定不利用Weave Net，而用我们已有的供应方案。但是在不久的将来我们肯定会再次回顾这个方案上，通过Kubernetes插件使用Weave Net。

理想上我们是要用到Terraform资源，而且我们发现了几个地方有用到：karaken(利用Ansible)，kubestack(耦合的GCE)，kubernetes-coreos-terraform（过时的Kubernetes）以及coreos-kubernetes。但是他们都构建在CoreOS上，而我们从一开始就希望避免这一部分额外的变动。（在我们的下一次实验当中，我们可能会测试CoreOS。）如果你使用Ansible，你会在主repo上看到应用指南。另外会有开源社区发布的cookbooks和Puppet modules。我希望这些社区能够快速的成长起来。

其他可行的选择似乎只有是kube-up，这是一个收集脚本，提供Kubernetes到各种各样的云供应商。默认情况下，kube-up在 AWS上将主、从节点放在他们自身的VPC当中，或者放在虚拟私有云上。但是我们的RDS实例被提供到默认域的VPC上，这意味着从Kubernetes 从属节点到DB的通信将有可能仅仅通过VPC peering或者是人工的通过开放的RDS VPC防火墙规则来实现。

为了让信息通过VPC点链接，你的目地IP需要在目标VPC的主地址范围之内。但是事实上，从相同的VPC外部的任何地方解析RDS实例主机名都将屈从于公共IP。而且这个问题能够解决是非常重要的，因为RDS为了维护而保留了修改IP的权利。我们之前的基础架构根本不涉及这个问题，因为Terraform脚本简单的将所有东西都放在同一个VPC当中。因此，我试着用Kubernetes效仿，kube-up支持通过指定一个VPC_ID环境变量来安装现有的VPC，于是我试着将Kuberbetes安装到RDS VPC。kube-up成功的实现了，但是通过ELB的服务集成挂掉了，而且经由kube-down的服务停止工作了。之后，我们认为让kube-up保持默认方式是最好的选择，进而将问题转移到RDS VPC上 。

这成为我们遇到的问题中的一个障碍。每一个问题都可以通过隔离来修复，但是利用shell脚本提供远程状态（remote state）这个固有的脆弱性貌似是问题存在的实际根本原因。我们希望Terraform，Ansible，Chef，Puppet等等packages 不断的成熟，迅速的转换。

除了供应，还有好多关于Kubernetes/AWS融合的事情要做。比如，正确类型的Kubernetes 服务自动生成ELB，Kubernetes的确在生命周期的管理上做了很多工作。进一步，Kubernetes的模型领域——服务，pods，replication controller，标签选择器模型等等都是耦合的，而且看起来给了用户适量的表现性，虽然定义文件确实很啰嗦没什么必要。kubectl这个工具很不错，尽管乍一看令人生畏。其中rolling-update命令尤其是绝妙的：精确的语义和表现是我希望系统能具备的。确实，一旦Kubernetes启动运行，它就开始工作，这恰恰是我期望的。这是一件伟大的事情。

结论

经过几周与机器的战役，我们解决了所有的关于Kubernetes/AWS融合的问题，而且我们推出了用于生产的一个合理健壮的基于Kubernetes的系统。

• Kubernetes供应是非常艰难的，因为复杂的自身架构和不足的供应历练。这显示出了我们需要改善的地方。
• Kubernetes的非选择性安全模式需要很长时间才能准确完成。
• Kubernetes领域语言的发展能够跟得上问题的产生。
• 我们在操作我们的应用方面非常的有自信（而且会变得更快）。
• 我们非常高兴来提高Kubernets的广泛使用性，贡献论题以及补丁，而且得益于开源开发的良性循环，我们才能写出如此令人兴奋的软件。

——Peter Bourgon，Weaveworks公司软件工程师

Weave Scope是一个面向容器化App和服务的虚拟化及监测的开源解决方案。对于一个Scope服务宿主机，可以在早期的访问程序中从scope.weave.works申请一个服务邀请。

原文链接： How Weave built a multi-deployment solution for Scope using Kubernetes（翻译：edge_dawn）

来自：http://dockone.io/article/907