从Docker迁移到Docker Swarm，再到Kubernetes，然后处理了多年来的所有各种API更改之后，我非常乐意发现部署中出现的问题和把问题进行修复。
我今天分享下我认为最有用的5条故障排除技巧，以及一些其他的使用技巧。

kubectl –“瑞士军刀”

kubectl就是我们的瑞士军刀，我们经常在出现问题的时候使用他们，在出现问题如何使用他们很重要，
让我们从5个“实际案例”开始，看出现问题时如何使用它们。
情况将是：我的YAML已被接受，但我的服务未启动且已启动，但无法正常工作。
1.kubectl get deployment/pods
这个命令如此重要的原因是它无需显示大量内容即可显示很有用的信息。
如果要为工作负载使用部署，则有两种选择：
kubectl get deploy
kubectl get deploy -n  名称空间
kubectl get deploy –all-namespaces [或“ -A”]
理想情况下，您希望看到的是1/1或等值的2/2，以此类推。这表明您的部署已被接受，并已尝试进行部署。
接下来，您可能需要查看kubectl get pod，以查看部署的后备Pod是否正确启动。

2. kubectl get events

我感到惊讶的是，我不得不经常向与Kubernetes有问题的人们解释这个小技巧。 此命令将打印出给定名称空间中的事件，非常适合查找关键问题，例如崩溃的pod或无法pull容器镜像。
Kubernetes中的日志是“未排序的”，因此，您将需要添加以下内容，这些内容取自OpenFaaS文档。

kubectl get事件的另一个接近的命令是是kubectl  describe，就像get deploy / pod一样，它与对象的名称一起工作：

您会在这里获得非常详细的信息。 您可以描述大多数事情，包括节点，这些节点将显示由于资源限制或其他问题而无法启动Pod。

3. kubectl logs

这个命令肯定经常大家经常使用，但很多人使用了错误的方式。
如果您进行了部署，比方说cert-manager命名空间中的cert-manager，那么很多人认为他们首先必须找到Pod的长（唯一）名称并将其用作参数。 不对。

要跟踪日志，请添加-f

为了避免获取所有可能的日志条目，您还可以使用–tail将其限制为最后几行：

您可以将所有三个结合起来。
如果您的Deployment或Pod有任何标签，则可以使用-l app = name或任何其他标签集来附加到一个或多个匹配Pod的日志中。

有一些工具，例如stern 和kail，可以帮助您匹配模式并节省一些键入操作，但我发现它们会分散您的注意力。

4.kubectl get -o yaml

当您开始使用由另一个项目或诸如Helm之类的其他工具生成的YAML时，您将很快需要它。 在生产中检查镜像的版本或您在某处设置的注释也很有用。

输出yaml

现在我们知道了。 而且，我们可以添加–export并将YAML保存在本地以进行编辑并再次应用。
实时编辑YAML的另一个选项是kubectl edit，如果您对vim感到困惑，不知道如何使用，请在命令前加上VISUAL = nano，使用这个简化编辑器。

5. kubectl scale  您打开和关闭它了吗？

Kubectl scale可用于将Deployment及其Pod缩小为零个副本，实际上杀死了所有副本。 当您将其缩放回1/1时，将创建一个新的Pod，重新启动您的应用程序。
语法非常简单，您可以重新启动代码并再次进行测试。

6. Port forwarding

我们需要这个技巧， 通过kubectl进行的端口转发使我们可以在我们自己计算机上的本地或远程群集上公开一项服务，以便在任何已配置的端口上访问它，而无需在Internet上公开它。
以下是在本地访问Nginx部署的示例：

有人认为这仅适用于部署或Pod，这是错误的。 服务间是公平的，通常是转发的选择，因为它们将模拟生产集群中的配置。
如果您确实想在Internet上公开服务，通常会使用LoadBalancer服务，或运行kubectl暴露：

技巧说完了，可以现在尝试一下，我希望您发现这6条命令和技巧有用， 现在，您可以在真实的集群上对其进行测试了。