原文出自：Rookout blog

原文作者：Gedalyah Reback（Senior Product Marketing Manager at Rookout）

Kubernetes 既具有革命性，又具有传播性。这是一次彻底的改革，需要一系列全新的配套、支持工具，来覆盖和支撑整个生态系统。实际上，目前已有数百种专为 k8s 而设计的工具，其中既有开源的，也有授权的。

选择 Kubernetes 技术堆栈似乎是一项很艰巨的任务，因为这一套生态系统是十分庞大的。如果要将所有工具及其调试方法完整地列出来，这就超出了本文的范围。Developer-first observability 要求简化这些杂乱无章的工具。全面了解和调试 Kubernetes 部署需要一个总体的工具和策略，该工具和策略比使用堆栈中的每个工具更直接，并且高效。话虽如此，大多数单独的工具都提供内部可观察性。知道如何获得这些可以为开发人员提供有利条件。

本文，并不会对每一种工具都进行详尽的介绍，但本文所列的这份清单，将涵盖最基本的关键点以及每一项中的主要工具。

调试 K8S 服务网格和入口控制器

我们已经有了编排和部署工具，那么为什么我们需要一些听起来多余的东西呢？这就是协调 Kubernetes 与之间的关键所在。和入口控制器作为可配置的抽象层来控制进出 Kubernetes 的流量。

服务网格对 Kubernetes 内的服务进行协调（即东西向流量）。

入口控制器协调流入（入口）（以及可能流出（出口））的 Kubernetes 流量（即南北流量）。在 Kubernetes 中，我们会使用 Kubernetes API 来实现配置和部署以下内容：

1. 接受入口（传入）流量并通过负载均衡将其路由到 Pod 上；

2. 监控 Pod 并自动更新负载均衡规则；

3. 管理与集群外服务通信的出口（传出）流量；

你的 Kubernetes 堆栈是否真的需要这两种工具，这是值得商榷的，因此，实际上这两个类别中的所有工具都在相互竞争。此外，您还可以在这里混合使用 API 网关，这就像入口控制器能实现控制入口流量和出口流量一样。

三大服务网格分别是 Istio、Linkerd 和 Consul。他们使用级数据流量的“控制平面”和“数据平面”直接处理网格内服务之间的数据处理功能。

1. 调试 Istio

以下两个命令都能很好地观测道 Istio 网格中的流量：

istioctl proxy-status

istioctl proxy-config

您还可以浏览调试日志。请注意，这 debug 是 Istio 日志的五种可能输出之一（其他是 none、 error、 warn和 info）。请注意，调试将提供最多的数据，一些开发人员认为 Istio 在日志方面信息量很大。

以下示例定义了要分析的不同范围：

istioctl analyze --log_output_level klog:debug,installer:debug,validation:debug,validationController:debug

2. 调试 Linkerd

调试的默认方法是使用调试容器（调试边车）。但是，Linkerd 调试的工作方式因您使用的应用程序类型而异。

例如，您将使用指标来调试 HTTP 应用程序和gRPC 应用程序的 请求 跟踪。

1.调试 502，即错误的网关响应

2.调试 控制平面端点

3.使用指标调试 HTTP 应用程序

4.使用请求跟踪调试 gRPC 应用程序

对于 Linkerd 调试容器/sidercar：

kubectl -n <appname> get deploy/<appservicename> -o yaml \
  | linkerd inject --enable-debug-sidecar - \
  | kubectl apply -f -

3. 调试Consul

Consul 调试命令 在 Consul 中非常简单。使用 -capture 定义您要分析的内容，并为间隔、持续时间、API、 Go pprof 包等添加参数。

consul debug -capture agent -capture host -capture logs -capture metrics -capture members -capture pprof -interval=30s -duration=2m -httpaddr=126.0.0.1:8500

4. NGINX 入口控制器

NGINX 很有趣，因为它很容易将两个独立的工具混为一谈： NGINX 入口控制器 和 NGINX 服务网格。本节着眼于入口控制器。为了了解 NGINX 如何定位这两个工具，他们的架构图很有帮助：

您可以在这里介绍两种类型的日志：用于 NGINX 入口控制器 本身， 和/或 更强大的整体 NGINX 日志。

使用 NGINX 入口日志进行调试

您可以通过添加 到 Kubernetes 部署的部分来将日志级别更改为 调试。请注意，必须使用 NGINX 部署构建 - 以便稍后获得调试日志。–v=5-args-with-debug

kubectl edit deployment nginx-ingress-controller

spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --v=5

使用常规 NGINX 错误日志进行调试

当你配置 NGINX 日志时，你必须设置错误日志，这对于调试来说是最重要的。

但在你这样做之前，你需要确保首先编译 NGINX（如果使用开源版本）并带有调试选项（是的，这感觉没有必要，但目前情况就是这样，因为 NGINX尝试管理它对存储日志数据的承诺。当然，默认情况下该选项可能只是关闭，但我们并不生活在那个替代的现实中）。

