譯者 | 布加迪

審校 | 孫淑娟

革命性的Kubernetes是一次徹底的重組，需要一系列全新的配套和支持工具來支撐整個生態(tài)系統(tǒng)。實際上有數(shù)百種工具專為K8s而設(shè)計，包括開源和專有工具。

選擇您的Kubernetes技術(shù)堆棧似乎很困難，畢竟生態(tài)系統(tǒng)很龐大。本文無意列出所有工具及調(diào)試方法。開發(fā)者優(yōu)先的可觀測性需要簡化這一大堆工具。全面了解和調(diào)試Kubernetes部署需要一種比使用堆棧中的每個工具更直接更高效的總體工具和策略。話雖如此，大多數(shù)單獨的工具提供內(nèi)部可觀測性，知道如何獲得這種工具可以為開發(fā)者帶來優(yōu)勢。

雖然不可能詳盡地介紹每種工具，但本文將介紹最基本的工具以及每個類別的主要玩家。

一、調(diào)試K8s服務(wù)網(wǎng)格和入站控制器

我們已經(jīng)有編排和部署工具，為什么需要一些聽起來多余的工具？這涉及微服務(wù)之間Kubernetes協(xié)調(diào)的關(guān)鍵。服務(wù)網(wǎng)格和入站（ingress）控制器充當可配置的抽象層，控制進出Kubernetes的流量。

服務(wù)網(wǎng)格對Kubernetes內(nèi)的服務(wù)進行協(xié)調(diào)（即東西流量）。

入站控制器協(xié)調(diào)流入Kubernetes的流量（入站），并協(xié)調(diào)可能流出Kubernetes的流量（出站，即南北流量）。在Kubernetes中，您將使用Kubernetes API來配置和部署它們。它們：

1. 接受入站（流入）流量，并通過負載均衡將其路由到pod

2. 監(jiān)控pod，并自動更新負載均衡規(guī)則

3. 管理與集群外服務(wù)通信的出站（流出）流量

您的Kubernetes堆棧是否真需要這兩種工具值得商榷，因此實際上這兩個類別的所有工具都相互競爭。此外，您還可以添加API網(wǎng)關(guān)，像入站控制器一樣控制入站流量和出站流量。

三大服務(wù)網(wǎng)格是Istio、Linkerd和Consul。它們使用管理集群級數(shù)據(jù)流量的“控制平面”和“數(shù)據(jù)平面”，直接面對在網(wǎng)格內(nèi)的服務(wù)之間處理數(shù)據(jù)的功能。

1.調(diào)試 Istio

您可以使用以下兩個命令之一深入了解Istio網(wǎng)格中的流量：

istioctl proxy-status
istioctl proxy-config

您還可以瀏覽調(diào)試日志。注意，debug是Istio日志的五種可能輸出之一（其他是none、error、warn和info）。注意，調(diào)試將提供最多的數(shù)據(jù)，一些開發(fā)者認為Istio在日志方面信息量很大。

以下示例定義了要分析的不同范圍：

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

2.調(diào)試Linkerd

調(diào)試的默認方法是使用調(diào)試容器（調(diào)試邊車）。然而，Linkerd調(diào)試的工作方式因您使用的應用程序類型而異。

比如說，您將使用度量指標來調(diào)試HTTP應用程序和gRPC應用程序的請求跟蹤。

• 調(diào)試502s，即錯誤的網(wǎng)關(guān)響應
• 調(diào)試控制平面端點
• 使用度量指標調(diào)試HTTP應用程序
• 使用請求跟蹤調(diào)試gRPC應用程序

針對Linkerd調(diào)試容器/邊車：

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

3.調(diào)試Consul

Consul調(diào)試命令在Consul中極其簡單。使用-capture定義您要分析的內(nèi)容，并為間隔、持續(xù)時間、API、Go pprof 包等添加參數(shù)。

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之所以值得關(guān)注，是由于它很容易結(jié)合使用兩個單獨的工具：NGINX入站控制器和NGINX服務(wù)網(wǎng)格。本節(jié)著眼于入站控制器。為了解NGINX如何定位這兩個工具，其架構(gòu)圖大有幫助：

