译者|布加迪评论家|孙淑娟革命性的Kubernetes是一次彻底的重组，需要一系列新的支撑和支撑工具来支撑整个生态系统。有数百种专门为K8s设计的工具，既有开源的也有专有的。鉴于庞大的生态系统，选择您的Kubernetes技术堆栈似乎很困难。本文无意罗列所有工具和调试方法。开发人员优先的可观察性需要简化这些过多的工具。完全理解和调试Kubernetes部署需要一个比使用堆栈中的每个工具更直接和高效的整体工具和策略。话虽如此，大多数单独的工具都提供内部可观察性，知道如何获得它可以给开发人员带来优势。虽然不可能详尽地涵盖所有工具，但本文将涵盖最基本的工具和每个类别中的主要参与者。1、调试K8s服务网格和入站控制器我们已经有了编排和部署工具，为什么还需要一些听起来多余的工具呢？这触及了微服务之间Kubernetes协调的关键。服务网格和入口控制器充当可配置的抽象层，控制进出Kubernetes的流量。服务网格协调Kubernetes中的服务（即东西向流量）。入站控制器协调流入Kubernetes的流量（入站）和可能流出Kubernetes的流量（出站，即南北流量）。在Kubernetes中，您将使用KubernetesAPI来配置和部署它们。它们：1.接受入站（传入）流量并通过负载均衡将其路由到Pod2.监控Pod，并自动更新负载均衡规则3.管理与集群外部服务通信的出站（传出）流量您的Kubernetes堆栈工具是值得商榷的，因此这两个类别中的几乎所有工具都相互竞争。此外，您可以添加一个API网关来控制入站和出站流量，如入站控制器。三大服务网格是Istio、Linkerd和Consul。它们使用管理集群级数据流量的“控制平面”和“数据平面”直接解决网格内服务之间处理数据的功能。1.调试Istio您可以使用以下两个命令之一深入了解Istio网格中的流量：istioctlproxy-statusistioctlproxy-config您还可以浏览调试日志。请注意，debug是Istio日志的五个可能输出之一（其他是none、error、warn和info）。请注意，调试将提供最多的数据，一些开发人员认为Istio在日志方面的信息量很大。以下示例定义了要分析的不同范围：istioctlanalyze--log_output_levelklog:debug,installer:debug,validation:debug,validationController:debug2.Linkerd调试的默认方式是使用调试容器（debugsidecar）。但是，Linkerd调试的工作方式因您使用的应用程序类型而异。例如，您将使用指标来调试HTTP应用程序并为gRPC应用程序请求跟踪。调试502，即错误的网关响应调试控制平面端点使用指标调试HTTP应用程序使用请求跟踪调试gRPC应用程序调试容器/Sidecars定位Linkerd：kubectl-ngetdeploy/-oyaml\|linkerd注入--enable-debug-sidecar-\|kubectl应用-f-3。调试ConsulConsul调试命令在Consul中非常简单。使用-capture定义您想要分析的内容，并为间隔、持续时间、API、Gopprof包等添加参数。consuldebug-captureagent-capturehost-capturelogs-capturemetrics-capturemembers-capturepprof-interval=30s-duratinotallow=2m-httpaddr=126.0.0.1:85004.N??GINX入站控制器NGINX值得关注，因为很容易将两个独立的控制器结合起来工具：NGINXInboundController和NGINXServiceMesh。本节着眼于入站控制器。要了解NGINX如何定位这两个工具，其架构图有很大帮助：图1.NGINX架构图（入站控制器与服务网格）（来源：NGINX文档）您可以在此处介绍两种类型的日志：对于NGINX入站控制器本身，和/或更强大的整体NGINX日志记录。使用NGINX入站日志进行调试您可以通过将--v=5添加到Kubernetes部署的-args部分来将日志级别更改为调试。请注意，NGINX部署必须使用--with-debug构建，以便稍后获取调试日志。kubectleditdeploymentnginx-ingress-controllerspec:containers:-args:-/nginx-ingress-controller---v=5使用常规的NGINX错误日志进行调试在配置NGINX日志时，必须设置错误日志，这对调试很有用最重要的。但在此之前，您需要确保使用调试选项编译NGINX（如果使用开源版本）。虽然感觉没有必要，但目前情况就是如此，因为NGINX试图管理如何提交存储日志数据。当然，默认情况下该选项可能完全关闭。首先下载开源版本的NGINX，开始编译过程。nginx-V2>&1|grep参数添加--with-debug参数./configure--with-debug编译：sudomakeinstall：sudomakeinstall重启。现在是第2阶段。仔细检查安装是否有-with-debug:nginx-V2>&1|grep--'--with-debug'打开NGINX配置文件：sudovi/etc/nginx/nginx.conf设置调试参数：error_log/var/log/nginx/error.logdebug;NGINX文档中有更多选项。作为最后的补充，您还可以使用Syslog作为替代方案，这需要syslog:前缀，然后指定服务器（通过IP、UNIX套接字或域）。error_logsyslog:server=130.78.244.101debug;access_logsyslog:server=130.78.244.102severity=debug;5.调试Traefik（入站控制器）TraefikKu??bernetesIngresscontroller是另一个入站控制器。它管理Kubernetes集群服务并通过支持入站规范来管理对集群服务的访问。不要将它与公司的其他工具混淆：TraefikMesh和TraefikGateway。与NGINX一样，TraefikIngress日志记录和常规Traefik日志记录和调试可以同时或单独设置。Traefik调试日志您可以在调试级别配置Traefik日志，或者通过TraefikAPI调试进行调试。两者都可以通过以下三种方式之一完成：通过TraefikCLI、.yaml配置文件或.toml配置文件。就日志记录而言，这是一个快速的三步过程：1.设置文件路径。2.设置格式（json或文本）。3.设置级别。该示例演示了如何在TraefikCLI中执行此操作，但您也可以使用YAML或TOML配置文件。--log.filePath=/path/to/traefik.log--log.format=json--log.level=DEBUGdebug是Traefik中六个日志级别之一，但默认是ERROR（其他级别有PANIC、FATAL、警告和信息）。TraefixAPI调试在CLI中，设置API:--api=true然后你将有不同的Kubernetes和其他容器编排器或基础设施管理器（DockerSwarm和Docker等）的配置选项。让我们演示一个基于Traefik文档的KubernetesCRD（在YAML中）示例：apiVersion:traefik.containo.us/v1alpha1kind:IngressRoutemetadata:name:traefik-dashboardspec:routes:-match:Host(`traefik.progress-regress-we-all-scream-4-ingress.com`)#this显然是一个示例，请不要访问此url，如果它是真实且不安全的，则不承担任何责任种类：Ruleservices：-名称：api@internalkind:TraefikServicemiddlewares:-name:auth---apiVersion:traefik.containo.us/v1alpha1kind:Middlewaremetadata:name:authspec:basicAuth:secret:然后在CLI中设置为debug:--api.debug=true用于调试Kubernetes工具包用于管理基础架构的管理器、基础架构即代码、配置管理器、自动化引擎等。许多相互竞争的工具对同一任务采用不同的方法，有时不是直接竞争，而是互补。图2.比较各种Kubernetes自动化、包和配置工具的非详尽维恩图6.调试HelmHelm已成为许多人事实上的Kubernetes包管理器。它为Kubernetes部署使用称为HelmCharts的复杂模板。创建模板或构建用于部署的图表本身就是一个过程。有多种调试Helm模板的方法。--debug标志首先检查你安装了哪些模板：helmgetmanifest然后让服务器显示模板并返回清单文件：helminstall--dry-run--debug或者：helmtemplate--debug你也可以使用–debugflag与大多数其他命令一起使用。无论您在做什么，它都会提供更详细的日志响应。您可以将这些日志委托给特定的文件，如下所示：helmtest-f-debug>debuglogs.yaml7.调试TerraformTerraform不是为Kubernetes设计的，但它已成为首选。Terraform使用称为提供者的支持包系统构建自己的Kubernetes提供者。它使用HashiCorp配置语言(HCL)来部署和管理Kubernetes资源、集群、API等。或者，您可能更喜欢通过像hashcorp/helm这样的提供程序来工作，它比普通的Kubernetes选项更强大。您可以将Terraform日志记录用于多个日志级别之一，包括调试。还有用于调试Terraform提供程序或插件集成的特定策略。Terraform调试日志可以使用TF_LOG或TF_LOG_CORE来记录Terraform本身，或者使用TF_LOG_PROVIDER来记录Terraform和所有提供程序。您可以使用TF_LOG_PROVIDER_将日志记录设置扩展到仅特定的提供者。TF_LOG_PROVIDER=DEBUG日志也可以使用stderr，但是在Terraform中不能使用stdout，因为它已经是专用通道了。您可以使用本机tflog包进行结构化日志记录，然后设置日志记录级别。根据您使用的是框架还是SDKTerraform插件，您可以设置创建调试日志的上下文。考虑Terraform文档中的以下示例：apiContext:=tflog.SetField(ctx,"url","https://www.example.com/my/endpoint")tflog.Debug(ctx,"Callingdatabase")tflog.Debug(apiContext,"CallingAPI")8.DebugKustomize看拼写你可能已经猜到这是Kubernetes原生的。Kustomize是一个配置管理器，其名字来源于自定义配置文件。它不像Helm那样依赖模板，而是更喜欢严格使用YAML文件，甚至使用YAML文件来配置其他YAML文件。现在，对于任何想要在不依赖kubectl和其他元素的情况下调试Kustomize的人来说，它变得更加复杂。无法找到有关日志记录、跟踪，尤其是Kustomize本身调试的任何文档。您可以在应用程序内的deployment.yml文件中使用log_level作为调试级别。env:-name:LOG_LEVELvalue:"DEBUG"之后，您将添加kustomization.yml文件，删除原始资源，然后重新部署应用程序。9.调试Ansible您必须启用调试设置，默认情况下它是关闭的。接下来，您可以使用debugger关键字，如Ansible文档中的示例所示：-name：执行命令ansible.builtin.command：“false”debugger：在[defaults]部分的ansible.cfg文件中全局启用It:[defaults]enable_task_debugger=Trueenable_task_debugger=True10.调试PulumiPulumi是后起之秀，主要是一个IaC工具。它通过将KubernetesAPI公开为SDK来部署和管理IaC。Pulumi试图与生态系统中已经广泛使用的工具兼容，因此它使用TF_LOG及其规则，就像在Terraform中一样。Pulumi还具有本地日志记录配置，可以使用常规编程语言而不是CLI/领域特定语言进行操作。此外，您还可以实现PulumiDebugAPI。Pulumi的文档使用了这个多选样式示例，在参数中列出了不同的选项：debug(msg:string,resource?:resourceTypes.Resource,streamId?:undefined|number,ephemeral?:undefined|false|true):Promise<无效>2。调试Kubernetes工具就像探索一样。每个工具都有不止一种调试其服务和实现的方法。一些工具有不同的调试日志的方法，其他工具包括跟踪收集选项。开发人员优先的可观察性要求您找到提供最清晰答案和最简单设置的选项。一些相互竞争的工具也有可能在同一个Kubernetes堆栈中进行协作。希望本文能让您了解存在哪些工具以及您可能希望使用哪些工具进行Kubernetes调试。原文链接：https://www.cncf.io/blog/2022/09/15/10-critical-kubernetes-tools-and-how-to-debug-them/