首先，下载 NGINX 的开源版本。然后开始编译过程。

nginx -V 2>&1 | grep arguments

添加 –with-debug 参数：

./configure --with-debug

编译：

sudo make

安装：

sudo make install

并重新启动。

现在，第 2 阶段。仔细检查安装是否 –with-debug 可用：

nginx -V 2>&1 | grep -- '--with-debug'

打开 NGINX 配置文件：

sudo vi /etc/nginx/nginx.conf

并设置 debug 参数：

error_log  /var/log/nginx/error.log debug;

NGINX 文档中提供了更多选项 。最后，我要补充一点，您还可以使用 Syslog 作为替代方案，它需要一个 syslog: 前缀，然后指定一个服务器（通过 IP、UNIX 套接字或域）。

error_log  syslog:server=130.78.244.101 debug;
access_log syslog:server=130.78.244.102 severity=debug;

5. 在 Traefik（入口控制器）中调试

Traefik Kubernetes Ingress 控制器是另一个入口控制器选项。它管理 Kubernetes 集群服务；也就是说，它通过支持 Ingress 规范来管理对集群服务的访问。不要将它与公司的其他工具混为一谈：Traefik Mesh 和 Traefik Gateway。

与 NGINX 一样，您可以同时设置 Traefik Ingress 日志和/或 常规 Traefik 日志和调试。

Traefik 调试日志

您可以配置 调试级别的 Traefik 日志 或通过 Traefix API debugs 进行调试。两者都可以通过以下三种方式之一完成：通过 Traefik CLI、 .yaml 配置文件或 .toml 配置文件。

日志方面，这是一个快速的三步过程： 1. 设置 filepath. 2. 设置 format (json 或 text)。3. 设置 level. 此示例展示了如何在 Traefik CLI 中执行此操作，但您也可以使用 YAML 或 TOML 配置文件。

--log.filePath=/path/to/traefik.log
--log.format=json
--log.level=DEBUG

DEBUG 是 Traefik 中的六个日志级别之一，但默认为 ERROR （其他为 PANIC、 FATAL、 WARN和 INFO）。

Traefix API 调试

在 CLI 中，设置 API：

--api=true

然后，您将为 Kubernetes 和其他容器编排器或基础设施管理器（Docker Swarm、Docker 等）提供不同的配置选项。当然，让我们展示一个基于 Traefik 文档的 Kubernetes CRD 示例（在 YAML 中） ：

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard
spec:
  routes:
  - match: Host(`traefik.progress-regress-we-all-scream-4-ingress.com`) <em>#this is clearly an example please do not visit this url and take no responsibility if it is real and unsafe</em>
    kind: Rule
    services:
    - name: api@internal
      kind: TraefikService
    middlewares:
      - name: auth
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: auth
spec:
  basicAuth:
    secret: someFancyShmancySecretiveIngressiveSecretNameShorterThanThis

然后将其设置为在 CLI 中调试：

--api.debug=true

调试用于基础设施管理的 Kubernetes 工具

包管理器、基础设施即代码、配置管理器、自动化引擎等。这是一个相当不拘一格的类别，因为许多竞争工具对相同的任务采用不同的方法，有时不是直接竞争，而是互补工具。

因此，其中许多工具可能能够达到列表中其他工具无法达到的目的。同时，虽然您通常可以扩展它们以完成其他类型的任务，但与其中一种替代方案相比可能非常困难。由于这种重叠，Kubernetes 架构图可能看起来像科学怪人应用程序。

（* in combination with CrossPlane, Helm and Kustomize can provision cloud resources ** kubectl apply -k (docs) *** when you provision K8S resources with terraform provider is actually deploy）

不过，每个用例都是不同的。无论您最终使用了哪些工具或使用了多少工具，您都应该知道在哪里以及如何调试它们。

使用 Pulumi，您可以使用成熟的编程语言编写或定义您的基础设施：Go、Python、C#、vanilla JS 和 TypeScript。Terraform 使用 HCL 定义基础设施，然后使用 JSON 状态文件对其进行跟踪。Ansible 虽然使用 YAML 来定义基础架构，并且本质上是无状态的。选项从那里扩展。

6. 调试 Helm

Helm 已经成为很多人事实上的 Kubernetes 包管理器。它利用称为 Helm Charts 的 Kubernetes 部署的复杂模板。模板化或构建用于部署的图表本身就是一个过程。有几种方法可以 调试 Helm 模板。

The –debug Flag

首先，检查您已经安装了哪些模板：

helm get manifest

然后让服务器渲染模板并返回清单：

helm install --dry-run --debug

或者…

helm template -debug

您也可以将 –debug 标志与大多数其他命令一起使用。无论您在做什么，它都会提供更详细的日志响应。您可以将这些日志推迟到特定文件，如下所示：

