首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为容器和 Kubernetes 构建应用程序的7个最佳实践

当容器和 Kubernetes 变得日益普及时,我们更需要做的是保持清醒,不要被欺骗,误认为应该使用它们来运行任何类型的应用程序。

“可以”和“应该”是有很大区别的,这在容器和 Kubernetes 的应用中也是如此:构建一个专门在容器中运行并使用 Kubernetes 对其进行操作的应用程序(有些人将其称为云原生开发)与将这些容器和编排用于现有的单体应用程序之间是有区别的。

对于刚开始使用容器工作的团队来说,构建专门用于容器和 Kubernetes 的新应用程序可能是最好的起点。

Aqua Security 的战略副总裁 Rani Osnat 说:“容器(和编排)是用于构建、部署和运行云原生应用程序的技术工具,我通常建议那些刚开始使用容器的人使用一个全新的、简单未开发的(greenfield)应用程序作为测试用例。”

如何开发利用 Kubernetes 在容器中运行的应用程序 ,我们请教了几位云原生专家,他们给出了以下七个最佳建议。

现代化的思维方式

如果今天我们要建造新房子,那么采用的风格和方法,和 50 年前的肯定不一样。同理,现在构建软件也需要尝试新的工具和方法。

SADA 首席技术官(CTO)Miles Ward 说过:“如果你要构建应用程序,请以现代的方式构建它!” 。同时,Ward 指出 微服务 和 12 要素(12-factor)方法论 是现代应用程序开发的主要方法。

Ward 指出,尽管微服务和容器可以很好地协同工作,但实际上,在某些情况下,没有必要这样做。同样,微服务也经常会和 Kubernetes 放在一起,但这也不是绝对的硬性要求,单体(monolithic)方法也是可以工作的,只有它可以水平扩展就行。12-factor 方法论也是如此。”

如果你是从头开始构建应用程序,请优先考虑微服务的方法。

Osnat 建议:“为了最大限度地利用容器,可以把我们的应用程序设计成微服务应用程序,这样,即使是刷新单个容器,它也可以正常运行。同时,还应该对其进行结构化,以便容器镜像可以表示独立发布的单元,从而实现高效的 CI/CD。”

“现代化”开发可以通过多种方式来定义。如果要为容器和 Kubernetes 构建应用程序,那么就要做出适合它们的技术选型。

  • 将容器镜像定义为能够独立伸缩的逻辑单元:将数据库、日志记录、监控、负载均衡和用户会话组件分别设置为可独立实现的容器或容器组。
  • 考虑云原生 API:“Kubernetes 具有强大的 API 扩展机制,通过与这些工具集成,我们可以即时利用生态系统中现有的工具,比如命令行实用工具、身份验证等等。

“大多数现代语言和框架都对容器非常友好,” Harness 的 DevOps 倡导者 Ravi Lachhman 说。“如果追溯到几年前,像 Java 这样的运行时都很难遵守容器边界,并且可怕的内存泄露“杀手”可以任意运行。而现在,由于容器和编排系统(尤其是 Kubernetes)的普及,语言和框架已经发展成为相适应的新范式了。”

CI/CD 和自动化

自动化是容器编排的一个关键特征。如果我们构建了一个在 Kubernetes 上的容器中的应用程序,那么实现自动化是必要的,否则,操作可能会不堪重负。

Brillio 的首席架构师 Chander Damodaran 表示:“如果在一开始构建自动化程度低的应用程序和服务,那么随着服务和组件的激增,自动化可能会成为一个瓶颈。”

精心设计的 CI/CD 管道可以将自动化引入到开发和部署过程的各个阶段。

“使用任何一个新的平台都需要进行大量的反复试验和试错。虽然使用 Kubernetes 有很多便利性,但是也会有风险。” Harness 的 Lachhman 说, “拥有一个鲁棒性强的持续交付管道可以确保测试、安全性、变更管理策略等都是遵循建信标准的,从而确保应用程序的有效运行。”

容器镜像尽可能保持轻量

为容器和 Kubernetes 开发应用程序的另一个关键原则是:为了性能、安全性及其他原因,容器镜像越小越好。

确保删除掉应用程序不需要的所有其他软件包,包括 shell 实用程序。

ThoughtWorks CTO 办公室的首席技术专家 Ken Mugrage 说:“镜像中通常会包含一些应用程序运行不需要的程序包,删除这些软件包,只保留我们需要的东西,不仅能够使得镜像更小,还可以减少安全性问题的攻击面。”

