kubernetes从入门到实践，初学者常见的7种Kubernetes错误

kubernetes从入门到实践，初学者常见的7种Kubernetes错误建立 Kubernetes 的一个陷阱是忽视适当的监测和日志。您应该设置一个日志聚合服务器和监视系统来监视您的应用程序。这不仅可以帮助您看到系统中的各种瓶颈，还可以帮助您测量和优化 Kubernetes 集群的性能。健全的监控系统包括各种资源指标的警报和通知。正如前面提到的，Kubernetes 是复杂的，因此您需要适当的监视和日志记录来排除故障并解决不同的问题。使用显式版本标记将确保始终部署正确的版本，同时允许您的团队使用以前已知版本的标记来控制回滚。#这是个错误示范，来自StackOverflow，问题在于其中第13行app的值与第18行的值不匹配 apiVersion: apps/v1 kind: ReplicaSet metadata: name: label-demo labels: environment: production app: nginx s

转译一篇有关Kubernetes的非常入门级的文章，积硅步，至千里，希望可以帮助到需要的同学。

Kubernetes 是业界最流行的用于容器编排的开源平台，可以让我们与容器相关的很多工作变得自动化。公司使用它来解决与部署、可伸缩性、测试、管理等相关的问题。然而，Kubernetes是复杂的，需要一个陡峭的学习曲线。在本文中，我们将介绍大多数公司都会遇到的一些常见的Kubernetes陷阱。这些是许多拥抱Kubernetes的公司在扩大业务规模时所面临的问题。在讨论这些问题的同时，我们还将强调如何避免或解决这些问题。最终，我们将讨论如何在不面对 Kubernetes 复杂性的情况下最大限度地发挥其作用的最佳解决方案。

下面，让我进入正题。

不正确使用Label和Selector

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

#这是个错误示范，来自StackOverflow，问题在于其中第13行app的值与第18行的值不匹配 apiVersion: apps/v1 kind: ReplicaSet metadata: name: label-demo labels: environment: production app: nginx spec: replicas: 3 selector: matchLabels: app: App1 template: metadata: labels: environment: production app: nginx spec: containers: - name: nginx image: nginx:1.7.9忽视健康检查

在 Kubernetes 部署服务时，健康检查在维持服务方面发挥着至关重要的作用。在Kubernetes中，健康检查的使用率很低。通过健康检查，你要密切关注Pod及其容器的健康状况。Kubernetes 有三种主要的健康检查工具。Startup 探测确认是否在没有问题的情况下启动和创建了Pod。Liveliness 探测将告诉您应用程序是否处于活动状态。Readness 探测确保应用程序能否成功接收请求。

一直使用默认名称空间

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

#错误，没有指定命名空间 kubectl apply -f deployment.yamlKubectl application-f loyment.yaml #正确，使用--namespace指定了命名空间 kubectl apply -f deployment.yaml --namespace production-apiKubectl application-f loyment.yaml ——namespace production-api使用“latest”标签

许多用户认为“ latest”标签（Tag）总是指向镜像的最新推送版本，但事实并非如此。“latest”标记并不总是部署您认为是最新的版本。在部署（Deployment）上使用的“latest”，您将无法回滚到之前的版本。

使用显式版本标记将确保始终部署正确的版本，同时允许您的团队使用以前已知版本的标记来控制回滚。

缺乏监测和日志

建立 Kubernetes 的一个陷阱是忽视适当的监测和日志。您应该设置一个日志聚合服务器和监视系统来监视您的应用程序。这不仅可以帮助您看到系统中的各种瓶颈，还可以帮助您测量和优化 Kubernetes 集群的性能。健全的监控系统包括各种资源指标的警报和通知。正如前面提到的，Kubernetes 是复杂的，因此您需要适当的监视和日志记录来排除故障并解决不同的问题。

采用一个健全的监测系统对于顺利运作和积极管理您的Kubernetes系统是必不可少的。由于原生监视工具缺乏许多有用的特性，如日志聚合、跟踪审计事件和警报通知，因此最好使用第三方工具进行日志记录和监视。

Pod与Service端口映射错误

如果您看到“连接被拒绝”或“容器没有回复”的错误，那么这可能是映射到服务（Service）的容器端口不正确的问题。这是因为服务中的两个参数彼此相似。一个是“ Targetport”，另一个是“port”，很容易弄混它们而导致这个问题。

请注意，您的服务（Service）的“targetPort”是 Pods 中的端口，服务转发流量的目标端口。下面的图片说明了这一点。而“port”参数指的是服务自己向访问端公开的端口。

Crashloopbackoff 错误

Kubernetes 另一个经常出现的错误是Crashloopbackoff。这种情况发生在Pod运行时，但其中一个容器由于终止运行而不断重新启动。因此，容器不断陷入启动-崩溃-启动-崩溃的循环。

出现此错误的原因有很多。可能是配置文件中的简单输入错误、内存不足、配置不正确等等。您需要检查Pod描述和日志，以排除故障并修复根本原因。