7个常见的Kubernetes陷阱

Kubernetes是业界最流行的容器编排开源平台。它帮助您自动化许多与容器管理相关的任务。公司使用它来解决与部署、可伸缩性、测试、管理等相关的问题。然而，Kubernetes非常复杂，需要一个陡峭的学习曲线。在本文中，我们将介绍大多数公司都会遇到的一些常见的Kubernetes陷阱。这些都是许多采用Kubernetes来扩大业务规模的公司所面临的问题。在讨论问题的同时，我们也将强调如何避免或修复它们。最终，我们将讨论最大限度地利用Kubernetes而不面对其复杂性的最佳解决方案。
让我们从与标签和选择器的不正确使用有关的第一个错误开始。

1.不正确的标签和选择器

初学者经常犯的错误之一是配置中标签和选择器的不正确使用。标签是与像豆荚、服务等对象相关联的键/值对。选择器允许您识别用标签标记的对象。不匹配的选择器将部署资源置于不受支持的状态，您可能会看到与不正确的标签和选择器相关的错误。下面的例子说明了这个概念。注意标签是区分大小写的。确保在YAML文件中使用正确的标签和选择符，并仔细检查错别字。

2.忽视健康检查

在将服务部署到Kubernetes时，健康检查在维护服务方面起着至关重要的作用。健康检查在Kubernetes环境中使用得很少。通过健康检查，您可以密切关注豆荚及其容器的健康状况。Kubernetes有三个主要工具可以用于健康检查。启动探测确认是否启动和创建了pods而没有出现问题。Livility探针告诉您应用程序是否处于活动状态。就绪探测确保您的应用程序是否能够成功接收通信量。

3.对所有对象使用默认命名空间

命名空间允许您对不同的资源（如部署和服务）进行分组。当多个团队在同一产品或基于微服务的应用程序上工作时，名称空间是必不可少的。在开发环境中，使用默认命名空间可能不是问题，但如果执行命令时不提及命名空间，则可能会导致生产问题。请记住，如果您没有提到任何名称空间，您将不会看到错误，但服务或部署将应用于默认名称空间，而不是您所需的名称空间。请参见下面的示例。

Instead of:

kubectl apply -f deployment.yaml

Run:

kubectl apply -f deployment.yaml --namespace production-api

4.使用“最新”标签

许多用户认为“最新”标签总是指向图像的最新推送版本，但事实并非如此。“最新”标签并不总是部署您认为是最近的版本。使用“最新”命令进行部署，将无法回滚到早期版本。
使用显式版本标记将确保始终部署正确的版本。这还允许您的团队使用以前已知版本的标记来控制回滚。

5.缺乏监测和记录

设置Kubernetes的陷阱之一是忽略了正确的监视和日志记录。您应该设置一个日志聚合服务器和监视系统来监视您的应用程序。这不仅将帮助您了解系统中的各种瓶颈，还将帮助您了解如何度量和优化Kubernetes集群的性能。一个健全的监视系统包括各种资源度量的警报和通知。如前所述，Kubernetes非常复杂，因此需要适当的监视和日志记录来排除故障并解决不同的问题。
采用完善的监控系统对于Kubernetes系统的顺利运行和积极管理至关重要。由于本机监视工具缺乏许多有用的功能，如日志聚合、跟踪审核事件和警报通知，因此最好使用第三方工具进行日志记录和监视。

6.错误的容器端口映射到服务

如果您面临“连接被拒绝”的错误或容器没有回复，那么这可能是映射到服务的容器端口不正确的问题。这是因为服务中的两个参数彼此相似。一个是“targetport”，而另一个是“port”。很容易混合它们的用法并面对问题。
请注意，服务的“targetPort”是pods中的目的端口，即服务转发流量的端口。下图说明了这一点。而“port”参数是指服务向客户端公开的端口。

7.Crashloopbackoff错误

Kubernetes中的另一个常见错误是crashloopbackoff错误。当一个吊舱正在运行，但它的一个容器由于终止而不断重新启动时，就会发生这种情况。所以容器不断陷入开始-崩溃-开始-崩溃的循环。
这个错误可能有很多原因。可能是配置文件中的简单错误、内存不足、配置不正确等等。您需要检查pod描述和pod日志来排除故障并修复根本原因。