文档
Kubernetes 博客
培训
合作伙伴
社区
案例分析
版本列表
Release Information
Kubernetes 文档说明
v1.38
v1.37
v1.36
v1.35
v1.34
v1.33
v1.32
v1.31
v1.30
v1.29
v1.28
v1.27
v1.26
v1.25
v1.24
v1.23
v1.22
v1.21
v1.20
中文 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 上,例如文件存储服务。有人解决了,而且并不复杂。 所以我坚信如果我们着手解决它,很可能回避我们所担心的要轻松许多。也许我应该接受自己的建议,“快速失败”!”