helm test -f -debug > debuglogs.yaml

7 、调试 Terraform

Terraform 并不是为 Kubernetes 原生设计的，但它已成为一种流行的选择。Terraform 使用它称为提供程序的支持包系统，并构建了自己的 Kubernetes 提供程序。它使用 HashiCorp 配置语言 (HCL) 来部署和管理 Kubernetes 资源、集群、API 等。

或者，您可能更喜欢通过像 Kubernetes 这样的提供程序来工作 hashicorp/helm，它比 vanilla Kubernetes 选项更强大。您可以将 Terraform 日志用于多个日志级别之一，包括调试。还有用于调试 Terraform 提供程序或插件集成的特定策略。

Terraform 调试日志

您可以使用 或 来记录 Terraform 本身， TF_LOG 或者 使用 来记录TF_LOG_CORETerraform 和所有提供者 TF_LOG_PROVIDER。您可以将日志设置扩展到只有一个特定的提供程 TF_LOG_PROVIDER_。

TF_LOG_PROVIDER=DEBUG

或者，您可以使用 stderr 进行日志记录，但不能在 Terraform 中使用 stdout，因为它已经是专用通道。

您可以使用原生 tflog 包进行结构化日志记录，然后设置日志级别。根据您使用的是框架还是 SDK Terraform 插件，您可以设置创建调试日志的上下文。考虑 Terraform 文档中的以下示例：

apiContext := tflog.SetField(ctx, "url", "https://www.example.com/my/endpoint")

tflog.Debug(ctx, "Calling database")
tflog.Debug(apiContext, "Calling API")

8. 调试 Kustomize

您可能已经从拼写中猜到这是 Kubernetes 原生的。Kustomize 是一个配置管理器，它的名字来源于自定义配置文件。它不像 Helm 那样依赖模板，而是更喜欢严格使用 YAML 文件，甚至使用 YAML 文件来配置其他 YAML 文件。

现在，对于任何想要独立于 kubectl 和其他元素调试 Kustomize 的人来说，它更加复杂。有点像寻找旧约中提到的地狱，不可能找到任何关于日志记录、跟踪，尤其是 Kustomize 本身的调试的文档。一段时间以来，一直存在对严格属于 Kustomize 的日志的需求，但有一些 解决方法。

您可以 在应用程序log_level 内的文件中进行调试 。deployment.yml

       env:
        - name: LOG_LEVEL
          value: "DEBUG"

之后，您将添加 kustomization.yml 文件，删除原始资源，然后重新部署应用程序。

9. 调试 Ansible

您必须启用调试设置，默认情况下是关闭的。接下来，您可以使用 debugger 关键字，如Ansible 文档中的此示例 所示：

- name: Execute a command
  ansible.builtin.command: "false"
  debugger: on_failed

ansible.cfg 在该部分的文件中 全局启用它 [defaults] ：

[defaults]
enable_task_debugger = True

10. 调试 Pulumi

Pulumi 是社区中较新的孩子之一，主要是 IaC 工具。它通过将 Kubernetes API 公开为 SDK 来部署，然后在其工作的基础设施中使用容器和 Kubernetes 集群管理 IaC。话虽如此，Pulumi 尝试使用已经在生态系统中广泛使用的工具，因此它使用 TF_LOG 和使用它的规则就像在 Terraform 中一样。

Pulumi 还具有原生日志配置，可以使用常规编程语言而不是 CLI/领域特定语言进行操作。此示例涵盖 Java：

此外，您还可以实现 Pulumi Debug API。Pulumi 的文档使用这个多选样式示例，参数中列出了不同的选项：

debug(msg: string, resource?: resourceTypes.Resource, streamId?: undefined | number, ephemeral?: undefined | false | true): Promise<void>

调试 Kubernetes 工具是一种冒险

每个工具都有不止一种方法来调试其服务和实现。有些有不同的方法来调试日志，而另一些则包括跟踪收集作为选项。开发人员优先的可观察性要求您找到提供最清晰答案和最简单设置的选项。一些竞争工具也有可能在同一个 Kubernetes 堆栈中协作。希望本概述能让您了解现有的内容，以及您希望使用哪些工具进行 Kubernetes 调试。

但是要真正了解整个 Kubernetes 堆栈中发生的事情，需要一个真正的总体工具。

Bootes——K8s多集群多云管理平台

行云创新K8s多集群多云管理平台（Bootes），云原生混合云管平台，通过单一控制面板实现跨混合云的Kubernetes统一管理，专注于Kubernetes的多云统一管理，无缝对接多套异构环境的Kubernetes集群。提供多租户的Kubernetes原生资源对象管理、应用管理、一站式应用商店、统一的监控告警平台、GitOps、租户级别的资源计量等能力。友好易用的管理界面让用户快速开展应用的部署、管理、监控等作业。

点击这里，免费获取K8s多集群多云管理解决方案>>