CloudBolt 产品营销总监 Nilesh Deo 也赞同了这一观点:“镜像越小,加载速度就越快,应用程序也更快。”

不要盲目地轻信镜像

如果我们重用或重新调整现有的组件就可以达到目的,那么就无需从头开始构建。同样的原理也适用于容器,但是从安全的角度来看,也不能对容器镜像盲目信任。

有太多的人从已经安装了某种应用程序堆栈的存储库中选择镜像。

“有太多人从已经安装了某种应用程序堆栈的存储库中选择镜像,” Mugrage 说。“通常情况下,这些镜像的质量不佳,而且往往还会存在不容忽视的安全性风险。我们在使用任何镜像的时候,即使是我们自己存储库中的镜像,在每次运行时都应在部署管道中对其进行扫描,以检查漏洞和合规性。”

一开始就应计划可观察性、遥测和监控

Kubernetes 的自愈能力是其具有吸引力的原因之一,但同时 Kubernetes 也强调了使应用程序和环境具有适当可见性的必要性。

“故障”本质上是容器和微服务的一部分,当然这里的指的是故障管理,而不是故障规避。这也是体现可观察性、遥测和监控的关键部分。

Sentry.io 的软件工程师 Andrei Zbikowski 说:“ Kubernetes 具有内置的弹性机制,这就需要将全面监控作为最佳实践。它的自愈功能可以重新启动发生故障的容器,或在不满足某些健康参数的情况下替换并终止其他容器。虽然这一定程度上保证了应用程序的正常启动和运行,但是也掩盖了一些问题。”

“缺乏代码可见性意味着应用程序随时可能抛出错误,即使是在健康指标显示一切正常的时候,”Zbikowski 表示:“因此,监控应用程序以及容器和后端系统是非常重要的。全面的监控方法能提高问题和事件的可见性,以便在造成重大影响之前,及时识别和纠正错误。”

Mugrage 表示:“如果在投入生产之后,再尝试对容器化应用程序进行监控,那么结果可能不尽如人意。所以,从一开始,我们就应该考虑可观察性和监控,尤其是分布式应用程序。”

Red Hat 技术专家 Gordon Haff 表示:“大量的云原生技术工具箱可用于在应用程序中构建复杂的监控、跟踪、服务网格和仪表板,例如我们常听到的 Prometheus、Jaeger、Kiali 和 Istio 等等。当然工具种类繁多,也会使得技术选型成为一项有挑战性的工作。”

从无状态应用程序开始

关于容器和 Kubernetes 的一个早期思路是:运行无状态应用程序比运行有状态应用程序(例如数据库)要容易得多。随着 Kubernetes Operator 的增长,这种情况发生了变化,不过,对于刚刚接触 Kubernetes 的团队来说,从无状态应用程序入手可能是更好的选择。

Plotly 联合创始人 Chris Parmer 表示,“从无状态应用程序入手,通过无状态的后端,开发团队可以确保没有长期运行的连接,以及难以扩展的可变状态,还能在无需停机的情况下轻松部署应用程序,使得最终用户的请求并行地传递到不同的容器中。”

Parmer 指出,可伸缩性是在 Kubernetes 上运行容器的主要优势之一,而使用无状态应用程序能更容易地实现该优势。

“无状态应用程序使得根据需求进行迁移和扩展变得很容易,为了满足组织的业务需求,它允许团队随意添加或删除容器,” Parmer 说。“通过使用建立在无状态后端上的 Web 应用程序框架,我们可以充分利用 Kubernetes 集群。”

构建 Kubernetes 环境很难

“如今,Kubernetes 中没有任何抽象可以使底层系统更容易理解。它们只会使其更易于使用。” Red Hat OpenShift 首席技术营销经理 Chris Short 说。“当然,如果这很容易,那么每个人就都已经做到了,行业也会从对 Kubernetes 的吹捧转向到下一个大事件。我们在进行容器编排的同时,除了需要抽象集群的状态和底层的基础架构之外,还需要管理很多其他的东西。如果你有完美构建 Kubernetes 环境的实践经验,欢迎分享给我们。”

原文链接:

https://enterprisersproject.com/article/2020/3/kubernetes-best-practices-building-applications-containers

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/w3dYSbdDa5IOhpDLaVrY
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券