随着DevOps开发模式的盛行，Kubernetes正在迅速占领着技术界。作为一个开源的容器编排系统，它可以自动化容器应用的部署、扩展和管理。由于Kubernetes是一种经济、强大、可靠的分布式容器集群的管理工具，因此它本身具有一定的复杂性。一旦开发者未加注意、或配置不当，就可能导致生产环境出现各种故障。

为了避免潜在陷阱与错误，本文将和您探讨在Kubernetes部署中的一些常见错误，它们的基本原理，以及如何修复的简单技巧。

Kubernetes的基础知识

编辑搜图

图片来源：Kubernetes.io

Kubernetes使用一组API和命令行工具，来管理集群中的容器。其架构由一个主节点和多个分节点、或工作节点所组成。其中，主节点既负责集群的状态和分节点的活动，又管理分节点上的工作负载，调度容器，并为容器分配适当的资源。分节点虽然不限于是物理机还是虚拟机，但是它们都需要通过访问Docker引擎和kubelet服务，才能与Kubernetes集群协同工作。此外，一个节点需要通过与其他节点连接，才能实现彼此间的数据传输。

Kubernetes使用一种声明性配置模式，来便捷地设计可扩展性系统，以应对那些可预期和无法预期的变化。这种声明式配置方便了Kubernetes去处理各种容器和集群操作的底层复杂性，进而能够轻松地构建出具有高可用性、可扩展性和安全性的集群。

当然，由于其固有的部署复杂性，您的Kubernetes应用可能会经常存在如下错误：

1.忽略健康检查

编辑搜图

图片来源：Kaizenberglabs

如上图所示，在将服务部署到Kubernetes时，了解pod的状态和Kubernetes集群的整体健康状况，对于保障服务能够按照预期运行是非常重要的。为此，我们可以用到启动探针、活跃度探针、以及就绪度探针。其中，启动探针可以确保Pod的成功启动和创建;活跃度探针方便了我们去测试应用程序是否处于活跃状态;而就绪度探针则被用于确定应用程序是否已为接收流量准备就绪。

2. 在容器中挂载主机文件系统

在容器中挂载主机文件系统是一种常见的反模式，时常被用于持久化数据的场景中。其中，最简单的方法是将主机的本地目录，挂载成为容器文件系统中的一个目录。据此，写入该目录的任何内容都会被保留在主机上。不过，此举可能会导致如下潜在的后果：

• 无法在多个容器之间共享状态(即，无法将两个不同的目录挂载到两个不同的主机上)。

• 在主机文件系统上的任何更改，对于其他容器都是不可见的。

• 无法在不更改所有权的情况下，管理任何已挂载目录上的文件。

因此，为避免出现上述问题，请勿将主机的任何文件系统挂载到容器中，除非是出于数据持久性目的。

3. 使用“Latest(最新)”标签

如果在生产环境中使用Latest标签，那么一旦针对版本的描述不够清楚的话，就可能会引起混乱，因此我们不建议在生产环境中使用此类标签。例如，当服务出现中断需要尽快恢复时，您却发现“Latest”标签并非指向新推送的镜像版本，那么就会导致您无法知晓刚才在运行的应用的具体版本。因此，您应该持续使用那些有意义的Docker标签。

4. 将服务部署到错误的Kubernetes节点

根据前面的介绍，工作节点仅能运行由其主节点分配的任务。那么，一旦您将服务部署到错误的节点上，就可能导致其无法正常工作。此外，新的容器在启动时，需要等待一个可用的调度程序来分配任务，这往往需要占用比预期更长的时间。

为避免这种情况，您需要在部署服务之前，知晓自己的服务需要在主节点、还是工作节点上运行。而在启动任何容器之前，您还应该检查pod是否可以访问集群中需要与之通信的其他pod。

5. 未能使用现成的部署模式

Kubernetes凭借其众多的部署技术，让开发人员可以轻松地部署自己的应用程序。如下图所示，Kubernetes建议您使用：蓝绿(Blue-Green)、金丝雀(Canary)和滚动(Rolling)等部署策略，来保证用户不会因为新的软件部署，而碰到任何停机或服务中断。

编辑搜图

• 滚动部署策略是Kubernetes的默认策略，它会用新版本的pod，去慢慢替换之前旧的pod版本。

