文档
Kubernetes 博客
培训
合作伙伴
社区
案例分析
版本列表
Release Information
v1.32
v1.31
v1.30
v1.29
v1.28
v1.27
v1.26
v1.25
v1.24
v1.23
v1.22
v1.21
中文 Chinese
English
您正在查看 Kubernetes 版本的文档: v1.21
Kubernetes v1.21 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击
最新版本。
案例分析:
Squarespace: 借力 Kubernetes 提升效率和可靠性
公司名
Squarespace
地址
纽约市,纽约州
行业
软件服务,网站构建平台
挑战
自从 2014 年,我们从 monolith 架构移植到微服务架构, “虽然解决了开发端的问题,但却带来了架构组的问题”,Squarespace 网站可靠性组的主任工程师 Kevin Lynch 说道。 “5000 个 VM 主机上的部署过程,让每个人都举步维艰。”
解决方案
网站可靠性组开始尝试使用不同的容器编排平台,然后发现 Kubernetes “解决了我们所有的既有问题”,Lynch 说道。于是整个公司在 2016 年开始在自己的数据中心中运行 Kubernetes 集群。
影响
自从 Squarespace 开始全面使用 Kubernetes,伴随着网络技术栈的革新,部署时间大幅减少85%。 以前,他们的 VM 部署需要耗费半个小时;现在,Lynch 提到,“一个人可以生成一个模板应用,在五分钟内部署,并将实例容器化,并在模拟环境下运行。”正因为如此,“开发效率节省了大量的成本。” 他又补充道,“当我们开始用 Kubernetes 时,我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。” Kubernetes 也同样提升了可靠性:“如果一个节点宕掉,马上会重新调度一个新的节点,没有任何性能上的影响。”
“一旦你验证了 Kubernetes 可以解决一个问题,每个人都会立即着手解决其它的问题,无需你的布道。”
— Kevin Lynch,Squarespace 网站可靠性组的主任工程师
从 2003 年宿舍起步, Squarespace 已经为数百万人提供了网站构建服务。
但在幕后,公司的单体应用却让开发人员在平台创新上举步维艰。所以在 2014 年,公司决定”走微服务之路”,Kevin Lynch 提到,Squarespace 网站稳定性组的主任工程师。 “但是我们还是一直在自己的 vCenter VMware 虚拟机[我们自己的数据中心]上部署应用。微服务解决了开发端的问题,但是让问题转变到了基础架构组这一边。我们在5000个虚拟机主机上的部署流程让每个人的开发效率都提高不起来。” 在尝试过另外一个容器编排平台,“非常痛苦地拆解它”,Lynch 说道,我们组开始在 2016 年年中尝试 Kubernetes,发现它“能解决我们所有的问题”。 将 Kubernetes 部署在数据中心,而非公有云上是我们最大的挑战,但在当时,并没有很多其它的公司会这么做。 “我们必须要自己摸索出如何在自己的基础架构中部署它,我们也必须要将其和我们其它的应用做集成,”Lynch补充道。
与此同时,Squarespace 的网络工程组也正在革新它们的网络技术栈,从传统的 L2 网络转变为 L3 脊叶网络架构。 “” Lynch 说道,“它给了我们服务器直接通过架顶交换机通信的能力。我们使用 Calico 作为
Kubernetes 的 CNI 网络插件
”, 因而,我们可以为每个 Kubernetes pod 分配 IP 地址,并将它们和其它仍在虚拟机中创建的服务无缝衔接。
在尝试过另外一个容器编排平台,“非常痛苦地拆解它”,Lynch 说道,我们组开始在 2016 年年中尝试 Kubernetes,发现它“能解决我们所有的问题”。
几个月的时间,它们就有了一个稳定的集群供内部使用,并开始在生产环境下使用 Kubernetes。 他们同时还在自己的云原生技术栈中用到了 Zipkin 和 CNCF 项目
Prometheus
and
fluentd
。 “我们换到 Kubernetes,就像进入了一个新世界,我们也同时改进了其它的工具,” Lynch 说道。“它让我们简化了流程,因而,我们才能更加方便地从模板中创建整个微服务项目,生成代码和部署管道,生成 Docker 文件, 并迅速地将可用的、可部署的项目发布到 Kubernetes 集群上。”在 Dev/QA/Stage/Prod 不同环境间的部署也变得 “异常的简单,” Lynch 补充道。 “现在,环境间的配置差异变得很小。”
而且整个部署过程只需要五分钟,和虚拟机部署相比,几乎节约了 85% 的时间。 “从端到端可能要半个小时,这还没有考虑可能需要基础架构工程师来做这方面的工作,因而,也还有一些业务上的延时。”
部署变快之后,“开发效率节省了大量的成本,” Lynch 提到,“我们有个组想要实现新的文件存储服务,他们就径直和我们的存储后来做了集成,而不需要我们的参与”,这在采用 Kubernetes 之前是不可想象的。 他又补充道:“在我们开始 Kubernetes 项目时,我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。”
“我们换到 Kubernetes,就像进入了一个新世界....它让我们简化了流程,因而,我们才能更加方便地从模板中创建整个微服务项目,” Lynch 说道。整个部署过程只需要五分钟,和虚拟机部署相比,几乎节约了 85% 的时间。
同样在应用程序的可靠性方面也有积极的影响。“当我们在部署虚拟机时,我们需要工具来保障服务散布在机架间,可以承受失败,”他说道,“Kubernetes 正好可以做到这一点。如果节点宕掉,可以马上重新调度,没有性能影响。”
另一个很大的好处就是扩缩容。“按照我们使用 VMware 的方式,扩缩容好像不可能实现,”Lynch 说道,“但现在,我们可以直接通过 Kubernetes 加入合适的扩缩容功能,然后,随着需求的增加而扩容。开箱即用!”
针对刚开始使用 Kubernetes 的人,Lynch 说他最后的建议就是“快速失败”:“一旦计划后,马上执行。Kubernetes 真的是非常适合快速实验,看看是否可行。”
“当我们在部署虚拟机时,我们需要工具来保障服务散布在机架间,可以承受失败,”他说道,“Kubernetes 正好可以做到这一点。如果节点宕掉,可以马上重新调度,没有性能影响。”
Lynch 和他的小组正准备开源一些他们的工具,这些工具用来延展 Kubernetes,将其作为 API 使用。 第一个工具在 pod 将依赖应用作为容器注入。 “当你在发布应用时,常常需要一系列的依赖应用,例如,日志用的 fluentd,” 他解释道。 有了这个工具,开发人员就不需要担心配置了。
自此之后,Squarespace 所有新的微服务都将直接部署到 Kubernetes 上,而最终的目标是要扩大到所有的服务上。 现在已经有四分之一的服务已经移植完。“我的单体应用将是最后一个被移植的,仅仅是以为它太大、太复杂,”Lynch 说道。 “但现在我已经看到其它的服务已经被移植到 Kubernetes 上,例如文件存储服务。有人解决了,而且并不复杂。 所以我坚信如果我们着手解决它,很可能回避我们所担心的要轻松许多。也许我应该接受自己的建议,“快速失败”!”