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

今天,我们听到了Weaveworks软件工程师Peter Bourgon的话,该公司为开发人员提供软件,以便他们在Docker容器中联网,监视和控制基于微服务的应用程序。彼得告诉我们选择和部署Kubernetes涉及到什么 

今年早些时候,我们在Weaveworks推出了 编织范围,这是一个用于可视化和监视容器化应用程序和服务的开源解决方案。最近,我们将托管的Scope服务发布到了 抢先体验计划。今天,我们想向您介绍如何初步构建该服务的原型,以及如何最终选择和部署Kubernetes作为我们的平台。

云原生架构 

Scope在数据收集和用户交互之间已经有了一条清晰的内部分界线,因此可以很轻松地在该行上拆分应用程序,向客户分发探针并在云中托管前端。我们在 12因子模型, 包括:

  • 用户服务,用于管理和验证用户帐户 
  • 供应服务,用于管理客户范围实例的生命周期  
  • 一个UI服务,托管所有精美的HTML和JavaScript内容 
  • 前端服务,根据其属性路由请求 
  • 监视服务,以检查系统的其余部分 

所有服务均构建为Docker映像, 从头开始 在可能的情况。我们知道我们想提供至少3个部署环境,它们应尽可能接近相同。 

  • 每个开发人员的笔记本电脑上的“飞行模式”本地环境 
  • 在托管生产的同一基础结构上使用不同的用户凭据的开发或暂存环境 
  • 生产环境本身 

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

我们的第一个原型 

似乎有无限的选择集,还有无限的可能组合。在2015年中对景观进行调查后,我们决定制作一个原型

  • 亚马逊EC2 作为我们的云平台,包括用于持久性的RDS  
  • 码头工人 作为我们的“调度员” 
  • 领事 引导Swarm时进行服务发现 
  • 编织网 应用程序本身的网络和服务发现 
  • 地貌 作为我们的供应商 

这种设置可以快速定义和部署,因此是验证我们想法可行的好方法。但是我们很快遇到了问题。 

  • 地貌对 Docker作为供应商 是准系统,我们发现了 一些错误 尝试使用它来驱动Swarm时。 
  • 由于上述原因,使用Terraform管理Docker容器的零停机部署非常困难。 
  • 虫群 理由 是在熟悉的Docker CLI / API命令之后抽象多节点容器调度的细节。但是我们得出的结论是,对于大规模生产中必需的那种操作,API的表达不足。 
  • Swarm不提供容错功能,例如节点故障。 

在设计工作流程时,我们还犯了许多错误。

  • 我们在构建时用目标环境标记了每个容器,这简化了Terraform定义,但有效地迫使我们通过映像存储库管理版本。该责任属于调度程序,而不是工件存储。 
  • 结果,每次部署都需要将工件推送到所有主机。这使部署速度变慢,并且回滚难以忍受。 
  • 地貌旨在提供基础架构,而不是云应用程序。这个过程比我们想要的要慢和刻意。将产品的新版本交付生产大约需要30分钟。 

当明确该服务具有潜力时,我们就着眼于长期重新评估了部署模型。

依靠Kubernetes 

仅仅几个月,但情况发生了很大变化。

尽管可以在不进行根本性架构更改的情况下解决许多问题,但我们希望通过加入现有的生态系统并利用其贡献者的经验和辛勤工作来利用行业的进步。 

经过一些内部商议之后,我们对Nomad和Kubernetes进行了小型试听。我们非常喜欢Nomad,但是觉得现在依靠我们的生产服务还为时过早。此外,我们发现Kubernetes开发人员对GitHub上的问题反应最快。因此,我们决定选择Kubernetes。

本地Kubernetes 

首先,我们将使用Kubernetes复制“飞机模式”本地环境。由于我们在Mac和Linux笔记本电脑上都有开发人员,因此对本地环境进行容器化非常重要。因此,我们希望Kubernetes组件本身(kubelet,API服务器等)可以在容器中运行。

我们遇到了两个主要问题。首先,也是最广泛的说,从头开始创建Kubernetes集群是困难的,因为它需要对Kubernetes的工作原理有深入的了解,并且需要相当长的时间才能将各个部分放在一起。 本地群集up.sh 似乎是Kubernetes开发人员的工具,并且没有利用容器,而我们发现的第三方解决方案,例如 Kubernetes独奏,需要专用的VM或特定于平台。