圖1. NGINX架構(gòu)圖（入站控制器vs服務(wù)網(wǎng)格）

（來源：NGINX 文檔）

您可以在這里介紹兩種類型的日志：用于NGINX入站控制器本身，及/或更強大的整體NGINX日志。

使用NGINX入站日志進行調(diào)試

您可以通過將–v=5添加到Kubernetes部署的-args部分，將日志級別更改為debug。注意，NGINX部署必須使用--with-debug來構(gòu)建，以便稍后獲得調(diào)試日志。

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

使用常規(guī)NGINX錯誤日志進行調(diào)試

配置NGINX日志時，您必須設(shè)置錯誤日志，這對于調(diào)試來說最重要。

但在此之前，您需要確保先用調(diào)試選項來編譯NGINX（如果使用開源版）。雖然感覺沒有必要，但目前情況就是這樣，因為NGINX試圖管理如何致力于存儲日志數(shù)據(jù)。當然，默認情況下該選項可能完全關(guān)閉。

先下載NGINX的開源版，然后開始編譯過程。

nginx -V 2>&1 | grep arguments

添加--with-debug參數(shù)

./configure --with-debug

編譯：

sudo make

安裝：

sudo make install

重新啟動。

現(xiàn)在是第2階段。仔細檢查安裝是否有-with -debug：

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

打開NGINX配置文件：

sudo vi /etc/nginx/nginx.conf

設(shè)置debug參數(shù)：

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

NGINX文檔中有更多的選項。最后補充一點，還可以使用Syslog作為替代方案，這需要syslog:前綴，然后指定一臺服務(wù)器（通過IP、UNIX套接字或域來指定）。

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

5.調(diào)試Traefik（入站控制器）

Traefik Kubernetes Ingress控制器是另一種入站控制器。它管理Kubernetes集群服務(wù)，通過支持入站規(guī)范來管理對集群服務(wù)的訪問。別將它與該公司的其他工具：Traefik Mesh和Traefik Gateway混為一談。

與NGINX一樣，Traefik Ingress日志和常規(guī)的Traefik日志及調(diào)試可以同時設(shè)置，也可以單獨設(shè)置。

Traefik調(diào)試日志

您可以配置調(diào)試級別的Traefik日志，或通過Traefix API調(diào)試進行調(diào)試。兩者都可以通過以下三種方式之一完成：通過Traefik CLI、.yaml配置文件或.toml配置文件。

日志方面，這是一個快速的三步過程：1. 設(shè)置filepath。2. 設(shè)置format（json或text）。3. 設(shè)置level。該示例演示了如何在Traefik CLI中執(zhí)行此操作，但您也可以使用YAML或TOML配置文件。

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

debug是Traefik中的六個日志級別之一，但默認為ERROR（其他級別為PANIC、FATAL、WARN和INFO）。

Traefix API調(diào)試

在CLI中，設(shè)置 API：

--api=true

然后，您將會有針對Kubernetes及其他容器編排器或基礎(chǔ)架構(gòu)管理器（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:

然后，將其設(shè)置為在CLI中調(diào)試：

--api.debug=true

調(diào)試用于管理基礎(chǔ)架構(gòu)的Kubernetes工具

包管理器、基礎(chǔ)架構(gòu)即代碼、配置管理器、自動化引擎等，許多彼此競爭的工具對相同的任務(wù)采用不同的方法，有時不是直接競爭，而是互為補充。

圖2. 比較各種Kubernetes自動化、包和配置工具的非詳盡的維恩圖

6.調(diào)試Helm

Helm已成為很多人事實上的Kubernetes包管理器。它使用名為Helm Charts的面向Kubernetes部署的復雜模板。創(chuàng)建模板或構(gòu)建用于部署的chart本身就是一個過程。有幾種方法可以調(diào)試Helm模板。

--debug 標志

先檢查您已經(jīng)安裝了哪些模板：

helm get manifest

然后讓服務(wù)器顯示模板，并返回清單文件：