• 在蓝绿模式中，蓝色和绿色版本会被同时部署，但是在单位时间内，只有一个版本处于活动状态。如果我们将蓝色视为旧版本、将绿色视为新版本的话，那么可以首先将默认所有流量都发送到蓝色版本上。一旦最新的绿色版本满足了所有要求，我们则可以将旧版本上的流量转移到新版本上(即：从蓝到绿)。

• 金丝雀部署策略可被用于进行A/B测试和“暗”启动。它与蓝绿方法非常类似，唯一不同的是，A、B两个版本是同时提供服务并受理请求的。我们可以在后台通过管控，让用户流量缓慢地从版本A转移至版本B。

6. 重复部署

当我们创建多个相同状态的副本，并行地部署到不同的集群上时，可能会发生重复部署的情况。例如：当某个集群出现故障时，另一个集群会继续处理部署的请求。但是，当它恢复、或有新的集群加入时，两个正在运行的副本会加倍处理请求，进而超额占用底层主机上的CPU和内存资源。对此，我建议您使用Headless Service或Daemon Set等服务类型，以便在任何给定时间，限制只有一个部署版本在运行。

7. 在生产环境中只使用一种容器(即无状态)

许多人会错误地认为所有的容器都是相同的。其实，它们之间存在显著的差异。其中，有状态的容器会允许您，将数据存储在磁盘等持久性存储介质上，以避免数据的丢失。而无状态容器则只在运行期间保留其数据，而在完成后丢弃数据(除非额外予以备份)。因此，您应该同时使用有状态和无状态两种容器。

8. 在不考虑监控和日志记录要求的情况下部署应用

不考虑监控和记录的需要，往往会导致开发人员疏忽他们的代码或应用在生产环境中运行的情况。为了避免此类缺陷，我们应当在应用部署之前，建立一个监控系统和日志聚合服务器，以获悉应用的性能，并发现需要更改和优化的地方。

不过，当您仅使用由Kubernetes自身提供的服务和工具、而非第三方解决方案时，可能会碰到厂商锁定的问题。例如，您在使用CRI容器的运行时接口，来部署容器时，就不能使用Docker或RKT容器。此外，许多开发人员也会碰到由于集群容量不足、或在错误的时间部署应用，而产生的低效与混乱。

9. 在没有任何安全配置的情况下部署应用

开发人员在使用集群外部可访问的端点时，往往会忽略诸如：密钥保护、以及如何安全地运行特权容器等问题。因此，我们应当对Kubernetes的如下安全性引起重视：

• 授权——身份验证和授权对于控制访问Kubernetes集群中资源是至关重要的。

• 网络——Kubernetes网络会涉及到管理覆盖网络(overlay networks)和服务端点，以确保容器之间的流量在集群内被安全地路由。

• 存储——由于Kubernetes API服务器上有个REST接口，可以访问所有存储的信息，因此用户只需向API发送HTTP请求，即可访问到存储在API中的任何信息。为了避免未经授权的用户或进程访问到敏感数据，我们可以为API服务器配置支持用户名/密码、或基于令牌的身份验证的方法(请参考下图)。

编辑搜图

此外，您还可以通过配置基于角色的访问控制(RBAC)策略，来保护Kubernetes集群。即，通过给用户分配诸如：“管理员”或“操作员”角色，并限制角色去访问资源，来保护Kubernetes集群。其中，管理员角色具有完全的访问权限，而操作员角色仅有对集群内有限资源的访问权限。

10.未设置资源的使用限制

如果您发现自己的资源利用率和账单双双猛增的话，那么就该重新检查服务的资源使用情况了。我们可以通过对应用程序执行压力测试，来设置容器的CPU和内存的限制。对此，Kubernetes在其资源利用的类别中定义了“请求”和“限制”。其中，“请求”代表应用需要运行的最小资源，而“限制”则定义了最大的资源。我们可以在部署YAML中指定资源的限制。

编辑搜图

由上图可见，Harness Cloud Cost Management(CCM)通过计算和分析不同的工作流负载，对CPU和内存的占用率，以直方图的形式显示了各种资源地优化可能性，为您的Kubernetes集群提供各项建议，进而减少您的每月支出。

小结

在上文中，我向您介绍了在Kubernetes部署过程中十种常见的错误、以及对应的解决方法。希望它们能够协助您有效地交付出更加完善的应用与服务。