为容器和 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