当前位置: 首页 > 科技观察

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

时间:2023-03-12 18:49:27 科技观察

随着容器和Kubernetes越来越流行,我们需要做的是保持清醒,不要被欺骗认为我们应该使用它们来运行任何类型的应用程序。“可以”和“应该”之间有很大的区别,这也适用于容器和Kubernetes:构建一个专门在容器中运行的应用程序并使用Kubernetes对其进行操作(有人称之为云原生开发)并使用这些现有单体应用程序的容器和编排。对于刚刚开始使用容器的团队,专门为容器和Kubernetes构建新应用程序可能是最好的起点。AquaSecurity战略副总裁RaniOsnat表示:“容器(和编排)是用于构建、部署和运行云原生应用程序的技术工具,我通常建议那些不熟悉容器的人使用新的、简单的未开发的(绿地)应用程序作为测试用例。”我们询问了几位云原生专家如何开发利用Kubernetes在容器中运行的应用程序,这里是他们的七个最佳技巧。1.现代思维方式如果我们今天要盖一座新房子,风格和方法将是与50年前不同。同样,构建软件现在需要尝试新的工具和方法。SADA首席技术官(CTO)MilesWard说:“如果您要构建应用程序,请将其构建为现代的Ward!”同时,Ward指出微服务和12-factor(12因子)方法论是现代应用程序开发的主要方法。Ward指出,虽然微服务和容器可以很好地协同工作,但在实践中,在某些情况下,这不是必需的。类似地,微服务通常与Kubernetes位于同一位置,但这不是绝对要求,单体方法可以工作,只要它可以水平扩展即可。12因素方法论也是如此.“如果您要从头开始构建应用程序,请优先考虑微服务方法。”Osnat建议:“为了充分利用容器,我们可以将我们的应用程序设计为微服务应用程序,这样即使刷新单个容器,它也能正常工作。同时,它应该结构化,使容器镜像可以代表独立发布的单元,从而实现高效的CI/CD。“现代”发展可以有多种定义。如果你想为容器和Kubernetes构建应用程序,那么你需要为它们做出技术选择。将容器镜像定义为可独立扩展的逻辑单元:数据库、日志记录、监控、负载平衡和用户会话组件均设置为可独立实施的容器或容器组。考虑云原生API:“Kubernetes具有强大的API扩展机制,通过与这些工具集成,我们可以立即利用现有工具,例如命令行实用程序、身份验证等。“大多数现代语言和框架都非常适合容器,”RaviLachhman说,Harness的DevOps倡导者。“如果你回到几年前,像Java这样的运行时很难遵守容器边界,可怕的内存泄漏‘杀手’随意运行。现在,由于容器和编排系统(尤其是Kubernetes)的流行,语言和框架已经演变成一种新的范式。”2.CI/CD和自动化自动化是容器编排的一个关键特性。如果我们构建一个应用程序在Kubernetes上的容器中,那么自动化是必要的,否则,操作可能会不堪重负。Brillio首席架构师ChanderDamodaran表示,“如果一开始就构建自动化程度较低的应用程序和服务,那么自动化可能会成为瓶颈,因为服务和组件激增。”设计良好的CI/CD管道可以将自动化引入到开发和部署过程的各个阶段。“使用任何新平台都需要大量的试验和错误。虽然使用Kubernetes有很多便利,但也存在风险,”Harness的Lachhman说。“拥有强大的持续交付管道可以确保测试、安全、变更管理策略等符合CCB标准,以确保应用程序高效运行。”3.保持容器镜像尽可能轻量为容器和Kubernetes开发应用程序的另一个关键原则是:出于性能、安全等原因,容器镜像越小越好。确保删除应用程序不需要的所有其他包,包括shell实用程序。ThoughtWorksCTO办公室首席技术专家KenMugrage表示:“镜像通常包含一些应用程序运行不需要的包。删除这些包并只保留我们需要的包,不仅会使镜像变小,而且会降低安全性。”攻击面。”CloudBolt产品营销总监NileshDeo对此表示赞同:“图像越小,加载速度越快,应用程序也越快。”4.不要盲目信任镜像,如果我们重用或重新调整现有组件就可以了,所以没有必要从头开始构建。同样的原则适用于容器,但从安全的角度来看,你不能盲目信任容器太多人从已经安装了某种应用程序堆栈的存储库中选择镜像。“太多人从已经安装了某种应用程序堆栈的存储库中选择镜像,”Mugrage说。“通常,这些图像质量很差并且经常会带来不容忽视的安全风险。当我们使用任何图像时,即使是来自我们自己存储库的图像,也应该在部署管道中扫描它以查找漏洞和合规性。”5.从一开始就规划可观察性、遥测和监控Kubernetes的自我修复能力是它具有吸引力的原因之一,但同时也强调了对应用程序和环境的适当可见性的需要。“故障”本质上是容器和微服务的一部分,当然我这里指的是故障管理,而不是故障避免。这也是可观察性、遥测和监控的关键部分。Sentry.io的软件工程师AndreiZbikowski表示:“Kubernetes具有内置的弹性机制,这需要将全面监控作为最佳实践。它的自我修复能力可以重启失败的容器,或者在不满足某些健康参数时进行替换。并在出现错误时终止其他容器。虽然这在一定程度上保证了应用程序的正常启动和运行,但也掩盖了一些问题。“缺乏代码可见性意味着应用程序可能随时抛出错误,即使在健康指标显示一切正常时,”Zbikowski说:“因此监控应用程序以及容器和容器非常重要。后端系统。全面的监控方法提高了问题和事件的可见性,因此可以在错误产生重大影响之前识别并纠正错误。“如果你试图在容器化应用程序投入生产后对其进行监控,结果可能不会如你所愿,”Mugrage说。所以,从一开始,我们就应该考虑可观察性和监控性,尤其是对于分布式应用程序。”红帽技术专家GordonHaff表示:“大量的云原生技术工具箱可用于在应用程序中构建复杂的监控、跟踪、服务网格和仪表板,例如我们经常使用的Prometheus、Jaeger、Kiali和Istiohear等。当然,工具的种类繁多,这也会让技术选型成为一项具有挑战性的工作。6.从无状态应用程序开始关于容器和Kubernetes的早期想法是,运行无状态应用程序比运行有状态应用程序(如数据库)要容易得多。随着KubernetesOperator的发展,这种情况发生了。但是,对于刚接触Kubernetes的团队来说,从无状态应用程序入手可能是更好的选择。Plotly联合创始人ChrisParmer表示,“从无状态应用程序开始,通过无状态后端,开发团队可以确保没有长时间运行的连接、难以扩展的可变状态,并且可以在不停机的情况下轻松部署应用程序,从而最终用户的请求被并行传递到不同的容器。Parmer指出:“可扩展性是在Kubernetes上运行容器的主要好处之一,而无状态应用程序更容易实现这一点。无状态应用程序使迁移和扩展变得容易根据需要,它允许团队随意添加或删除容器,以满足组织的业务需求,”Parmer说。“通过使用构建在无状态后端上的Web应用程序框架,我们可以充分利用Kubernetes集群。“7.构建Kubernetes环境很难”如今,Kubernetes中没有抽象可以让底层系统更容易理解。它们只是让它更容易使用。RedHatOpenShift首席技术营销经理ChrisShort说。“当然,如果这很容易,那么每个人都已经在这样做了,整个行业就会从炒作Kubernetes转向下一件大事。我们正在做容器编排,除了抽象集群的状态和底层foundation除了架构,还有很多其他的东西需要管理,如果你有构建完美Kubernetes环境的实践经验,欢迎分享给我们。”