随着DevOps开发模式的盛行，Kubernetes正在迅速占领技术世界。作为一个开源的容器编排系统，它可以自动化容器应用程序的部署、扩展和管理。由于Kubernetes是一种经济、强大、可靠的分布式容器集群管理工具，它本身具有一定的复杂性。一旦开发人员不注意或配置不当，可能会导致生产环境出现各种故障。为了避免潜在的陷阱和错误，本文将讨论Kubernetes部署中的一些常见错误、它们的基本原理以及如何修复这些错误的简单提示。Kubernetes基础图片来源：Kubernetes.ioKubernetes使用一组API和命令行工具来管理集群中的容器。它的架构由一个主节点和多个子节点或工作节点组成。其中，主节点不仅负责集群的状态和子节点的活动，还管理子节点上的工作负载，调度容器，为容器分配合适的资源。子节点虽然不限于物理机或虚拟机，但都需要接入Docker引擎和kubelet服务才能与Kubernetes集群协同工作。此外，一个节点需要与其他节点相连，以实现彼此之间的数据传输。Kubernetes使用声明式配置模式轻松设计可扩展的系统来处理预期和意外的变化。这种声明式配置使得Kubernetes可以轻松处理各种容器和集群操作的底层复杂性，然后轻松构建具有高可用性、可扩展性和安全性的集群。当然，由于其固有的部署复杂性，你的Kubernetes应用可能经常会出现以下错误：1.忽略健康检查图片来源：Kaizenberglabs如上图所示，在向Kubernetes部署服务时，了解pod的状态和整体Kubernetes集群的健康对于确保服务按预期运行非常重要。为此，我们可以使用启动探测器、活性探测器和就绪探测器。其中，startupprobe可以保证Pod的成功启动和创建；活动探针方便我们测试应用是否活跃；就绪探测用于确定应用程序是否已准备好接收流量。2、在容器中挂载宿主机文件系统在容器中挂载宿主机文件系统是一种常见的反模式，常用于持久化数据场景。其中，最简单的方法是将宿主机的本地目录挂载为容器文件系统中的一个目录。据此，写入此目录的任何内容都将保留在主机上。然而，这具有无法在多个容器之间共享状态的潜在后果（即无法在两个不同的主机上挂载两个不同的目录）。对主机文件系统所做的任何更改对其他容器都是不可见的。在不更改所有权的情况下，无法管理任何挂载目录上的文件。因此，为避免上述问题，请勿将任何文件系统从宿主机挂载到容器中，除非用于数据持久化目的。3、使用“Latest（最新）”标签如果在生产环境中使用Latest标签，一旦对版本的描述不够清晰，可能会造成混淆，所以不建议在生产环境中使用此类标签.比如当服务中断，需要尽快恢复，但是你发现“Latest”标签并没有指向新推送的镜像版本，那么你就无法知道具体是哪个版本刚才运行的应用程序。因此，您应该始终使用那些有意义的Docker标签。4.将服务部署到错误的Kubernetes节点根据前面的介绍，worker节点只能运行其master节点分配的任务。那么，一旦你把服务部署到错误的节点上，就可能导致它无法正常工作。此外，当一个新的容器启动时，它需要等待一个可用的调度器来分配任务，这通常需要比预期更长的时间。为了避免这种情况，您需要在部署服务之前了解您的服务需要运行在主节点还是工作节点上。在启动任何容器之前，您还应该检查pod是否可以访问集群中需要与之通信的其他pod。5.不使用现成的部署模式Kubernetes凭借其众多的部署技术，可以让开发者轻松部署自己的应用程序。如下图所示，Kubernetes推荐大家使用Blue-Green、Canary、Rolling等部署策略，保证用户不会因为新的软件部署而遇到问题。任何停机或服务中断。滚动部署策略是Kubernetes默认的策略，会慢慢的用新版本的pod替换旧的pod版本。蓝绿模式下，蓝绿版本同时部署，但单位时间内只有一个版本处于活动状态。如果我们将蓝色视为旧版本，将绿色视为新版本，那么默认情况下所有流量都可以先发送到蓝色版本。一旦最新的绿色版本满足所有要求，我们就可以将流量从旧版本转移到新版本（即：蓝色到绿色）。金丝雀部署策略可用于A/B测试和“暗”启动。与蓝绿方式非常相似，唯一的区别是A和B版本同时提供服务和接受请求。我们可以通过后台管控，慢慢将用户流量从A版本转移到B版本。6.重复部署当我们创建同一个状态的多个副本并并行部署到不同的集群时，可能会出现重复部署的情况。例如：当一个集群出现故障时，另一个集群会继续处理部署请求。然而，当它恢复时，或者当一个新的集群加入时，两个正在运行的副本的请求加倍，超额订阅了底层主机上的CPU和内存资源。为此，我建议您使用HeadlessService或DaemonSet等服务类型，这样在任何给定时间，您都只能运行一个版本的部署。7.在生产中只使用一种类型的容器（即无状态）许多人错误地认为所有的容器都是一样的。事实上，它们之间存在显着差异。其中，有状态容器允许您将数据存储在磁盘等持久性存储介质上，以避免数据丢失。另一方面，无状态容器仅在操作期间保留其数据并在完成时丢弃（除非另外备份）。因此，您应该同时使用有状态和无状态容器。8.在不考虑监控和日志要求的情况下部署应用程序通常会导致开发人员忽视他们的代码或应用程序在生产环境中的运行方式。为了避免此类缺陷，我们应该在应用部署前建立监控系统和日志聚合服务器，了解应用的性能，发现需要改变和优化的地方。然而，当你只使用Kubernetes本身提供的服务和工具，而不是第三方解决方案时，你可能会遇到供应商锁定。例如，当您使用CRI容器的运行时接口部署容器时，您不能使用Docker或RKT容器。此外，由于集群容量不足或在错误的时间部署应用程序，许多开发人员会遇到效率低下和混乱的情况。9.在没有任何安全配置的情况下部署应用程序开发人员通常会忽略密钥保护以及在使用集群外部可访问的端点时如何安全地运行特权容器等问题。因此，我们应该关注Kubernetes的以下安全方面：授权——身份验证和授权对于控制对Kubernetes集群中资源的访问至关重要。网络-Kubernetes网络涉及管理覆盖网络和服务端点，以确保容器之间的流量在集群内安全路由。存储-由于KubernetesAPI服务器上有一个REST接口可以访问所有存储的信息，用户只需向API发送HTTP请求即可访问API中存储的任何信息。为了防止未经授权的用户或进程访问敏感数据，我们可以配置API服务器支持用户名/密码，或基于令牌的身份验证方法（请参考下图）。此外，您可以通过配置基于角色的访问控制(RBAC)策略来保护Kubernetes集群。即通过为用户分配“管理员”或“操作员”等角色，并限制角色访问资源，来保护Kubernetes集群。其中，administrator角色拥有完全的访问权限，而operator角色仅拥有集群内有限资源的访问权限。10.没有设置资源使用限制如果你发现你的资源使用率和账单都在暴涨，那么是时候重新审视服务的资源使用情况了。我们可以通过对应用程序进行压力测试来设置容器的CPU和内存限制。为此，Kubernetes在其资源利用类别中定义了“请求”和“限制”。其中，“request”代表应用运行所需的最小资源，“limit”定义了最大资源。我们可以在部署YAML中指定资源限制。从上图可以看出，HarnessCloudCostManagement(CCM)计算和分析了不同的工作流负载、CPU和内存使用情况，并以直方图的形式为您的Kubernetes集群展示各种资源的优化可能性。提供减少每月支出的建议。小结以上为大家介绍了Kubernetes部署过程中常见的十个错误以及相应的解决方法。希望他们能帮助您有效地交付更完善的应用和服务。译者介绍51CTO社区编辑JulianChen。他在实施IT项目方面拥有超过十年的经验。善于控制内外部资源和风险。专注传播网络与信息安全知识与经验；翻译等形式分享前沿技术和新知识；经常在线上和线下开展信息安全培训和讲座。原标题：Don’tMakeThese10KubernetesMistakes，作者：PavanBelagatti
