十大Kubernetes工具及调试方法-51CTO.COM

译者 | 布加迪

审校 | 孙淑娟

革命性的Kubernetes是一次彻底的重组，需要一系列全新的配套和支持工具来支撑整个生态系统。实际上有数百种工具专为K8s而设计，包括开源和专有工具。

选择您的Kubernetes技术堆栈似乎很困难，毕竟生态系统很庞大。本文无意列出所有工具及调试方法。开发者优先的可观测性需要简化这一大堆工具。全面了解和调试Kubernetes部署需要一种比使用堆栈中的每个工具更直接更高效的总体工具和策略。话虽如此，大多数单独的工具提供内部可观测性，知道如何获得这种工具可以为开发者带来优势。

虽然不可能详尽地介绍每种工具，但本文将介绍最基本的工具以及每个类别的主要玩家。

一、调试K8s服务网格和入站控制器

我们已经有编排和部署工具，为什么需要一些听起来多余的工具？这涉及微服务之间Kubernetes协调的关键。服务网格和入站（ingress）控制器充当可配置的抽象层，控制进出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应用程序的请求跟踪。

调试502s，即错误的网关响应
调试控制平面端点
使用度量指标调试HTTP应用程序
使用请求跟踪调试gRPC应用程序

针对Linkerd调试容器/边车：

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 -duratinotallow=2m -httpaddr=126.0.0.1:8500

4.NGINX入站控制器

NGINX之所以值得关注，是由于它很容易结合使用两个单独的工具：NGINX入站控制器和NGINX服务网格。本节着眼于入站控制器。为了解NGINX如何定位这两个工具，其架构图大有帮助：

图1. NGINX架构图（入站控制器vs服务网格）

（来源：NGINX 文档）

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

使用NGINX入站日志进行调试

您可以通过将–v=5添加到Kubernetes部署的-args部分，将日志级别更改为debug。注意，NGINX部署必须使用--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集群服务，通过支持入站规范来管理对集群服务的访问。别将它与该公司的其他工具：Traefik Mesh和Traefik Gateway混为一谈。

与NGINX一样，Traefik Ingress日志和常规的Traefik日志及调试可以同时设置，也可以单独设置。

Traefik调试日志

您可以配置调试级别的Traefik日志，或通过Traefix API调试进行调试。两者都可以通过以下三种方式之一完成：通过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:

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

--api.debug=true

调试用于管理基础架构的Kubernetes工具

包管理器、基础架构即代码、配置管理器、自动化引擎等，许多彼此竞争的工具对相同的任务采用不同的方法，有时不是直接竞争，而是互为补充。

图2. 比较各种Kubernetes自动化、包和配置工具的非详尽的维恩图

6.调试Helm

Helm已成为很多人事实上的Kubernetes包管理器。它使用名为Helm Charts的面向Kubernetes部署的复杂模板。创建模板或构建用于部署的chart本身就是一个过程。有几种方法可以调试Helm模板。

--debug 标志

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

helm get manifest

然后让服务器显示模板，并返回清单文件：

helm install --dry-run --debug

或者：

helm template –debug

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

helm test -f -debug > debuglogs.yaml

7.调试Terraform

Terraform不是为Kubernetes原生设计的，但它已成为首选。Terraform使用名为provider的支持包系统，构建了自己的Kubernetes provider。它使用HashiCorp 配置语言（HCL）来部署和管理Kubernetes资源、集群和API等。

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

Terraform调试日志

可以使用TF_LOG或TF_LOG_CORE记录Terraform本身，或者使用TF_LOG_PROVIDER记录Terraform和所有provider。您可以使用TF_LOG_PROVIDER_<providername>将日志设置扩展到只有一个特定的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本身调试方面的文档。

您可以在应用程序内的deployment.yml文件中将log_level用作调试级别。

env:
- name: LOG_LEVEL
value: "DEBUG"

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

9.调试Ansible

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

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

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

[defaults]
enable_task_debugger = Trueenable_task_debugger = True

10.调试Pulumi

Pulumi是后起之秀，主要是一种IaC工具。其工作原理是，将Kubernetes API公开为SDK来部署和管理IaC。Pulumi试图兼容生态系统中已经广泛使用的工具，因此它使用TF_LOG及其规则，就像在Terraform中一样。

Pulumi也有原生的日志配置，可以用常规的编程语言而不是CLI/领域特定的语言来操作。

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

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

二、调试Kubernetes工具如同探险

每个工具都有不止一种方法来调试其服务和实现。一些工具有不同的方法来调试日志，另一些工具包括跟踪收集这一选项。开发者优先的可观测性要求您找到提供最清晰答案和最简单设置的选项。一些彼此竞争的工具也有可能在同一个Kubernetes堆栈中协作。但愿本文让您了解现有的工具以及您希望使用哪些工具用于Kubernetes调试。

原文链接：https://www.cncf.io/blog/2022/09/15/10-critical-kubernetes-tools-and-how-to-debug-them/