helm install --dry-run --debug

或者：

helm template –debug

您也可以將–debug標志與大多數(shù)其他命令一起使用。無論您在做什么，它都會提供更詳細的日志響應。您可以將這些日志委托給特定文件，如下所示：

helm test -f -debug > debuglogs.yaml

7.調(diào)試Terraform

Terraform不是為Kubernetes原生設(shè)計的，但它已成為首選。Terraform使用名為provider的支持包系統(tǒng)，構(gòu)建了自己的Kubernetes provider。它使用HashiCorp 配置語言（HCL）來部署和管理Kubernetes資源、集群和API等。

或者，您可能更喜歡通過像hashcorp/helm這樣的provider來工作，其功能比普通的Kubernetes選項更強大。您可以將Terraform日志用于多個日志級別之一，包括調(diào)試。還有用于調(diào)試Terraform provider或插件集成的特定策略。

Terraform調(diào)試日志

可以使用TF_LOG或TF_LOG_CORE記錄Terraform本身，或者使用TF_LOG_PROVIDER記錄Terraform和所有provider。您可以使用TF_LOG_PROVIDER_<providername>將日志設(shè)置擴展到只有一個特定的provider。

TF_LOG_PROVIDER=DEBUG

您還可以使用stderr用于日志，但無法在Terraform中使用stdout，因為它已經(jīng)是專用通道。

您可以使用原生tflog包用于結(jié)構(gòu)化日志，然后設(shè)置日志級別。根據(jù)您使用的是框架還是SDK Terraform插件，可以設(shè)置創(chuàng)建調(diào)試日志的上下文?？紤]Terraform文檔中的以下示例：

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

8.調(diào)試Kustomize

您可能已從拼寫中猜到這是Kubernetes原生的。Kustomize是一個配置管理器，名字來源于定制配置文件。它不像Helm那樣依賴模板，而是更喜歡嚴格使用YAML文件，甚至使用YAML文件來配置其他YAML文件。

現(xiàn)在，對于任何想要不依賴kubectl及其他元素來調(diào)試Kustomize的人來說，它更加復雜。不可能找到任何關(guān)于日志、跟蹤，尤其是Kustomize本身調(diào)試方面的文檔。

您可以在應用程序內(nèi)的deployment.yml文件中將log_level用作調(diào)試級別。

env:
- name: LOG_LEVEL
value: "DEBUG"

之后，您將添加kustomization.yml文件，刪除原始資源，然后重新部署應用程序。

9.調(diào)試Ansible

您必須啟用調(diào)試設(shè)置，默認情況下它是關(guān)閉的。接下來，您可以使用debugger關(guān)鍵字，如Ansible文檔中的該示例所示：

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

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

[defaults]
enable_task_debugger = Trueenable_task_debugger = True

10.調(diào)試Pulumi

Pulumi是后起之秀，主要是一種IaC工具。其工作原理是，將Kubernetes API公開為SDK來部署和管理IaC。Pulumi試圖兼容生態(tài)系統(tǒng)中已經(jīng)廣泛使用的工具，因此它使用TF_LOG及其規(guī)則，就像在Terraform中一樣。

Pulumi也有原生的日志配置，可以用常規(guī)的編程語言而不是CLI/領(lǐng)域特定的語言來操作。

此外，您還可以實現(xiàn)Pulumi Debug API。Pulumi的文檔使用這個多選樣式示例，參數(shù)中列出了不同的選項：

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

二、調(diào)試Kubernetes工具如同探險

每個工具都有不止一種方法來調(diào)試其服務(wù)和實現(xiàn)。一些工具有不同的方法來調(diào)試日志，另一些工具包括跟蹤收集這一選項。開發(fā)者優(yōu)先的可觀測性要求您找到提供最清晰答案和最簡單設(shè)置的選項。一些彼此競爭的工具也有可能在同一個Kubernetes堆棧中協(xié)作。但愿本文讓您了解現(xiàn)有的工具以及您希望使用哪些工具用于Kubernetes調(diào)試。

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