譯者 | 布加迪

審校 | 孫淑娟

革命性的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/