【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

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

  • 2020-03-27
  • 本文字数:3150 字

    阅读完需:约 10 分钟

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


2020-03-27 09:281676

评论

发布
暂无评论
发现更多内容

2020互联网公司中秋礼盒大比拼!(文末送福利)

Java架构师迁哥

Greenplum 性能优化之路 --(三)ANALYZE

腾讯云大数据

大数据 数据仓库

经常使用的数据结构

hasWhere

FastDFS 分布式文件系统详解

哈喽沃德先生

文件系统 分布式文件存储 fastdfs 分布式文件

Java源码系列2——HashMap

超超不会飞

Java

Java源码系列4——HashMap扩容时究竟对链表和红黑树做了什么?

超超不会飞

Java

Nexmark: 如何设计一个流计算基准测试?

Apache Flink

flink

Java源码系列3——LinkedHashMap

超超不会飞

Java

烦人的Null,你可以走开点了

四猿外

Java 注解 空指针 Optional null

Smartisan

Changing Lin

摄影

码住!Flink Contributor 速成指南

Apache Flink

flink 开源社区

鲲鹏播种于时代,花开五色中原

脑极体

架构师训练营第三周作业

邓昀垚

极客大学架构师训练营

【架构笔记之设计模式】架构师训练营第1期第3周

业哥

极客大学架构师训练营

Greenplum 性能优化之路 --(二)存储格式

腾讯云大数据

大数据

架构师训练营第1期第3周作业

业哥

极客大学架构师训练营

一个好系统自我完善自我进化的方法

boshi

产品思维 系统工程 即时反馈 生态体系

架构师训练营 1 期 - 第三周 - 设计模式

三板斧

极客大学架构师训练营

太牛了,这份神仙级面试笔记把所有 Java 知识面试题都详解出来了

Java架构之路

Java 程序员 面试 编程语言

在 InfoQ 兼职做运营

邓瑞恒Ryan

创业 用户增长 创业心态 运营 产品运营

我一定是熬夜熬傻了,小程序后台获取用户信息居然发生了这件事

小Q

Java 小程序 学习 编程 架构

传统网络缺失货币层,比特币是否能担此大任?

blockchain

比特币 区块链 数字货币 比特币数字货币 区块俩金融

优秀组织的5大表现

凌晞

团队管理 团队组织 组织

第三周学习代码重构总结

三板斧

极客大学架构师训练营

CSS语法与规则 — 重学CSS

三钻

CSS 大前端

基于 Flink + Hive 构建流批一体准实时数仓

Apache Flink

flink

架构师训练营第 1 期第 3 周学习总结

好吃不贵

极客大学架构师训练营

一个Hibernate的事务问题

YoungZY

hibernate

【FastDFS】SpringBoot整合FastDFS实战,我只看这一篇!!

冰河

springboot fastdfs

高中生写LOL外挂1年狂赚五百万,落网前刚买下120万保时捷

Java架构师迁哥

Dromara团队发布Hmily全新架构的2.1.1版本

猫大人

分布式事务 分布式柔性事务‘’

为容器和 Kubernetes 构建应用程序的7个最佳实践_服务革新_Kevin Casey_InfoQ精选文章