其次,集装箱式Kubernetes仍然缺少一些重要的方面。继 Kubernetes官方Docker指南 产生没有证书或服务发现的准系统群集。我们还遇到了一些可用性问题(#16586, #17157),我们通过 提交补丁 并建立我们自己的 超立方体图像 来自主人。

最后,我们通过创建自己的配置脚本来使事情正常进行。它需要做类似的事情 生成PKI密钥和证书设置DNS加载项,它花了一些时间才做对。我们还了解到 承诺将证书生成添加到Docker构建中,因此短期内事情可能会变得更容易。

AWS上的Kubernetes 

接下来,我们将Kubernetes部署到AWS,并将其与其他AWS组件连接起来。我们希望在生产中迅速站起来该服务,而我们只需要支持Amazon,因此我们决定在没有Weave Net的情况下这样做,并使用预先存在的供应解决方案。但是,我们肯定会在不久的将来重新审视此决定,并通过Kubernetes插件利用Weave Net。

理想情况下,我们应该使用Terraform资源,然后发现了几个: 海妖 (使用Ansible), kubestack (与GCE耦合), kubernetes-coreos-terraform (过时的Kubernetes)和 coreos-kubernetes。但是它们都建立在CoreOS上,这是我们一开始要避免的额外动作。 (在下一次迭代中,我们可能会试听CoreOS。)如果您使用Ansible,则有 可用的剧本 在主仓库中。还有社区驱动 厨师食谱人偶模块。我希望社区在这里能够迅速发展。

唯一可行的选择似乎是kube-up,这是将Kubernetes设置到各种云提供商的脚本的集合。默认情况下,对AWS进行kube-up会将主节点和小节点放入其自己的VPC或虚拟私有云中。但是我们的RDS实例是在默认区域VPC中配置的,这意味着从Kubernetes奴才到DB的通信只能通过 VPC对等 或通过手动打开RDS VPC的防火墙规则。

为了使流量穿越VPC对等链接,目标IP必须在目标VPC的专用地址范围内。但 原来 从同一VPC之外的任何位置解析RDS实例的主机名将产生公共IP。解决问题很重要,因为RDS保留更改IP进行维护的权利。在以前的基础架构中,这不再是一个问题,因为我们的Terraform脚本只是将所有内容放置在同一VPC中。所以我以为我会在Kubernetes上尝试相同的方法。 kube-up脚本表面上通过指定VPC_ID环境变量来支持安装到现有VPC,因此我尝试将Kubernetes安装到RDS VPC。拼搏似乎成功了,但是 通过ELB的服务集成中断通过kube-down进行拆解停止工作。一段时间后,我们判断最好让kube-up保持默认值,然后在RDS VPC中戳一个洞。

这是我们遇到的几个小问题。可以单独解决每个问题,但是使用shell脚本提供远程状态所固有的脆弱性似乎是实际的根本原因。我们完全期望Terraform,Ansible,Chef,Puppet等软件包将继续成熟,并希望尽快进行转换。

除了配置,还有关于Kubernetes / AWS集成的很棒的事情。例如Kubernetes 服务 正确类型的设备会自动生成ELB,而Kubernetes在那里的生命周期管理工作做得很好。此外,Kubernetes域模型-服务, 豆荚, 复制控制器标签和选择器型号等等)是连贯的,尽管定义文件确实可以为用户提供适量的表达能力 倾向于不必要地结巴。 kubectl工具很好,尽管 乍一看令人生畏。的 滚动更新 命令特别出色:我希望从这样的系统中获得准确的语义和行为。确实,一旦Kubernetes启动并运行, 它只是工作,并且完全符合我的预期。那是一件大事。

结论 

经过两周的机器奋战,我们能够解决所有集成问题,并已将相当强大的基于Kubernetes的系统投入生产。

  • 设置Kubernetes很困难 ,这归功于复杂的架构和年轻的供应故事。这显示出所有改善的迹象。 
  • Kubernetes的非可选 安全模型需要时间才能正确
  • Kubernetes 领域语言非常适合 到问题域。 
  • 我们有 更有信心 操作我们的应用程序(速度也快得多)。 
  • 而我们 很高兴成为不断增长的Kubernetes用户群的一部分 ,尽我们所能,发布问题和补丁,并受益于开放源代码开发的良性循环,这种循环为当今编写的最令人兴奋的软件提供了动力。   -Weaveworks的软​​件工程师Peter Bourgon

编织范围是一个开源解决方案,用于可视化和监视容器化的应用程序和服务。对于托管的Scope服务,请在scope.weave.works中请求“早期访问”程序的邀请。