译文 精选
作者: 陈峻 2022-03-08 09:00:00
云计算
云原生 本文将向您介绍在Kubernetes部署过程中十种常见的错误、它们的基本原理、以及如何修复的简单技巧。希望它们能够协助您有效地交付出更加完善的应用与服务。
随着DevOps开发模式的盛行,Kubernetes正在迅速占领着技术界。作为一个开源的容器编排系统,它可以自动化容器应用的部署、扩展和管理。由于Kubernetes是一种经济、强大、可靠的分布式容器集群的管理工具,因此它本身具有一定的复杂性。一旦开发者未加注意、或配置不当,就可能导致生产环境出现各种故障。
为了避免潜在陷阱与错误,本文将和您探讨在Kubernetes部署中的一些常见错误,它们的基本原理,以及如何修复的简单技巧。
图片来源: Kubernetes.io
Kubernetes使用一组API和命令行工具,来管理集群中的容器。其架构由一个主节点和多个分节点、或工作节点所组成。其中,主节点既负责集群的状态和分节点的活动,又管理分节点上的工作负载,调度容器,并为容器分配适当的资源。分节点虽然不限于是物理机还是虚拟机,但是它们都需要通过访问Docker引擎和kubelet服务,才能与Kubernetes集群协同工作。此外,一个节点需要通过与其他节点连接,才能实现彼此间的数据传输。
Kubernetes使用一种声明性配置模式,来便捷地设计可扩展性系统,以应对那些可预期和无法预期的变化。这种声明式配置方便了Kubernetes去处理各种容器和集群操作的底层复杂性,进而能够轻松地构建出具有高可用性、可扩展性和安全性的集群。
当然,由于其固有的部署复杂性,您的Kubernetes应用可能会经常存在如下错误:
图片来源: Kaizenberglabs
如上图所示,在将服务部署到Kubernetes时,了解pod的状态和Kubernetes集群的整体健康状况,对于保障服务能够按照预期运行是非常重要的。为此,我们可以用到启动探针、活跃度探针、以及就绪度探针。其中,启动探针可以确保Pod的成功启动和创建;活跃度探针方便了我们去测试应用程序是否处于活跃状态;而就绪度探针则被用于确定应用程序是否已为接收流量准备就绪。
在容器中挂载主机文件系统是一种常见的反模式,时常被用于持久化数据的场景中。其中,最简单的方法是将主机的本地目录,挂载成为容器文件系统中的一个目录。据此,写入该目录的任何内容都会被保留在主机上。不过,此举可能会导致如下潜在的后果:
因此,为避免出现上述问题,请勿将主机的任何文件系统挂载到容器中,除非是出于数据持久性目的。
如果在生产环境中使用Latest标签,那么一旦针对版本的描述不够清楚的话,就可能会引起混乱,因此我们不建议在生产环境中使用此类标签。例如,当服务出现中断需要尽快恢复时,您却发现“Latest”标签并非指向新推送的镜像版本,那么就会导致您无法知晓刚才在运行的应用的具体版本。因此,您应该持续使用那些有意义的Docker标签。
根据前面的介绍,工作节点仅能运行由其主节点分配的任务。那么,一旦您将服务部署到错误的节点上,就可能导致其无法正常工作。此外,新的容器在启动时,需要等待一个可用的调度程序来分配任务,这往往需要占用比预期更长的时间。
为避免这种情况,您需要在部署服务之前,知晓自己的服务需要在主节点、还是工作节点上运行。而在启动任何容器之前,您还应该检查pod是否可以访问集群中需要与之通信的其他pod。
Kubernetes凭借其众多的部署技术,让开发人员可以轻松地部署自己的应用程序。如下图所示,Kubernetes建议您使用:蓝绿(Blue-Green)、金丝雀(Canary)和滚动(Rolling)等部署策略,来保证用户不会因为新的软件部署,而碰到任何停机或服务中断。
当我们创建多个相同状态的副本,并行地部署到不同的集群上时,可能会发生重复部署的情况。例如:当某个集群出现故障时,另一个集群会继续处理部署的请求。但是,当它恢复、或有新的集群加入时,两个正在运行的副本会加倍处理请求,进而超额占用底层主机上的CPU和内存资源。对此,我建议您使用Headless Service或Daemon Set等服务类型,以便在任何给定时间,限制只有一个部署版本在运行。
许多人会错误地认为所有的容器都是相同的。其实,它们之间存在显著的差异。其中,有状态的容器会允许您,将数据存储在磁盘等持久性存储介质上,以避免数据的丢失。而无状态容器则只在运行期间保留其数据,而在完成后丢弃数据(除非额外予以备份)。因此,您应该同时使用有状态和无状态两种容器。
不考虑监控和记录的需要,往往会导致开发人员疏忽他们的代码或应用在生产环境中运行的情况。为了避免此类缺陷,我们应当在应用部署之前,建立一个监控系统和日志聚合服务器,以获悉应用的性能,并发现需要更改和优化的地方。
不过,当您仅使用由Kubernetes自身提供的服务和工具、而非第三方解决方案时,可能会碰到厂商锁定的问题。例如,您在使用CRI容器的运行时接口,来部署容器时,就不能使用Docker或RKT容器。此外,许多开发人员也会碰到由于集群容量不足、或在错误的时间部署应用,而产生的低效与混乱。
开发人员在使用集群外部可访问的端点时,往往会忽略诸如:密钥保护、以及如何安全地运行特权容器等问题。因此,我们应当对Kubernetes的如下安全性引起重视:
此外,您还可以通过配置基于角色的访问控制(RBAC)策略,来保护Kubernetes集群。即,通过给用户分配诸如:“管理员”或“操作员”角色,并限制角色去访问资源,来保护Kubernetes集群。其中,管理员角色具有完全的访问权限,而操作员角色仅有对集群内有限资源的访问权限。
如果您发现自己的资源利用率和账单双双猛增的话,那么就该重新检查服务的资源使用情况了。我们可以通过对应用程序执行压力测试,来设置容器的CPU和内存的限制。对此,Kubernetes在其资源利用的类别中定义了“请求”和“限制”。其中,“请求”代表应用需要运行的最小资源,而“限制”则定义了最大的资源。我们可以在部署YAML中指定资源的限制。
由上图可见,Harness Cloud Cost Management(CCM)通过计算和分析不同的工作流负载,对CPU和内存的占用率,以直方图的形式显示了各种资源地优化可能性,为您的Kubernetes集群提供各项建议,进而减少您的每月支出。
在上文中,我向您介绍了在Kubernetes部署过程中十种常见的错误、以及对应的解决方法。希望它们能够协助您有效地交付出更加完善的应用与服务。
陈峻 (Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式,分享前沿技术与新知;经常以线上、线下等方式,开展信息安全类培训与授课。
原文标题:Don't Make These 10 Kubernetes Mistakes,作者:Pavan Belagatti
分享题目:千万别犯这十种Kubernetes错误
文章URL:http://www.csdahua.cn/qtweb/news4/393004.html
网站建设、网络推广公司-快上网,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 快上网