尽管容器和KubeRnetes正在迅速普及，但首先我们需要明确，它们并不适合所有应用程序类型。在“可以”和“应该”之间，必须建立清晰的界限。例如，专为容器和KubeRnetes编排而设计的应用程序，与传统单体应用程序之间存在显著差异。
对刚进入容器领域的团队而言，构建全新的、专为容器和KubeRnetes设计的应用程序通常是一个理想的起点。Aqua Security公司的战略副总裁Rani Osnat表示，容器和编排技术是构建、部署和运行云原生应用程序的重要工具。我建议刚接触容器技术的人以简单的新应用程序作为测试用例。
为了探讨如何使用容器和KubeRnetes进行应用开发，我们咨询了Osnat及其他多位云原生技术专家，汇总出以下七项最佳实践。
考虑并建立现代架构
正如50年前的建筑风格与现代建筑大相径庭，软件构建也应尽量采用新工具和方法。
SADA公司的CTO Miles Ward表示，如果您计划构建一款应用，请务必采用现代的方法。他指出，微服务和十二要素方法论（12-Factor）应成为现代应用程序开发的核心原则。
Ward还提到，尽管微服务与容器技术可以良好配合，但大多数开发场景并不强制要求这种匹配。微服务与KubeRnetes常被视为一体，但这并非必需。单体式开发同样适用，只需确保其既可作为单体部署，也可作为同一代码库上的不同端点进行横向扩展。此外，十二要素方法论是良好的起点，但并非不可或缺的教条。
Osnat建议，为了最大程度利用容器技术，应用程序应设计为微服务架构，以确保在单个容器更新时仍能正常运行。同时，结构化设计应确保容器镜像只代表独立发布单元，从而实现有效的CI/CD机制。
现代开发通常通过多种方式定义。如果要为容器和KubeRnetes构建应用程序，需选择合适的打包和技术部署选项。以下是两个示例：
将容器镜像定义为可以独立扩展的逻辑单元：将数据库、日志记录、监控、负载均衡和用户会话组件实现为容器或容器组。考虑使用云原生API：KubeRnetes提供强大的API扩展机制，通过与容器工具集成，可以立即利用生态系统中的现有解决方案选项，例如命令行工具和身份验证。
从软件开发的角度来看，现代化也是一项利好。HaRneSS公司的DevOps倡导者Ravi LachHMan指出，许多现代语言和框架的最佳特性就是能够与容器无缝对接。几年前，像Java这样的语言在容器边界的体现上还有困难。如今，随着容器和KubeRnetes等编排工具的流行，语言和框架迎来了新的发展范式。
充分利用CI/CD与自动化的优势
自动化是容器编排的重要特征，几乎成为构建容器内应用程序的核心要素。没有自动化，现代应用的运营负担将难以承受。
BRillio公司的首席架构师ChandeR DaModaRan建议，以自动化方式构建应用程序和服务可以显著降低风险。随着服务和组件数量的增加，应用及服务的运营可能会面临严峻挑战。
精心设计的CI/CD管道将尽可能多地引入自动化，这已成为当前流行的趋势。我们也可以通过另一种方式理解自动化的价值：它能够更轻松地消除错误，尤其是在开发初期难以避免的各种错误。
HaRneSS公司的LachHMan强调，使用新平台往往需要大量反复试验，而KubeRnetes本身并不能抵消潜在错误。只有建立稳健的持续交付管道，才能真正形成可靠的标准，如测试、安全性和变更管理策略，从而确保应用程序高效运作。
保持容器镜像轻量化
在容器和KubeRnetes开发应用程序时，另一个重要原则是尽量保持镜像轻量化，以满足性能、安全及其他要求。
THoughtWoRks公司的CTO办公室首席技术专家Ken MugRage表示，只保留绝对必要的内容。镜像中常常包含应用程序所不需要的多余包。因此，应移除所有不必要的软件包，包括Shell工具。这不仅能缩小镜像体积，也能减少攻击面。
CloudBolt公司的产品营销负责人Nilesh Deo也同意这一观点，开发人员需重新审视自己的应用开发方法，例如创建更小的容器和基础镜像。镜像越小，加载速度越快，应用程序的运行速度也就越快。
不要盲目信任镜像
在软件开发中，我们常常重用现有组件，以避免“重复造轮子”。在容器开发中更是如此，但从安全角度出发，不应盲目相信镜像，特别是要警惕其中可能存在的安全缺陷。
MugRage表示，许多人在Repo中选择镜像时，没有注意到其中可能包含的某些应用栈。这些镜像往往质量不高，甚至存在严重的安全问题。我们使用的任何镜像，包括自有Repo的镜像，都应在部署管道的每次运行前进行扫描，以检查漏洞和合规性。
在起步阶段就规划可观察性、遥测与监控机制
故障是容器与微服务的一部分，这里强调的是故障管理，而非完全避免故障。KubeRnetes的自我修复功能无疑是其核心吸引力之一，但也要求用户具备适当的可见性。在这方面，可观察性、遥测和监控机制是至关重要的能力。
SentRy.io公司的软件工程师AndRei ZBIkowski指出，KubeRnetes具备内置弹性机制，符合最佳监控实践。其自我修复功能可以在某些健康参数不满足时，重新启动故障容器或替换其他容器。这一功能虽然能保持应用程序正常运行，但也可能掩盖其他问题。
ZBIkowski补充，缺乏对代码的可见性，可能导致应用程序随时抛出错误，但管理者因为运行指标的正常而误以为一切良好，因此监控应用程序以及容器/后端系统至关重要。全面的监控方法必须具备提升问题广泛可见性的能力，以便在重大影响发生前及时识别和解决问题。
MugRage指出，起步阶段就应考虑到可观察性和监控需求。对分布式应用程序进行故障排查往往极为困难，这一点必须在应用程序设计时就考虑到。
红帽公司的技术布道师Gordon HaFF表示，使用多种云原生技术工具，可以在应用程序中建立复杂的监控、跟踪、服务网格和仪表板。例如PRoMetheUS、Jaeger、Kiali和Istio等都在此列，但工具种类繁多，这也使得技术选型成为一项挑战。
考虑从无状态应用程序入手
通常情况下，运行无状态应用程序比运行有状态应用程序要容易得多。随着KubeRnetes运营商的增加，情况有所不同。对于刚入门KubeRnetes的团队而言，运行无状态应用程序可能是更佳选择。
Plotly公司的联合创始人Chris Palmer指出，如果只能选择一条最佳实践，我建议从无状态应用程序开始。通过无状态后端，开发团队可以确保没有需要长期运行的连接或可变状态，从而大大降低扩展难度。开发人员还能够在零停机时间的情况下轻松部署应用程序，确保最终用户的请求可以并行传递至不同容器。
Palmer指出，可扩展性是KubeRnetes上运行容器的主要优势，而使用无状态应用程序更有助于发挥这一优势。
无状态应用程序使开发团队能够更轻松地迁移和扩展容器，以满足组织业务需求，包括随意添加或删除容器。通过使用基于无状态后端的Web应用程序框架，我们可以最大化KubeRnetes集群的收益。
构建容器化并非易事
迄今为止，KubeRnetes中仍然没有任何抽象能够使其底层系统真正易于理解，或者说现有方案只能使其更易使用。红帽OpenShift的首席技术营销经理Chris Short指出，这并不容易，否则每个人都能构建KubeRnetes。我们在进行容器编排时，消除了集群状态和底层基础设施的“存在感”，甚至管理方面的需求。Etcd是KubeRnetes的一个重要依赖，许多厂商都在努力将其隐藏。KubeRnetes涉及网络、安全等复杂内容。只有做好失败的准备，团队才能真正迈出探索KubeRnetes的步伐，接受现代架构的挑战。
